Top 10 RDP Protocol Misconceptions – Part 1

Top 10 RDP Protocol Misconceptions – Part 1

  • Comments 28

Hi,

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).

clip_image002

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:

· ClearType

· Wallpaper

· 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.

Leave a Comment
  • Please add 4 and 6 and type the answer here:
  • Post
  • i have heard that there is a deliberate 10ms delay in the protocol (at the behest of citrix?) is this true or yet another myth?

  • I'm connecting from Vista 32-bit sp1 Business laptop to a Vista 64-bit sp1 Business desktop. Both have Aero glass enabed.

    Why is that when I RDP from one to another, I'm not getting Aero Glass even though I have all the options turned on in RDP?

    The remote 64-bit desktop has an Nvidia Quadro FX 3700 with 512MB of ram and 8GB of ram, so it should have enough horsepower.

    Is there anything else I am missing?

  • To what OSes will RDP 7.0 be available downlevel? Vista at least?

  • De afgelopen periode was nogal een periode van veranderingen. Zo was er de bijna overname van Sun door

  • When will the Mac RDC client be available for the TSG under Windows Server 2008?

    thanks

    Dan

  • Even with all the improvements to RDP, there are still ways to get even better performance.  Ericom Blaze is a software-based RDP acceleration and compression product that provides improved performance over WAN and congested LANs. Besides delivering higher frame rates and reducing screen freezes and choppiness, Ericom Blaze accelerates RDP performance by up to 10-25 times higher, while significantly reducing network bandwidth consumption over low-bandwidth/high latency connections.

    Ericom Blaze works with any standard RDP host, including VDI, Terminal Servers and remote physical machines.

    You can read more about Blaze and download a free evaluation at:

    http://www.ericom.com/ericom_blaze.asp?URL_ID=708

    Or view a video demo at:

    http://www.ericom.com/blaze_youtube.asp?URL_ID=708

    Adam

  • Hi, this is very nice but I have a question,

    How can I workaround RDP service when it's not working and I can't reboot the server inmediatly?

    I can use remotelyanywhere or vnc, but I want to fix RDP.

  • Printing in RDP is causing huge frustrations.  The drivers are server compliant but a small kb file will spool to many mb's before printing.   Haven't found a fix yet and appears that Microsoft hasn't either. :(

  • ClearType over RDP is a very nice feature, much more needed than all those Aero stuff. But there are certain obstacles before it:

    - It requires a KB946633 hotfix to work on the Win2003 target machine, so you need certain privileges for that;

    - This hotfix requires restart;

    In my case there are up to 100 win2003 machines, which run servers 24/7 and it is rather hard to find time window to reboot.

    And the most major problem - with ClearType on, bandwidth requirements rise up to 3 times higher. In my personal experience, connect drops from almost realtime to uncomfortable slideshow. Correct comparison would be drop from 20-25 FPS in a video game, which is playable, to lower than 10 FPS.

    In the end I had to disable ClearType over RDP. :(

    Blog I referred to:

    blogs.sepago.de/.../bandwidth-requirements-for-cleartype-over-rdp

  • Excellent !!!!  thanks for the info.

  • Where is part II of the Top 10 rdp misconceptions list?  Can someone please either post it here or edit the article with a link for part 2?

    Or both.

  • @jon:  Part 2 is here: blogs.msdn.com/.../top-10-rdp-protocol-misconceptions-part-2.aspx

  • 2008 RDS is slower than 2003 RDS

    There is a definite difference in performance for the exact same process with the exact same software and network setup on 2008 R2 RDS compared to 2003 server. This is even if the 2008 R2 server is a lot higher spec.

    My opinion is it has to do with the GUI interface profile of the app that is running.

    If processes are run that have no GUI influence then there is no performance hit.

    As soon as the app process has any affect on GUI components (form status, messages, graphics etc) then 2008 R2 seems to force the complete process to run slower. This does not occur on 2003 or has far less of a performance hit.

    An easy way to test this is to run the app on the server desktop over RDS.

    - Run the process while viewing the RDS desktop - record the speed for the process to complete.

    - Start the same process and disconnect from the RDS session - i.e. so that it is not being viewed but the session is still active (the process continues to run on the server) - record the speed for the process to complete

    Leave enough time as required to expect that the process has completed and then re-connect to the RDS session.

    The speed recorded for the process when viewing the RDS desktop session will be a lot slower than the exact same process that ran when the session view was disconnected.

Page 2 of 2 (28 items) 12