The most important features aren't the ones you'd expect
Windows terminals are solid-state devices that display applications running on a Windows terminal server. The OS that powers the device might be a form of Windows or a flavor of Linux. The device might offer terminal emulation support in addition to Windows display protocols, as many of the terminals I review here do. (For more information about Windows terminals and protocols, see "Related Articles in Previous Issues," page 124.) Regardless of the local OS or the protocols supported, Windows terminals can display Windows graphical output routed from a Windows terminal server.
Windows terminals make up only about 30 percent of the desktops in the thin-client world. The other 70 percent of desktops are PCs that run a display protocol and thus can run locally installed applications as well as terminal server applications. But Windows terminals have advantages over PCs in some situations. A PC might be too big for the available space, or the environment might not be good for a PC—dust in a warehouse, for example, can damage a hard disk. Or perhaps you need a device that is nearly impossible to break or misconfigure for installation at an unattended kiosk, at a truck stop, or in a library. Whatever the reason, you need to use terminal services, and you've determined that PCs are not a good client for the environment. But how do you choose a thin-client device? When evaluating thin-client devices, you might find that the most important features aren't the ones you'd expect.
Windows Terminal Basics
On the outside, core Windows terminal features include a keyboard, a mouse, and serial and parallel ports. Many newer terminals also have one or two Universal Serial Bus (USB) ports. But you'll need to think carefully about the devices you plug into USB ports. Any device (such as a scanner) that requires a lot of chattering between the client application and output device will bog down the network. So, don't assume that you'll want to plug a particular device into a terminal simply because you can.
10Base-T network connections have been standard in Windows terminals for a while, but 10/100Base-T connections are becoming more common. For logical connections, Windows terminals generally support RDP, ICA, and at least one (and perhaps many) traditional terminal emulation types (e.g., VT100, 3270), so you can use one terminal for all connection types.
The basics of configuring a Windows terminal are simple. Windows terminals use TCP/IP to communicate with the network, so you'll need to specify whether the device will get an IP address from a DHCP server or will have a static address. You'll also need to choose display settings. Most Windows terminals support resolutions of at least 1024 x 768 or 1280 x 1024, and refresh rates of 75Hz to 85Hz are typical. If you change either core configuration option, you'll need to restart the machine. You'll also need to know what you're doing or have a good manual when you set up a Windows terminal because no online Help is available on either Windows- or Linux-based Windows terminals.
Securing Windows terminals can be a problem. One Windows terminal I tested required me to include logon information when I set up a connection to a terminal server. Even terminals that don't require logon information let you include a username and password in the connection settings so that the user doesn't have to provide the information at logon. But if you include logon information in the connection configuration settings, anyone with access to that connection can log on to the terminal server and access any domain resources available to that account. If you choose a terminal that requires logon information in the connection settings, you'll need to physically protect the terminal. Although some terminals include password protection or support smart card readers as an extra layer of security, I generally advise against including logon information in any connection setup unless your environment is completely secure or you give few permissions to terminal users.
A Need for Speed?
How do Windows terminal devices compare on the inside? One of the easiest criteria to isolate is CPU speed. Faster is better, right? Well, yes and no. Having a fast CPU isn't a bad thing, and thin-client devices that perform local processing benefit from more power. However, because of the way thin-client devices work and because of what they're designed to do, CPU speed isn't as important as some other factors. You can't evaluate a thin-client device by using the same criteria you would use to evaluate a PC because a Windows terminal doesn't do a PC's job and operates in an environment different from that of a PC. In a thin client's simplest form, the device is an extension of the terminal server with a remote display. When you understand how Windows terminals work and what they do, you can clearly see why CPU power isn't the main determinant of performance in most present-day terminals—and why CPU power might become more important as the standards for Windows terminals change.
Whether you use RDP or ICA with terminal services or you use a terminal emulation package that shipped with your thin-client device, the method of getting graphical data from the server to the client is approximately the same. When you connect to a terminal server, the server assigns a session to you and identifies it internally. Any application you run from that session is associated with the session so that what you do with your application doesn't affect the same application running within other users' sessions. The terminal server's monitor doesn't display the application output for any session except the console session. Instead, the display driver for the remote session downloads to the client the commands needed to show application output, window resizing, text input, and so forth. In the other direction, the session's client uploads mouse clicks and keyboard movements, which the terminal server interprets only for that session. As you might guess, remote sessions use different video and client I/O drivers than does the console session because the remote-session data takes a different path from the console data. (You don't need to load extra drivers—they're part of terminal services.)
On the client end, all you need to manage the connection to the terminal server is a network interface so that the Windows terminal and terminal server can communicate, video support and a monitor so that the client can render and display the output, and a CPU to process the network and video data. If the client uses a device connected to its local serial, parallel, or USB port, the display protocol also transports the information needed to make that client-side device work with the terminal server session. Thus, the terminal's key innards are the network interface, the video logic, the memory for storing data, and the CPU. About 70 percent of Windows-based terminals (WBTs) use National Semiconductor's layout. This layout divides key system components into two groups connected by a PCI interface that also interfaces to the network card. One group of components performs number crunching, and the other group carries out data I/O.
Basically, the path from the Windows terminal to the terminal server starts with the PCI-based network connection. When the network delivers data to the Windows terminal, the network card passes the data through the PCI interface to the group of number-crunching components, which includes the CPU, memory controller, bus controller, video generator, and SDRAM. As the video generator creates graphical output, the video generator passes the output to the display module on the terminal (I/O) side, which is where all port interfaces are located. Currently, motherboard speeds range from 66MHz to 83MHz, with 83MHz being most common. (Keep in mind that CPU speeds are separate from motherboard speeds.) Although 100MHz motherboards should become available this year, they will likely appear only in the few higher-end Windows terminals that are intended to do more local processing (such as the processing that CAD programs require), not in models designed to replace text-based terminals.
Because the terminal's primary job is to display output generated on the terminal server, the critical parts of the data path are those to the network controller and the video generator. If these paths are slow, the device will be slow. Certainly, the more information transferring between client and server, the more work the CPU has to do. However, when you're talking about a 200MHz CPU responsible only for helping to process incoming and outgoing network data and doing any work that a graphics accelerator can't handle, the demands aren't great. Video and network interface speeds are more important to device performance than is CPU speed, and in general, total performance on the Windows terminal depends more on server load and network throughput than on client-side performance.
I don't mean that CPU speed is never important. When devices have locally installed applications, such as Web browsers, CPU speed makes a difference just as it does in the PC world. As you'll see in the following reviews, a few Windows terminals have locally installed Web browsers. With time, more such terminals will appear—the newest specifications for Professional model Windows terminals include the option of installing a local copy of Microsoft Internet Explorer (IE) 5.0 and Windows Media Player, and Linux-based thin-client devices often include a locally installed copy of Netscape Navigator. Microsoft's next version of the specification for Standard WBTs will permit OEMs to include a Windows CE-compatible version of IE 4.0 on the device. Local application support isn't limited to browsers, either: You can customize Netier Technologies' NetXpress SL2000 to include just about any locally installed application you want. In fact, some thin clients are getting decidedly chubby, moving from lean and mean to solid-state PC wannabes.
On thin-client devices that don't run locally installed applications, however, CPU speed is much less important to overall performance. Congestion at the server or network level is likely to have a far greater impact on Windows terminal performance than the terminal's overall performance is, and video and network driver efficiency is likely to be more important to client performance than CPU speed is. In the past, many Windows terminals manufacturers used proprietary OSs on terminals. But when Windows CE became available (appearing on terminals in mid-1998), the trend reversed toward using readily available standardized OSs. The reason for this change isn't hard to determine: As one OEM told me, hiring developers skilled in a proprietary OS is much harder than hiring developers skilled in a widely used OS. These days, you have three main choices for the OS in a thin-client device: embedded Windows NT, Windows CE, and Linux.
Choosing an OS
A Windows terminal's OS, its drivers, and the display protocol the device uses to communicate with the terminal server for a session have more influence on the device's performance and ease of maintenance than the hardware does. First, the terminal's OS influences which drivers are available. Second, the OS determines the setup and configuration interface—or at least whether it will follow a standard.
Any Windows terminal powered with embedded NT or Windows CE must conform to Microsoft's model for Windows-based terminals. WBT Standard terminals use Windows CE and don't support locally installed applications. (WBT Standard 1.5, which Microsoft announced in January and will make available before second quarter 2000, will permit a locally installed copy of IE 4.0 for Windows CE.) WBT Professional terminals use embedded NT and may optionally include a locally installed copy of IE 5.0 (or another browser) and Windows Media Player. To be sold as a WBT, neither type of terminal can support any devices, such as floppy drives, that aren't part of the standard. Additionally, OEMs must follow a particular design when creating an interface for a terminal's configuration and session setup tools. OEMs can add to these interfaces, but the basic tool layout must always be the same.
Linux terminals don't have these restrictions. A Linux terminal can include any device that its manufacturer deems necessary or desirable, and the OEM can decide how to design the terminal's interface. However, this flexibility means that Linux terminals are less predictable than their Windows-based cousins. If you can set up one Windows CE-based terminal, you can set up another one without having to think much about it—even if the options vary, the basic information required and the manner of displaying it are the same across all similar devices. If you know what information you need to connect a Linux terminal to the server, you can figure out how to make the connection, but you can't go to a different Linux terminal and automatically know the location of all the tools. These differences, combined with a poor user interface (UI) and lack of management tools, made setting up the two Linux-based terminals I tested a chore.
Finally, the OS your terminals use can influence the types or quality of display protocols available to you. As of November 1999, the restriction on RDP working with non-Windows clients ended and a Linux-compatible version of RDP became available. However, RDP isn't on all Linux boxes. When RDP does appear on Linux terminals, it's RDP 4.0, which doesn't support all the functionality of RDP 5.0, used with Windows 2000 (Win2K). Furthermore, the Linux version of RDP doesn't yet work all that well. Although Linux's RDP might improve by the time you read this, for the time being, I'd skip the Linux RDP clients and use ICA instead.
Is Performance Important?
As I've stated, CPU speed isn't a key factor in differentiating Windows terminals, and neither is the locally installed OS. The speed of the client's network interface and video generation matter more, but the network speed and server load overshadow even these factors in real-life performance. However, when you eliminate factors such as network congestion and server load, the performance differences between devices can be significant.
To evaluate the performance of thin-client devices I cover in this review, I tested them with BAPCo's SYSmark 98 and recorded the time each device took to complete the application benchmark tests for Netscape Navigator 4.05; Microsoft Excel, Word, and PowerPoint; and Adobe Photoshop 4.01. For consistency, I ran these tests on a nearly unused network segment and on a dual 300MHz Pentium II terminal server with 128MB of RAM that was supporting only NT Server 4.0, Terminal Server Edition (WTS) with Service Pack 4 (SP4), Citrix MetaFrame 1.8, and one session running one benchmarking tool. The benchmarks ran through a series of tasks common to each application. I used the ICA display protocol for the tests because the devices had only that protocol in common. I ran all the tests at 800 * 600 resolution. Table 1, page 122, shows my results.
Looking at the benchmarks in Table 1, you might immediately assume you should avoid Neoware Systems' NeoStation 2300 because it was the slowest in the tests. However, I caution you against making a purchase decision based solely on performance. First, the tools available for a given Windows terminal will make a big difference in the time you spend to update and manage the terminal. At press time, several vendors were developing remote-administration tools, but tools were available on only a few of the terminals I tested. Second, when you use one of the slower terminals (as opposed to running a benchmarking tool against a stopwatch), the terminal feels little different from other devices that completed the tests more quickly. Apart from the fact that you don't type as quickly as a benchmarking tool, the influences of server and network responsiveness mute these performance results. If you stress the server a bit and add some network traffic to the segment, the numbers won't mean as much. When all other factors are equal, some terminals will be faster than others, but you'd be making a mistake if you considered only performance when choosing a Windows terminal.
Instead of focusing on how quickly a device can draw pictures, think about the requirements it needs to fill. Some Windows terminals support only 10Mbps networks; others support both 10Mbps and 100Mbps. Does the device you're considering support the network speed you need? Consider performance, but also think about where the terminal will fit—physically and logically—into your organization. Will you be using the terminal in an environment in which PCs aren't practical? Does the device's form factor work in your situation? What kinds of management tools are available for the device? Does the terminal have the port types (e.g., COM, LPT, USB) you need? Are the terminal's plugs and power connections easy to reach? How quickly is the terminal available when you turn it on? Finally, how would you feel about plugging in several hundred of the devices?
Results
The reviews that follow look at nine Windows terminals and help you evaluate the offerings. Table 2, page 122, compares these terminals' features. After examining the devices, I came to some general conclusions about the offerings.
The only two Linux Windows terminals available for this review were Boca Research's BocaVision JNC205 and the Thinworks e3000. I'd hoped to have a wider sample of Linux-based terminals, but Wyse Technology canceled production of its Linux terminal in favor of a device that uses embedded NT, and Netier Technologies' device wasn't available in time to review. The disappointing news is that, based on my sample, Linux Windows terminals aren't yet ready for prime time. I know I'll hear from dissatisfied readers about this conclusion, and I wish I could report that Linux terminals were as fast and well designed as the best Windows NT- or Windows CE-based devices. However, my evaluation of the JNC205 and the Thinworks e3000 shows that Linux Windows terminals still have rough edges.
Linux's RDP protocol is slow, and its graphical portion is shaky. Unlike native RDP, which runs on Windows only, Linux RDP can't use the client OS's graphical capabilities, and so will remain slower until developers streamline the protocol. Even when the devices use ICA, their performance is no better than average. And the poorly designed interface can make setting up ICA connections painful. (Of the Linux-based terminals I evaluated, I'll take the text-based menus over the Windows-like GUI.)
The devices also tend to be big and heavy, which isn't necessarily a problem but does mean that Linux terminals are less space-efficient than a Windows CE-based terminal that can stand up next to its monitor. Neither type of device has centralized administration tools available. In short, the Linux terminals look like the Windows CE-based terminals of a year or so ago. The one advantage the Linux devices might (but don't always) have is cost. Although you'll need to provide a mouse, keyboard, and even a power cord, at $375 the Thinworks e3000 is inexpensive because the OEM doesn't need to license the OS. However, a couple of the Windows CE devices are almost as economically priced, and they have the peripherals the Thinworks e3000 doesn't have.
Removing the Linux devices from the picture leaves one NT-based terminal and six Windows CE devices in the group I evaluated. The Windows CE devices were fundamentally similar, but a few stood out. If you work with Network Computing Devices' NCD ThinPATH products (which can manage both PCs and the NCD ThinSTAR Windows terminals), you'll need the NCD ThinSTAR 400, which has a good design in most ways and performs well. Readers looking for a true bargain in terms of feature set and cost will like Boundless Technologies' Capio 325.
I really liked Wyse's Winterm 3320SE in many different ways, though. Its display isn't quite as high-quality as some of the other devices, but it's perfectly usable, and the terminal's security and reliability features make it attractive, particularly if you access a terminal server from across a WAN. As a general rule, when evaluating WBTs, look for features that enhance their usability (such as high-quality graphical output), security, or ease of management.