Bandwidth Requirements for ClearType over RDP

In an earlier post I wrote about a great technology that finally makes it into terminal services with Windows Server 2008: ClearType or Font Smoothing, as it is sometimes called. I will stick to the term ClearType for the time being.

ClearType greatly enhances the display of fonts on the nowadays prevalent LCD screens. By adding support for ClearType in version 6 of the RDP protocol Microsoft bridged part of the gap that still separates terminal services from desktop PCs in terms of functionality and appearance.

There is, however, a downside to enabling ClearType over RDP: more bandwidth is required between terminal server and client. To understand why you need to know that RDP without ClearType uses a very efficient method for transporting font information called glyph caching. For those of you who do not know what I am talking about (a few days ago I did not have a clue what a glyph is, either): glyphs are essentially bitmap representations of characters. The RDP protocol contains optimizations that minimize the number of times glyphs need to be transferred over the network and a special glyph cache stores transmitted glyphs on the client device.

If ClearType over RDP is enabled the glpyh caching mechanism cannot be used – characters have to be transferred as ordinary bitmaps. Since this is less efficient the required bandwidth increases. But by how much? Depending on the amount of additional overhead enabling ClearType might be a no-brainer or necessitate thorough planning.

Measuring the Impact of ClearType on Bandwidth

In order to shed some light on this I set up a simple test scenario using the following environment:

Server: Windows Server 2008 June CTP
Client: RDP6 on Windows XP SP2
Session: 1024×768 @ 16 Bit

I created an AutoIt script which I put in the test user’s startup folder. The script basically starts notepad, types in some text (my earlier post on ClearType) and then ends the session by logging off. The first two script commands increase the delay between keystrokes in order to match human typing speeds.

This is the script used (text removed to enhance readability):

AutoItSetOption ("SendKeyDelay", 90)
AutoItSetOption ("SendKeyDownDelay", 10)
Run("notepad.exe")
WinWaitActive("Untitled - Notepad")
WinSetState("Untitled - Notepad", "", @SW_MAXIMIZE)
WinActivate("Untitled - Notepad")
ControlSend("Untitled - Notepad", "", "Edit1", "Much text here...")
Sleep(5000)
WinClose("Untitled - Notepad")
WinWaitActive("Notepad", "&Save")
Send("!n")
Sleep(1000)
Run("logoff.exe")

This screen shot shows the script in action:

Test Procedure

1. Delete the RDC (Remote Desktop Connection) cache, located in %USERPROFILE%\Local Settings\Application Data\Microsoft\Terminal Server Client\Cache
2. Start a pre-defined Performance Counter Data Collector in an admin session on the terminal server
3. Use RDC to connect to the terminal server. The test script is started by a link in the user’s startup folder. As the last command the script logs the user off.
4. Stop the pre-defined Performance Counter Data Collector in an admin session on the terminal server

I executed above test procedure three times both with ClearType enabled and disabled, and then analyzed the total amount of compressed bytes sent over the network between the terminal server and the client.

Test Results

From the collected data I created graphs that show the bandwidth used during each test. The following two images exemplarily depict the results of the second test iterations:

With ClearType disabled the average bandwidth used per test was: 268, 266 and 258 Bytes/s. Enabling ClearType raised those numbers to 883, 882 and 883 Bytes/s.

These numbers show two things: for one, the variation between the individual tests is low, indicating that the measurements were not affected by other factors. Secondly, it is startling to see that ClearType more than triples the number of bytes transferred (the increase is by 335%, to be exact).

What does all this mean in practice?

I only examined a very simple scenario in which most of the bandwidth consumed stems from text being typed into an empty window. This allows for isolating the increase in bandwidth caused by ClearType. In real-world scenarios, though, most of the bandwidth used by RDP is taken up by windows containing images and text. Thus the percental increase in bandwidth will in practice be much lower than the 335% I observed. Exactly how much more bandwidth is required depends, as always, on your individual application mix and usage pattern.

Conclusion

Enabling ClearType over RDP certainly increases bandwidth requirements. While the increase is negligible in a LAN it may just be the straw that breaks the camel’s back over slow or heavily used WAN links. I recommend you conduct your own tests prior to using this great new feature of Windows Server 2008.

In this test scenario I did not examine how latency is affected by ClearType over RDP. That may a topic for a future post.

Additional information:

Terminal Services Team Blog – ClearType in Remote Desktop
Remote Desktop Protocol (RDP) Features and Performance