My name is Nadim Abdo and I’m the development manager responsible for the Remote Desktop Protocol (RDP).
Since we first shipped RDP in 1998 with Windows NT Terminal Services Edition we’ve gotten lot of very useful feedback on RDP (please keep it coming!). But we’ve also heard a lot of ‘interesting’ myths and misconceptions about RDP and its performance. So I thought why not try to bust some of those myths.
This post will at times get technical for those inclined to those details but I’ll also try to share some useful tidbits that end-users can apply to get an even better RDP experience.
Top 10 RDP Protocol Misconceptions (Part 1 of 2):
1) Myth: RDP is pretty slow because it has to scrape the screen and can only send giant bitmaps
This is a common misconception. While many alternative protocols are principally screen scrapers, RDP uses sophisticated techniques to get much better performance than can be obtained with a simple screen scraping approach.
To drill into this it helps to first talk a little about what screen scraping really means (i.e. what RDP does not do today) and why it can be slow: In a screen scraping protocol the server side has to ‘poll’ screen contents frequently to see if anything has changed. Screen scraping polling involves frequent and costly memory ‘scrapes’ of screen content and then scanning through a lot of memory (a typical 1600x1200 by 32bpp screen is about 7MB of data) to see what parts may have changed. This burns up a lot of CPU cycles and leaves the protocol with few options but to send large resulting bitmaps down to the client.
So what does RDP do different today and why is it faster?
RDP uses presentation virtualization to enable a much better end-user experience, scalability and bandwidth utilization. RDP plugs into the Windows graphics system the same way a real display driver does, except that, instead of being a driver for a physical video card, RDP is a virtual display driver. Instead of sending drawing operations to a physical hardware GPU, RDP makes intelligent decisions about how to encode those commands into the RDP wire format. This can range from encoding bitmaps to, in many cases, encoding much smaller display commands such as “Draw line from point 1 to point 2” or “Render this text at this location.”
To illustrate some of the benefits on CPU load, terminal servers today can scale to many hundreds of users. In some of our scalability tests we see that even with hundreds of users connecting to one server running knowledge worker apps (e.g. Word, Outlook, Excel) the total CPU load consumed by RDP to encode and transmit the graphics is only a few percent of the whole system CPU load!
With this approach RDP avoids the costs of screen scraping and has a lot more flexibility in encoding the display as either bitmaps or a stream of commands to get the best possible performance.
2) Myth: RDP uses a lot of bandwidth
In many common and important scenarios such as knowledge worker applications and line of business app centralization RDP’s bandwidth usage is very low (on the order of Kbps per user depending on the app and scenario).
This is certainly much lower than many of the screen scraping approaches can hope to achieve (see point #1 above). More importantly it’s low enough that it provides a good experience for many users sharing the same network and datacenter infrastructure even when over a slow network.
So why has there been a perception that RDP uses a lot of bandwidth?
This is a good question and the answer probably lies in the fact that RDP does not use a constant amount of bandwidth; it actually tries to reduce bandwidth usage to 0 when nothing is changing on the screen. Bandwidth consumption only goes up in proportion to what is changing on screen. For instance, if you just run a line of business app with basic graphics and not much animation you may end up sending just a few Kbps of bandwidth down the wire. Of course if you start running animation-heavy applications or graphics your bandwidth usage will go up to support that scenario.
So let’s illustrate some sample bandwidth usages for RDP6.1 in common scenarios (data is from the RDP Performance Whitepaper).
Your mileage will vary depending on your application and network conditions, so it’s important to actually measure empirically for your scenario but the whitepaper gives useful general trends.
3) Myth: I can’t get the same rich experience I get locally when working over RDP
This is also a misconception. RDP provides a scalable remoting experience. By default it cuts down on rich effects in the desktop and application experience in order to preserve bandwidth and save on server load (e.g. CPU, memory). However, if you want the highest end user experience it is possible to turn on many rich effects and display enhancements such as:
· The Aero theme with full glass and 3D effects (when connecting to Vista with RDP 6.1)
· 32-bit per pixel color
The key to enabling many of these effects is to run the Remote Desktop client, click Options, and then click the Experience tab. Here you can select and enable many high-end features. Note that in some cases your admin might have controlled access to these features with server-side group policies.
In many cases you can get a great end user experience with good parity to the local case.
We’re also constantly working to ‘close the gap’ between the local and remote experience and so we’re looking to improve the remote experience even more in future versions.
4) Myth: RDP can’t be tuned to get better performance
This is again a misconception. RDP has a set of defaults that tries to provide the best balance between bandwidth usage, the remote user experience, and server scalability. However, you can override many settings if you want to manually tune for a specific scenario and in some cases get very significant boosts in performance.
TIP: One of my favorite such settings is the ability to set policy on the server to optimize RDP compression. This can give you a boost of as much as 60% bandwidth improvement over previous versions of RDP. The tradeoff here is that you’d be consuming more server resources (such as memory and possibly CPU) to achieve that bandwidth reduction.
The GP to control this is :
Administrative Templates\Windows Components\Terminal Services\Terminal Server\Remote Session Environment\“Set compression algorithm for RDP data”
There is more information on tuning the bulk compressor as well as other RDP-tunable parameters such as cache sizes in the RDP Performance Whitepaper.
5) Myth: Using lower color depths -- e.g. 8bpp -- gives the best end user experience
This is a common misconception and was historically true, but not anymore!
The first version of RDP only supported 8bpp color. However, ever since Windows XP, RDP has supported up to 32bpp color.
The reason for this is that more and more apps have come to expect 32bpp mode as the default. Even the Windows Aero experience requires it.
Rather than deny this trend and create a difference between the local and remote experiences, we put a lot of effort into optimizing the 32bpp case to bring down its cost. This allows the user to have the flexibility to pick what is best for their scenario without necessarily having to incur a much bigger bandwidth cost.
In general I’d recommend attempting to run your scenario at 32bpp and measuring the resulting bandwidth to see if it’s acceptable for your scenario. It will usually give the best visual experience and in several cases will consume only a small percentage more data than 16bpp.
That’s it for part 1. I hope this list has been useful, come back soon for part II of the Top 10 RDP Misconceptions list.
PingBack from http://www.clickandsolve.com/?p=17465
I saw "The Aero theme with full glass and 3D effects" also running on Windows Server 2008. But I could not bring it to work on one of our servers. How to do this?
Thankx, Cheers Harry
"However, ever since Windows XP, RDP has supported up to 32bpp color."
up to 24 :)
Out of curiosity: what is your opinion about the assertion that RDP is insecure: http://louwrentius.blogspot.com/2008/11/did-you-know-that-rdp-is-s-secure-as.html ? I know that it refers to rather old versions of the protocol, but there are still NT 4.0 machines out there in production, whether we like it or not, so these issues will be relevant for a long time.
The link for the RDP Performance White paper is broken. Any chance of getting the appropriate link?
Re: I saw "The Aero theme with full glass and 3D effects" also running on Windows Server 2008. But I could not bring it to work on one of our servers. How to do this?
Aero theme support is not available when connecting to Windows Server 2008. It is only available when connecting to Windows Vista as outlined in myth #3 on this post.
"The Aero theme with full glass and 3D effects"
What kind of performance can one expect when using RDP to connect to a Vista machine with Aero when hardware acceleration is not supported? This was one of the future benefits of the Calista technology. I don't see how you can claim this with performance of software rendering of 3D is poor. Due to the lack of hardware rendering we are limited to the abilities of software rendering, which are limited.
Re: last query in the comment stream
The answer to your question is somewhat related to myth #1 outlined in this blog post. The assumption that to do Aero theme in a RDP session on Vista, RDP has to screen scrape and render on the graphics hardware on the remote machine and send giant bitmaps down the wire is not true. Aero glass remoting happens using a client-side rendering technology where the Aero commands are intercepted in the RDP session and sent using RDP dynamic virtual channels over to the client computer and rendered using the graphics acceleration hardware present on the client. So practically the remote Vista computer can have no graphics hardware at all for the RDP session to get Aero glass - this is the case when the remote computer is a Hyper-V based Vista virtual machine which does not have the necessary virtualized graphics hardware; even here an RDP session to this Vista VM can get full Aero glass as long as the client computer has Vista with basic DirectX 9 compliant hardware. Hope this clarifies.
"The Aero theme with full glass and 3D effects" on WinServer 2008 probably not supported but it is working. I have seen it on the "Visual Studio 2010 CTP" which comes preconfigured from Microsoft. Are there any steps one can follow to get this to work on other maschines for testing propose only (not asking for a supported solution)?
Looks like you are asking for how to make Aero glass theme work locally on a Windows Server 2008 - nothing to do with RDP. Please try the following:
1. On the Windows Server 2008, install the Desktop Experience optional feature
2. Enable the Themes service
3. For your user account, go to Control Panel\Appearance and Personalization\Personalization and choose the Aero glass theme
Thank you for your response. It is all well and good that Aero remoting can work (with a Vista client with appropriate hardware) by remoting commands and perimatives, but what about other 3D? How would it work with Virtual Earth, or Adobe Acrobat 3D?
I have a Terminal Server on a server with a business critical application based on Word and a lot of macros. Each time the user types a character the cursor performs many moves to check the context where the character is inserted.
The RDP session slows down, while using pure Word the perofmance is fine.
How can I customize or tune RDP in order to provide a better user experience?
Simple. Run it on Citrix. Even with the improvements to RDP (and it has improved), ICA is still the better protocol.
The link to the whitepaper works for me. What error do you get?
Microsoft's Terminal Services team publishes the first in a two-part series on the top 10 biggest misconceptions about the RDP protocol used by Terminal Services. Along with each tip is a detailed explanation of the real facts. In this first post, Nadim