The Lab Guys run the stopwatch on ICA and RDP
Once, when I was a kid, I saw a series of stark black-and-white billboards proclaiming Speed Kills. Although I'm not admitting what year that was, speed was a popular drug of choice at the time. Speed addicts, commonly referred to as speed freaks, were dropping right and left from overdoses. I always liked the message on those billboards; it was short, sweet, and to the point.
The same message applies to today's thin-client technology, although it has a slightly different play (I doubt anyone will fall over dead after using a product that's too fast or too slow). Specifically, Speed Kills describes the contention between two competing thin-client implementations: the Citrix Independent Computing Architecture (ICA) client and the Microsoft Remote Desktop Protocol (RDP) client. If one of these clients (or the underlying protocols) has a significant speed advantage over the other, the slower client will die, be buried, and soon forgotten.
Why is speed so important to this market? In thin-client technology, a central server pushes all the bits that make up the desktop display over the network to the client. For example, when you start, resize, or stop applications on the desktop, the server must push all the affected bits to repaint the thin-client screen. As you can imagine, moving display bits takes more than a spoon's worth of network bandwidth (more like a couple buckets).
Because the client/server interaction is so bandwidth-intensive, client efficiency is extremely important. Conventional wisdom states that in a LAN environment the ICA client and RDP client offer similar performance. In a WAN environment or in a dial-up environment, the ICA client offers
better performance than the RDP client because Citrix developed the ICA client implementation for low-speed modem connections.
Now that you have the big picture, you can examine each client in detail, which gets foggy. For example, the ICA client supports sound and the RDP client doesn't. Keep in mind that delivering sound requires more bandwidth than not delivering sound. Similarly, the ICA client for 32-bit Windows can cache icon bitmaps, which in theory speeds up screen operations. The RDP client for 16-bit Windows and the RDP client for 32-bit Windows can't cache these same bitmaps.
Another complicating factor that affects performance is the operating system (OS) each client runs. For example, an ICA client running on a terminal with a proprietary OS might be faster than an ICA client running on a Windows Consumer Electronics (CE) terminal. Similarly, an RDP client running on a Windows NT or Windows 95 terminal might be faster than an RDP running on a Windows CE terminal. As you can see, comparing the speed of different thin-client implementations gets ugly fast.
A Test of Speed
The Windows NT Magazine Lab is on course to answer the litany of performance questions relating to the ICA client and protocol, and the RDP client and protocol. We'll explore the relative performance of both clients and both protocols under different network speeds, different client loads, and different client configurations. Unfortunately, these complicated tests take time to perform.
I do want to address one question immediately: Which client implementation is best for low-speed links? To answer this question, I performed one-on-one client/server tests to examine the relative efficiency of the ICA client versus the RDP client.
Specifically, I set up a Wyse Winterm 3000 Series terminal (running Windows CE) and a 166MHz Pentium PC (running Win95) in our small office/home office (SOHO) lab. The PC connects to our enterprise lab via an ISDN link. In the enterprise lab, I set up a 200MHz Pentium server running NT 4.0, Terminal Server Edition and Citrix MetaFrame. To prevent other traffic from getting in the way, I connected my ISDN router to the server using switched Ethernet and ran the tests late at night when the other Lab Guys were sleeping.
To be fair to all parties, I defined four connection configurations between the client and the server:
- An ICA connection with no compression and no sound
- An ICA connection with compression and no sound
- A standard RDP connection
- An RDP connection using the low-speed option
I set up all four configurations on both the Winterm terminal and the PC in the SOHO lab. I also disabled sound support and icon caching on the ICA clients because the RDP clients have no comparable options.
For the core test, I displayed, closed, and redisplayed an 800 * 600, 256-color image. I ran the test in full-screen mode and in partial-screen mode. I ran this test using the four configurations I listed above on both the Winterm and the PC at speeds of 64Kbps and 128Kbps. During each test, I timed how long the screen image took to appear.
I calculated my results in seconds and tenths of seconds, so smaller numbers are better. Because I was timing each redraw by hand, my margin of error is approximately plus or minus 0.01 second. I ran each test three or more times to verify that my timing was accurate and averaged the test runs to obtain my final results. I must admit, the results surprised and fascinated me.
Full Screen Ahead
My first set of tests involved drawing and redrawing a full screen of information over a 128Kbps link. I created the screen by copying and pasting a Windows desktop into a Windows bitmap file. I then used Polybytes' Polyview graphics program to display the file in full-screen mode. These tests simulate starting the desktop environment, starting full-screen applications, and switching between full-screen applications, which is where the redraw performance applies. I began my test on the Wyse Winterm terminal, as Table 1 shows.
Based on the results in Table 1, the RDP client offers better performance for full-screen draw and redraw operations. Table 2 shows what happened when I repeated the test on a Win95 PC running the ICA and RDP clients.
In the case of Table 2, the ICA client lost even more ground, making the RDP client look even better. Next, I looked at the full-screen draw and redraw numbers again, but slowed the link to 64Kbps. At this slower speed, the ICA client running in compressed mode closed the gap with the RDP client running in low speed, as Table 3 shows. The RDP client had a slight advantage because of its redraw speed. I quickly recognized that the RDP client has a better cache-to-screen processing algorithm than the ICA client. Table 4 shows that the Win95 PC provided similar results.
As Table 4 shows, the RDP client running in low speed was a clear winner. As an aside, I found myself scratching my head wondering why the ICA client for 32-bit Windows is less efficient than the ICA client for Windows CE (you might think the results would be the other way around).
Size Does Matter
By now, I can hear you muttering, "Where's ICA's alleged speed advantage?" ICA's speed shows up big when you draw and redraw a window on the desktop (as opposed to redrawing the entire desktop). To test this type of performance, I used Polyview to draw and redraw my test graphics file in a partial window.
Once again, I began my tests on the Winterm terminal running over a 128Kbps link, as Table 5 shows. Based on the results in Table 5, the ICA client easily outperforms the RDP client for the initial draw. More important, the ICA client is redrawing from cache to obtain these fast redraw speeds, and the RDP client is not--ouch! This same trend held true in the 32-bit Windows environment, as Table 6 shows.
Holy bottleneck, Batman! The results in Table 6 indicate that the RDP client has a problem. Do the RDP client results get worse at a lower speed? You bet your Batarang they do, as Table 7 shows. As you can see in this table, both the ICA and RDP clients naturally slow down as the link slows down. However, the ICA client maintains crisp redraw times, and the RDP client does not. Table 8 shows that this trend is also present in the 32-bit Windows environment.
Death to the Vanquished?
Based on my testing, I conclude that the ICA client is better than the RDP client for low-speed links if--and this is a big if--you run a mixture of full-screen and partial-screen applications. You might also see an advantage with the ICA client if you run a full-screen application that opens and closes subwindows. However, if you run all your applications in full-screen mode, you might never see the ICA client advantage.
During my testing, I noticed one operational difference between the ICA client and the RDP client. The RDP client draws directly to the screen as the data comes in (i.e., you see the server paint the screen in raw blocks as the display information comes across the network). The ICA client takes a different approach and buffers the information from the server until it completely renders the screen and quickly slaps it up for display. This method often leaves you looking at a paused or blank display while the ICA client composes the next display. I suppose my response is purely emotional, but I preferred the ICA client approach. Watching the RDP client approach (i.e., the screen creeps in as a series of blocks) only reminded me how slow the link was.
These tests just scratch the surface of ICA client versus RDP client matters. Stay tuned as the Windows NT Magazine Lab examines other aspects of these two clients and their related protocols in future tests. For now, neither client kills the other in speed, although my testing makes the RDP client look pretty bruised.
Previous
