Slow repaints of user interfaces
Wrong fonts in applications
Slow keyboard response
Slow response in saving files
It would be wonderful if Gigabit could be run to all of your facilities.
But the truth is that often you are not able to deploy that speed, because
of cost or physical locations of buildings. Once networking speeds get
below 100 Megabit, you will no longer be able to use native X windows
and must consider deploying products that compress presentation data.
Microsoft RDP will do this, along with Citrix Metaframe, tight-VNC, and
Most of the products the author has tested that compress data seem to
become usable around 100K of speed. Dialup connections will work, but
repaints will be tedious and not very efficient. A good formula to use is to
multiply the number of concurrent users at each remote site by 100 to get
a rough estimate of bandwidth required. Using this formula, 3 concurrent
users would require roughly 300K of bandwidth. Remember too, that
very possibly print jobs will be running on the same circuit, which will
consume bandwidth as well. The user community will perceive 'slowness'
mostly in the user presentation itself. Print jobs that take a bit longer
are not normally noticed. So, one might consider running two circuits
to remote sites and splitting the user sessions on one, and the print jobs
on the other. That way if massive print jobs are sent, the users won't
notice and can continue working. It should be noted as well that some
bandwidth management products such as Citrix have designed their
software to support printer connectivity that is also compressed.
The most important issue with remote sites is stability and uptime.
When you centralize all of your software, it's critical that the network be
available or users will not be able to log into the servers and do their job.
Many people do not care how it works, just that it's reliable. Consider
all of your options such as T1 connections, DSL, and cable modems and
then select the solution that seems like the best fit. One effective method
is to create a list of all available networking methods, and then create a
chart that clearly spells out the features and speed available within each
category. As the line becomes cheaper, it normally becomes slower. The
decision makers need to understand that at a certain point presentation
and software application speed will start to degrade. It is also important
to obtain from the vendor exact service levels for each of the connection
methods. Commercial and business lines often will guarantee a minimum
amount of bandwidth. Regular home-use circuits often are rated for 'burst
rates' and run considerably slower than the specified rate.
Some remote users will be using wireless connections. They too will
require an application that will perform compression, and should be
considered as well. Cellular wireless broadband is providing plenty of
bandwidth these days to run with centralized computers.
Thin Client Network Connections
Once you have performed the steps as outlined previously, you will need to finalize
your design for the thin clients themselves. If your current deployment is only
capable of 10 Megabit, you will definitely want to upgrade the wiring and move
to a minimum of 100 Megabit. 100 Megabit provides plenty of bandwidth for very
crisp response time from the servers, and mouse and user interface response is
excellent. At the time of this writing, running Gigabit to the desktop has not
been tested by the author; but if your thin clients support that speed that is
an excellent buffer and should provide even greater capabilities. If users are
using devices such as laptops, always encourage them to use a wired connection
in the office. In the case of X windows, it will avoid having to
use a licensed bandwidth compression interface.
At the time of this writing, Gigabit connections to the desktop are
becoming more and more commonplace. If part of your deployment
is a redesign of the network, run the highest-rated wiring that you are
allowed. The author is anticipating that Gigabit thin clients will become
available very shortly. More and more software is making use of the
3-dimensional capabilities of thin client video cards, and each step in this
direction requires additional bandwidth.
Testing the Network
Anyone that has supported users knows that often they will discover things that
the technical staff never anticipated. It's important to turn that into a
positive, and isolate as many problems as possible before final
deployment. It's effective to place a few thin clients at each of your sites,
and on each of the networking technologies that you have selected and
perform their regular day-to-day duties. Some types of connections such
as X windows sessions are not stateless, and will drop if the network
under-performs. If you are considering a new vendor for networking
hardware, they should allow you to install demo devices and test them
on your infrastructure. Be mindful that sales people sometimes over sell
their products or don't understand exactly your design goals, so a real-
world test with their hardware before major purchases is always a
In this article/excerpt we see that though the complexity of networking cannot be stated
strongly enough, it is important to design a rock-solid and stable network
before your deployment begins. Follow standard methods and designs and work with
your hardware vendors to make the best possible use of their equipment. Once you
plug the thin client in the wall, you will be excited at the things to come and
will be ready to configure the application servers.
David Richards is the author of the new thinclient Linux book:
Linux Thin Client Networks Design and Deployment.
This brief book excerpt is provided by permission from Packt Publishing Ltd.
All experiences are those of the author and do not necessarily convey the views of reallylinux.com.
Linux is a registered trademark of Linus Torvalds.
Microsoft, Microsoft Windows and WindowsXP are trademarks or registered trademarks of Microsoft Corporation both in the United States and Internationally. RedHat is a registered trademark of RedHat Inc., SUN and JAVA are registered trademark of Sun Microsystems, Inc. All other trademarks or registered trademarks in this opinion piece belong to their respective owners.