One issue to consider when setting up a Thin Client system is the size of the Server. Since all of the applications will be running on this machine, it is vital that it be big enough - but since cost is always a factor it is important that it not be unnecessarily oversized. Like the dilemmas faced by Goldilocks, the correct server is not too big, not too small, but just right.
In a discussion about server sizing for Windows 2000, Microsoft makes the following statement:
"For adequate performance, a Terminal server requires a Pentium or higher processor. A Terminal server requires a minimum of 128 MB RAM, plus additional RAM for each user to support running each user's programs on the server. An additional 10 MB RAM is recommended for each light user and up to 21 MB RAM for each power user."
They go on to point out that even such factors as bus architecture must be considered. The low bandwidth ISA (AT bus) architecture is not recommended for a Terminal server, and should be passed by in favor of a higher-performance bus, such as EISA, MCA, or PCI. All of these buses support the sustained high data transfer rates typically required when running Terminal Services.
Again from the Microsoft Website:
"In general, processor and memory requirements scale linearly: You can support double the number of users on a multiprocessor-capable Pentium system by doubling the number of processors and doubling the amount of memory. For this reason, purchasing a system that supports multiple processors, even if you initially purchase only one processor, allows you to add capacity easily as your requirements grow."
This is a good start, but leaves a great deal of leeway, and a little additional discussion is in order.
It is easy to classify computer users according to the demands that they place on the server, and for the purpose of this article we will break the user space up into two groups - Industrial and Commercial.
Industrial Users
The typical industrial user is a special case, and therefore does not fit into the sizing requirements usually advertised by Microsoft. Some of the factors associated with most industrial applications that may make them unique:
One (big) program - Most HMI programs are much larger than the smaller applications run daily by commercial users. Some do have special versions for display only nodes or even Terminal Services, but these seem to be the exception.
Constant use - The industrial application is typically up 24 hours a day, and so every industrial Thin Client on the network should be counted on to add one application on the server. This is different than the commercial user, where probably one out of every five clients are not running any programs.
Mostly idle / Highly computational - While the program is probably running 24/7, the system requirements will possibly vacillate wildly. One display screen may simply show a few rarely changing production totals; while another screen in the same application may show 500 data points that all have to be calculated from continuous data. This requires the system planner to assume the worst when sizing the server. And the size of the screens being displayed may have a huge impact on the amount of RAM required.
Maybe DOS? - Some industrial applications still require DOS, and you might have another problem: keyboard polling. Since they're designed for a single-tasking environment, some DOS applications poll the keyboard for input so that they can respond as quickly as possible. Doing this uses up a lot of CPU cycles.
With industrial applications, the best way to pin down the correct server size is, unfortunately, to run the application. Performance varies drastically depending on the type of HMI, the number of 'tags', and the requirements of the display and alarming system. Find a PC running the program and screens that will be run on the Thin Client, and discover the system resources being consumed. If you can get an idea of the RAM and processor loading, and compare it to the system when the application is not loaded, you will have a pretty good idea of what to expect. Assume the RAM will scale linearly, and then make an estimate of the CPU cycles needed.
Commercial Users
These "office type" people are generally light users, and typically run a single application at a time (word processing, Excel, etc.). If they do have two or more programs running simultaneously, they do not frequently switch between programs. These applications do not place high data-processing demands on the system, and a large part of the time the computer is basically idle.
An advantage that most of the (especially Microsoft) office type applications have is that they are running applications that allow the Terminal Server to share executable resources between the individual users, just as Windows 2000 shares executable resources (.dll, .exe, and so on) between individual programs. As a result, the memory requirements for additional users running the same program are typically less than the requirements for the first user to load the application.
The problem is that the number of users that a single server can support depends heavily on a number of factors, many of which vary over time, and the range is pretty dramatic.
Also take into account the number of Terminal Servers. When you buy a 25 pack of licenses for ACP's ThinManager software, this allows you to run 25 clients - but these clients don't have to all be connected to the same server. A strong case can be made for using more small servers than fewer large servers. If the 25 clients are distributed among 5 servers, a single server going off-line is very easy to compensate for. Adding more clients is also easier and faster when you are adding another smallish server than if you have to physically upgrade a big server.
If you want to be safe, you might want to go ahead and "super size" that server order. If you put down a little more money in a server up front, you will probably end up saving money later on down the line.
For more information on ACP Industrial Thin Client computers, please visit our web site at http://www.thinmanager.com
To sign up for the E-mail newsletter go here: ACP newsletter signup
For an archive of past newsletter articles go to: ACP Newsletter Archive