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:

  1. An ICA connection with no compression and no sound
  2. An ICA connection with compression and no sound
  3. A standard RDP connection
  4. 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.

NT and the Financial Connection
Windows NT Server 4.0 is the new darling of IS at Nasdaq, but NT Server 4.0 at the Chicago Mercantile Exchange (CME) is a very different story, although both implementations are in the financial community. Nasdaq publicly praises NT because of its Web publishing prowess. Representatives of Nasdaq's IS department like NT's ability to effectively and reliably support the estimated 13 million hits a day that the NT-powered Nasdaq Web site (http://www.nasdaq.com) received. In fact, Nasdaq is so impressed with the NT computing model that it has migrated all corporate users to NT Workstation. A staff of 15 supports the site, and many Nasdaq member companies have expressed their satisfaction with the new site and its impact on their visibility.

In contrast, at the CME, the IS staff is ripping out the existing NT and OS/2-based server infrastructure, replacing it with a combination of NetWare 5.0 over TCP/IP and Novell ZENWorks systems management software. The main goals are to reduce network delays and increase trading speed. The CME's staff says both of these goals are attainable even though their upgrade project calls for fewer servers (12 to 14 NetWare servers will replace 20 NT servers and 40 OS/2 servers). According to CME, NetWare scales better for their needs and can handle more users. They believe these capabilities will translate into better performance.

These stories reveal a trend in how enterprises are deploying NT. NT is proving popular for less critical jobs such as Web serving, workflow applications and e-commerce, and systems such as NetWare continue to be the choice in areas where the business logic is most sensitive, such as in IT's backrooms and glass houses.

Case in point: Dell's Web site (http://www.dell.com) is a marvel of NT and Active Server Pages (ASP) development. The combination of a slick layout and some clever custom programming (such as the particularly impressive Configurator object) has made Dell's site the perfect showcase for Microsoft technologies.

However, the Dell NT façade runs only skin deep. Behind all those pretty Web pages is a classic big-iron solution: a Tandem non-stop system serves as the heart of the company's order processing and tracking infrastructure. In the world of www.dell.com, NT is simply the gatekeeper. A mission-critical, bet-your-business platform is doing the real work.

In my opinion, as more and more anecdotal data comes in from the field, the CME and Dell solutions begin to look like the norm for NT. Microsoft has its work cut out if NT is going to compete in the big leagues of business process automation, and NT is Microsoft's bet for the future.


Microsoft Installer as Killer Application
Many IS professionals consider Active Directory (AD) and IntelliMirror to be the most compelling features of Windows NT 5.0, but these technologies pale in comparison to the Microsoft Installer service. Microsoft's demonstrations of policy-based application distribution with NT 5.0 usually begin with an administrator assigning a shortcut to a user or group of users defined within AD. A link appears on their desktops or in their Start menus as a result, and the link can trigger the application's installation procedure. The link can be to an executable file (part of an installation package) or to a file that has no local association (and thus causes Windows to search for a suitable application to handle the file via the Extended Class Store, triggering the installation process).

Regardless of how the event is initiated, the AD hands off the management of the installation to a specialized service, Installer. Without Installer's ability to download an application in the background and dynamically configure it for immediate use, the concept of network-based install-on-demand would break down.

IntelliMirror is another key NT 5.0 feature that depends on the Installer service. (For more information on IntelliMirror, see "Influential Products of 1997 and Predictions for 1998," January 1998.) IntelliMirror can reproduce a user's desktop and personal folders on any NT Workstation 5.0 system in the network. It replicates the user's profile settings from a server-based copy and then uses Installer to dynamically download and configure the user's applications as the user accesses them.

Installer is the linchpin of Microsoft's total cost of ownership (TCO)-reducing mechanisms. (See "NT 5.0 TCO/ZAW Update," page 157.) However, the Installer service has its limits. For example, for Installer to support a legacy application, the application must include a setup script compatible with the service.

The only Installer-aware applications that are close to release are components of Microsoft's Office 2000 suite. At last report, Office 2000 was scheduled for a February 1999 release. Microsoft will bundle an NT 4.0-compatible version of Installer with Office 2000. Because NT 4.0 doesn't support AD or IntelliMirror, this bundled version will be limited in scope but will give organizations a chance to familiarize themselves with the principles and underlying architecture of Installer.

Installer has the potential to revolutionize the way you deploy client applications. It is Microsoft's long-term answer to the network computing challenge and deserves serious attention from IS organizations of all sizes.


SBS Suites Come into Their Own
One reseller described Microsoft's BackOffice Small Business Server (SBS) by saying, "It's like Microsoft Office for your server." With overall server operating system (OS) sales growing at a rate of 15 percent per year and eager resellers targeting the underdeveloped small-business market, SBS could be the right product at the right time.

Even Microsoft seems surprised by the success of SBS. The combination of price, functionality (SBS includes full-blown versions of the core BackOffice components), and a well-defined upgrade path is doing particularly well in small to midsized businesses. The suite is so popular that Microsoft is hurrying to update it with additional licensing options and revised components. SBS 4.5, which is scheduled to ship in first quarter 1999, will include updated Exchange Server 5.5 and SQL Server 7.0 installations and licensing for up to 50 users.

SBS's success is attracting other vendors to this previously neglected market. Novell is preparing a new version of its small-business bundle. NetWare for Small Business 4.2 includes similar features to Microsoft's SBS, including integrated messaging (GroupWise), a database (Oracle), and a Web server (Netscape Fastrack).

Feature for feature, the two offerings look competitive. SBS consists of the mainstream Microsoft BackOffice suite--SQL Server 6.5, Exchange Server 5.0, and Windows NT Server 4.0. SBS is a tightly integrated solution. As with any BackOffice deployment, NT security applies to all the participating components, providing a cohesive, single-logon environment that is designed to be easy to maintain and upgrade.

Novell's NetWare for Small Business is a true best-of-breed configuration. It features a variety of third-party tools that, while competitive in their respective market segments, were never designed with suite integration in mind. This adds a level of complexity to the overall licensing and upgrade process. For example, customers can license NetWare for Small Business for up to 50 users, but they must purchase extra licenses for the bundled Oracle database separately. The version of Oracle that ships with NetWare for Small Business includes five client licenses. If customers want more licenses, they must buy them directly from Oracle (or their local Oracle reseller) regardless of how many NetWare licenses they purchase.

Exactly this sort of integration makes SBS successful in the small to midsized business arena. The suite lends itself to many convenient bundling and packaging scenarios as Microsoft's BackOffice. In contrast, customers who buy into a best-of-breed solution--like Novell's--must weigh the benefits of individual component superiority against the added complexity of managing multiple vendor licenses.

The small-business marketplace has traditionally been won or lost based on two factors: usability and overall value to the customer. Microsoft has its bases well covered with SBS, and barring a major development by another player, should continue to dominate this segment. Small-business customers can interpret this to mean that SBS is a sound investment.

NEWS COMMENTARY
Windows NT 5.0 is Now Windows 2000
As Windows NT receives serious consideration in enterprise environments, Microsoft has decided to remove the "NT" from Windows.

What if one day, Toyota (Windows) decided it had too many brands and decided to eliminate its Lexus (NT) brand. At first, Lexus owners would say, "I don't care what it's called. I have a quality vehicle." However, the Lexus dealers would be irate. These dealers sell a Toyota differently from a Lexus, market the two brands differently, and target different customers. Instead of selling the new cars as "Toyotas," dealers find themselves positioning the former Lexus line by saying, "I know it's called a Toyota, but it really is a Lexus." Selling Toyotas, the dealers find it hard to charge the margins they were getting for a Lexus.

Microsoft is changing the name of Windows NT 5.0 to Windows 2000
Next thing you know, the resale value of a Lexus drops by thousands of dollars. The blue book values a Lexus similar to a Toyota. Now, the current Lexus customers become irate. People who never understood the value of a Lexus are starting to buy the new Toyota (formerly Lexus) car and are shocked by the cost to maintain the vehicle and the price of add-ons. "How can they charge that kind of money? It's just a Toyota!" customers say. Previous Lexus owners try to communicate the value of a Lexus, but the effort falls on deaf ears.

Toyota hoped that combining the Lexus brand with the Toyota brand would lift the Toyota brand. Unfortunately, the renaming was like putting a drop of red food coloring into the ocean and wondering why it didn't turn the ocean red.

Microsoft is changing the name of Windows NT 5.0 to Windows 2000, and adding the tag line "Built on NT Technology." Windows NT Workstation 5.0 becomes Windows 2000 Professional, Windows NT Server 5.0 becomes Windows 2000 Server, and the Enterprise Edition becomes Windows 2000 Advanced Server. Microsoft will also add a new 64-bit very large memory (VLM) version called Windows 2000 Datacenter Server, which will address 64GB of physical RAM and 16 CPUs.

Why is Microsoft changing NT's name? Professionals who use NT have always known that NT is not Windows and equate the name "Windows" with Win3x/9x. Following Microsoft's decision to migrate all Windows users to NT, Microsoft insiders began to fear that the "Windows" brand would die with Windows 98. Microsoft's success hinges on the Windows brand. Therefore, changing the NT name to Windows 2000 ensures the continuation of the Windows brand.

There's an old saying: "If it ain't broke, don't fix it." In this case, NT was not broken. In fact, the Windows brand was broken, and Microsoft is using NT to fix it. Microsoft has been known to say, "If you don't know why you need NT, then you don't need it." But now, Microsoft is sending all Windows users the message that they need NT regardless of the reason. The name Windows 2000 hides this sophisticated OS's complexity, whereas, the name NT promoted the complexity and its power.

This change in strategy opens NT to a whole new wave of users who have no idea what "Built on NT Technology" means. The bottom line is that people who don't know NT won't care. The naming progression will seem logical: Windows 95 becomes Win98, which becomes Windows 2000.

Good Move?
Clearly, Microsoft will benefit from the name change. Microsoft benefits from this name change by alerting people when their OS is not the latest release available. The naming strategy illustrates planned obsolescence at its finest. Naming the OS after the year is like building a car with the model year painted on the outside: When you buy that car, everybody knows if you're driving an old model. Similarly, by the year 2001, that old Win98 will seem tired. Everybody will want an upgrade.

But what about those home users who don't understand the NT technology that their OS is built on? Will the home users' old DOS programs and devices run? Will home users look up their new peripherals on the Hardware Compatibility List (HCL) before trying out Windows 2000? No way.

It will be a fun day when home users try to use NT--I mean Windows 2000. So what will Microsoft do to help these millions of home users? Will Microsoft sacrifice reliability for compatibility? Will Microsoft eliminate NT's security? Will Windows 2000 Home become "NT compromised?" The answers to these questions are important.

Wag the Dog?
I thought it was interesting the way NT became Windows on the day of Bill Gates' taped testimony during the Department of Justice (DOJ) trial. Before the name change, NT was not part of the trial. Now Microsoft has made NT part of the investigation.

Gates has said that the software industry needs the freedom to innovate. Surely, Windows 2000 can be an innovative extension of Windows. In addition, this move sends a message to the DOJ: Microsoft has moved on. By the time the DOJ can do anything about Win98, it will be a legacy OS, and irrelevant. Windows 2000 is the new game in town.

The new naming scheme also changes the nature of how to quantify market share. Windows has the largest market share on the desktop. But what happens when you put the server market into the mix? "The new naming system eliminates customer confusion about whether 'Windows NT' refers to client or server technology," said Brad Chase, author of the new naming system. Is it possible that the Department of Justice would look at the entire market for Windows, client and server, and declare that Microsoft does not have a monopoly? I doubt it, but the gamble is worth a try.

Upgrade or Downgrade?
There were a couple of things in Microsoft's press release that puzzled me: "Windows 2000 Server (formerly Windows NT Server 5.0) will support up to 2-way symmetric multiprocessing (SMP.) Existing Windows NT Server 4.0 systems with up to 4-way SMP can be upgraded to Windows 2000 Server." However, Microsoft's Group Manager of Enterprise Marketing, Ed Muth, explained that the price of Windows 2000 Advanced Server will be "significantly lower" than the price of its predecessor, Windows NT 4.0 Enterprise Edition. This pricing strategy will encourage more companies to adopt clustering and Web server load balancing. New users who want four CPUs will need to buy Windows 2000 Advanced Server. Today, people buy the equivalent Enterprise Edition to get clustering support. Assuming a similar pricing strategy to today's, 4-way systems just got a lot more expensive.

Another puzzler is the Datacenter version of Windows 2000. This new version is worthless without a set of applications written to handle the extra capacity. My guess is that SQL Server 7.0 will probably have a Datacenter version that will support the new version's 64GB of RAM. Imagine a large database almost entirely in RAM. You're bound to get some impressive performance out of that capability, but you'll want to make sure that any add-ons or changes are written to disk.

This capacity could be a boon for large data warehousing applications and for system vendors who want to create the hardware to run these applications. "We're ecstatic about the Datacenter announcement. It's right where we want to be," said Michel Gambiet, director of Microsoft partnership at Sequent. At this point, Sequent might be the only server manufacturer that can make a 16-way, 64GB system. So for now, Datacenter gives Sequent a unique market position. But it will be a long time before any applications take advantage of a 16-CPU server. The best I've seen so far is 6-way application scalability with performance falling off dramatically after the sixth CPU. Time will tell.

Howdy Partners
At the recent Microsoft Professional Developers Conference, Bill Gates declared that 60,000 applications would run on NT 5.0 by the time it shipped. Of course, he included every DOS, 16-bit, and 32-bit program that runs on NT. I think the number will be less than 10,000 applications that will run natively on Windows 2000. Even so, that number represents a lot of Microsoft's partners that will need to change their branding strategy around the name change. These partners have spent millions positioning NT as a platform for the next wave of enterprise computing. Will that equity in the NT brand transfer automatically to Windows 2000? Did Microsoft even consider its partners and the amount of money this change would cost them?