As I did not have much time to test RemoteFX extensively, here are the first impressions of it and how we got it to work.
First of all, you MUST get a compatible video card. Not everything will work with Windows Server 2008 R2 with SP1 with Hyper-V, so you can get your Windows 7 VMs (with SP1 of course) working with RemoteFX.
I posted about it before. You can read the list of supported video cards here.
What did we get?
– HP desktop with a six-core AMD CPU and 8GB RAM.
– FirePro 5800 Video Card (also tried the unsupported Quadro FX 580 that by the way, does work too).
Initially I simply tested the Windows 7 VM connecting from the Hyper-V host itself but later got another Windows 7 SP1 box and used that one to connect to the VM.
Performance is decent I must say. I tried playing some Windows Media HD videos (make sure you disable multimedia redirection by using videoplaybackmode:i:0 in the .RDP file (save the RDP connection to the desktop and open it using Notepad). Also very important that you set the policy for RemoteFX (as I was not sure where to set it, I set it both on the client and on the VM itself). It is described here:
To set the experience index for connections using RemoteFX
- Log on to the client computer as a member of the local Administrators group.
Click Start, and in the Search programs and files box, type gpedit.msc and then press ENTER.
- Navigate to Computer ConfigurationPoliciesAdministrative TemplatesWindows ComponentsRemote Desktop ServicesRemote Desktop Session HostRemote Session Environment.
- Double-click Set experience index for connections when using RemoteFX.
- Select the Enabled option.
- In the Screen capture rate (frames per second) box, click Highest (best quality), and then click OK.
- Restart the client computer.
The key thing to understand here is, why you may need RemoteFX. For example, during our tests, playing the WMV-HD tests, it used up to 30MBits so as you can see it is VERY bandwidth intensive. For comparison, running Google Earth in DirectX mode used around 9MBits. So basically the bandwidth will of course depend on the application being used. The same for how intensive CPU/GPU utilization will be.
I would expect applications like AutoCad to use way less bandwidth than something like WMV-HD and what we will be testing next is actually using RemoteFX over a typical home (cable/DSL) connection, simulated in our lab. By typical I mean a 10MBits down/1MBits up with 40-50ms latency and some packet loss probably in the 1% range (or a little more due to bursty loss). Given the first results we have seen, I am confident RemoteFX can indeed work over the WAN (at least bandwidth wise) depending on the applications.
Yes, before Brian Madden sends me a tweet or leave a comment here saying ‘MS says RemoteFX is LAN only’, I still want to make the point that IMHO, anything that is LAN only has its fate determined already. DOA. See my post about this here.
And still on the performance side, what we have seen in a nutshell is this: RemoteFX does work great BUT it is NOT the same as local. Simple things like Flip3D (using Windows key + Tab) are NOT as smooth as running them locally. Even Google Earth (that works just fine by the way) is NOT as smooth. But they both work and work fine, considering you are over RDP. For a BETA release we can expect it will be tweaked and improved even more before it hits the market.
As a sidenote, keep in mind there IS a bug on SP1 that throws a message on the RemoteFX event log about CPU encoding being used for ATI cards. It is a known issue and has been fixed apparently on later builds, what of course I have no access. But for 1 VM testing like we did (I am after experience testing and not scalability – I will leave that to people with more time and resources on their hands like Ruben and Benny 🙂 ).
As soon as I have more results and some nice videos to show RemoteFX, I will post these here.
4,397 total views, 1 views today