Sustainable Computing White Papers
Sustainable Computing through client/server
"computing hardware that doesn't cost the earth"
Disclaimer
This paper presents the personal views of the author, who acknowledges his debt to the
immense wealth of knowledge made freely available on the internet by members of the
open-source community. Trademarks are owned by their owners. There is no warranty
about the information in this document. Use and distribute at your own risk - for license
information please read the appendix. E&OE.
John McCreesh
Sustainable Hardware through
Terminal/Server
Concepts
When people bring home a new PC and switch it on, they expect to see a nice graphical
user interface, with some kind of windowing system where they can run whatever software
is installed on the PC. This is true whether the PC has Microsoft Windows installed, or one
of the Linux distributions like RedHat, Lindows, etc.
However, if the PC is running Linux, what appears to be a self contained PC is actually
something subtly different. A self-contained PC under Linux is technically known as an X
Workstation. Behind the scenes, the user interface - keyboard, mouse, and screen - is
managed by an X server program. The application programs (OpenOffice.org, Mozilla, etc.)
are known as X clients – they communicate with the user through the X server. This
means that the developers of the applications don’t need to worry about what kind of
screen, keyboard, mouse etc are present – the X server takes care of all the details for
them.
However, there is no reason why the X server and the X clients (applications) have to be
on the same computer. An X server does not require particularly sophisticated hardware a basic PC can be set up to boot up and run an X server from a local hard disk. The user
would then connect to another computer running the X clients to do ‘real work’. A device
like this is known as a dumb X terminal. This can be carried a stage further – a dumb X
terminal can be set to download its software from another computer every time it boots,
eliminating the need for a local hard disk - a diskless X terminal.
The main restriction created by the split is that the communications between the X clients
and the X server is limited by the bandwidth of the network connecting the two systems.
Using current networking technologies, it is impractical to run video-hungry applications
such as watching DVDs or playing video games. However, normal commercial applications
– including CAD, photo-editing, etc – run without problems at normal LAN speeds.
Carrying this a stage further, one server can be used to serve X clients to many diskless X
terminals. All the software and data for the system is held on the server. Every time a
diskless X terminal is switched on, it downloads the software it needs to run as an X server.
When the user has finished, there is nothing to store on the terminal, and it is simply
switched off.
This form of computing can provide a highly efficient and cost-effective solution where a
number of users on a local area network have similar computing requirements.
Comparing this ‘Terminal / Server’ solution with a conventional network of workstations:
Terminal / Server
Conventional networked workstations
diskless X terminals require minimal
hardware to run
every PC needs to be fully specified with
disk, memory, CPU etc.
every user has equal access to computing
resources
each user can only use the resources
provided by the PC on their desk
terminals boot quickly as they have
every user has to boot a complete operating
minimal software to load
system for their own PC
applications are shared in the memory of
the server, so programs load quickly and
save memory
every user has to load their own copy of
every piece of software into their own PC’s
memory
if a diskless X terminal fails, it can be
swapped out with any other device
rebuilding a complete PC from scratch
requires tedious software installs / restore
from backups
new versions of application software only
need to be installed once on the server
every new piece of software / upgrade
needs to be installed on every PC
Terminal/Server in Practice
There have been a number of attempts to introduce terminal / server technology to groups
of Microsoft Windows users using technologies such as Citrix, Microsoft Terminal Server,
etc. However, these have suffered from the restriction that Microsoft Windows was
originally designed to be run on a self-contained PC. Software developers have written
programs on this assumption, with the result that trying to split the operating system into
a ‘server’ and ‘terminal’ has not been very satisfactory. The Microsoft Windows operating
system has also had its limitations as a multi-user server operating system.
On the other hand, Linux (and other *nix operating systems) have adopted an X server / X
client approach from the earliest days of windowing systems, and so are ideally suited
technically for terminal / server computing. The modular design of the Linux kernel also
means it is easy to design a minimal Linux kernel to power an X terminal. The fact that
Linux and XFree86 are free of licence fees also makes their use in large numbers of
terminals commercially attractive.
Linux is also an ideal operating system for servers, as it was designed from the outset to
support tens to hundreds of users on a single system, with all the reliability, scalability,
and security features that server based computing requires. Linux now offers open-source
software for providing normal office computing – web browsers, email clients, word
processing, spreadsheets, graphics, presentations – making it a viable alternative to
Microsoft Windows for most office users.
The Linux Terminal Server Project –
packaged terminal/server computing
It has always been possible for technical staff to create a Linux-based terminal/server
systems from scratch. However, the Linux Terminal Server Project (LTSP) 1 has made this
much simpler by pre-packaging the necessary software components to make installation as
simple as possible. The LTSP package is also well supported through the usual open-source
channels, and it is possible to buy ready made diskless X terminals designed for the LTSP
package 2.
As sustainable computing is all about not re-inventing wheels, in this document
terminal/server and LTSP will be used synonymously from now on. An LTSP terminal is a
diskless X terminal running the LTSP client software; and an LTSP server is a Linux server
with the LTSP package installed.
LTSP terminals are by definition diskless (with a hard disk they become dumb X terminals
or X workstations). This means that when they are switched on, they require some
mechanism to enable them to boot from the LTSP server. Some PC / network cards
support booting over a network; most other PCs can be made to work using Etherboot
software on a floppy disk. Converting a PC from operation under Microsoft Windows to
being an LTSP terminal can be as simple as putting an Etherboot floppy in the floppy disk
drive. Removing the floppy disk means the PC reverts to Microsoft Windows – ideal for
testing / trialling.
Flavours of LTSP terminal
The simplest (‘purest’) form of an LTSP terminal comprises a PC configured to boot from
an LTSP server. When the terminal boots, it downloads the necessary LTSP client software
from the LTSP server, and from then on runs as a self-contained X server. This is by far
the simplest form of terminal to configure and manage, and runs well on most standard
specification PCs, including those which are considered obsolete by users of Microsoft
Windows.
However, the LTSP package does provide some support for PCs that are either fall below or
exceed the standard specification.


PCs with as little as 4Mb of memory can be made to work as LTSP terminals by
mounting a swapdisk on an NFS server. This makes an otherwise unusable PC
usable, at the cost of additional load on the NFS server and additional complexity
(terminals have to be configured on a case by case basis) 3.
At the other extreme, a high spec PC with a fast CPU and generous amounts of
RAM can run an X server and have lots of spare capacity. One way to use this
capacity is to run one or more X client applications on the diskless X terminal. This
reduces the load on the LTSP server, especially if applications malfunction, and can
enable users to run graphics intensive applications, or application needing access
to peripherals attached to the terminal. On the other hand, applications have to be
specially analysed and set up to run on the terminals. The server environment
becomes more complex and less secure, with sharing of users files via NFS and
authentication via NIS. Users also lose the benefits of code sharing.
For most situations, the default configuration of LTSP terminal provides the greatest
benefits of terminal/server computing.
Specification of an LTSP terminal
The hardware requirements for the terminal are modest:
CPU
i486-66
P75
P133
>P133
RAM
16Mb
24Mb
24Mb
>24Mb
Performance
acceptable
good
good
not noticeably better
The client also needs a floppy disk drive to boot from 4; an Ethernet card; and a
reasonable graphics card with 2Mb of video RAM for a full graphical user desktop 5. It helps
if the video and network card are PCI, as most PCI devices can be automatically detected
by the software (ISA require manual configuration).
The X server on the terminal manages the standard parts of the user interface: graphics;
keyboard, mouse, and also some more exotic devices like touch screens. In the simple
model, all other peripherals are provided by the server. However, LTSP does provide some
support for other peripherals attached to terminals, either out of the box or using
additional software:

Printers: networked printers are standard in Linux; so permitting printing to printer
attached to a diskless X terminal is simple to set up for serial or parallel attached
printers, and only slightly more complex for USB devices


Soundcards: common types are supported through an add-on component to the
standard LTSP package.
Floppy disk drives, CD-ROMs: can be accessed over the network, using add-on
components
Converting a PC into an LTSP terminal
If a networked PC meets the basic specification of an LTSP terminal, converting it can be
as simple as identifying the network card installed, inserting the appropriate Etherboot
floppy disk 6 and rebooting the PC. Once the PC has booted, the floppy disk drive is then
no longer required until the next reboot.
The process is completely reversible, making it comparatively simple to set up ‘proof of
concept’ demonstrations.
Specification of an LTSP server
The LTSP package makes use of a number of different services to boot LTSP clients, to
download the LTSP client software to the terminal, etc. These services are supplied as part
of most normal Linux distributions, but may not be enabled by default. The install script
supplied with LTSP attempts to configure them and enable them if necessary. In a simple
single server setup, all these services are provided by one server; this server also runs all
the X clients (applications run by users). The size of server is then a function of the
number of users, and the number and size of the X clients that users run concurrently. For
this reason, there is no ‘one size fits all’ specification for an LTSP server; however, it is
possible to list the factors which influence the size of the server required:
Factor
Smaller server
Larger server
Number of users
few users
many users
Number of different
applications
users sharing small number of
common applications
users all running different
applications
Windowing system
light – e.g. XFce, qvwm
heavy – e.g. Gnome, KDE
Type of application
minimalist – e.g. Sylpheed,
Abiword, Opera
full function – e.g. Evolution,
OpenOffice.org, Mozilla
Bandwidth hogs
none
MPEG player, P2P networking...
Clients
run applications locally
low memory (swapfiles via NFS)
Experienced LTSP administrators have their own rules of thumb for estimating server size:
for example, 256Mb memory minimum plus anything from 15-50Mb of RAM per concurrent
user. Most implementations also quote ‘no more than 100 users per server’ as a sensible
limit (larger user populations can be served using multiple servers – see ‘Scaling an LTSP
server’ below).
Examples of LTSP servers
A survey of live LTSP sites was carried out during November 2002 to record some data
about the kind of servers currently in use. The results are given in 'LTSP User Survey
2002' below.
Scaling an LTSP server
LTSP server capacity can be increased in two dimensions:


vertically – in a single server configuration, the specification of the server can be
increased to support an increased workload. Increasing memory is often found to
be a comparatively inexpensive way to deliver a noticeable performance
improvement.
horizontally – as the ‘LTSP service’ consists of a number of separate processes, it
is quite feasible to run these on physically separate servers. This can be attractive
if there is redundant equipment available which can reused as additional servers
(typically PIII 600, 256Mb RAM or better). Sites adopting this strategy could also
consider clustering techniques such as OpenMosix 7 to provide automatic load
balancing between servers.
There is no real alternative to analysing the performance of a running system, finding the
performance bottleneck, and removing it (additional memory; faster disks; adding another
CPU...). Even a simple ‘proof of concept’ set up using available equipment will yield
valuable information. There is a wealth of material describing the tuning *nix servers –
there is nothing special about an LTSP server.
LTSP and the network
LTSP is designed to serve a trusted community on a LAN. As the package uses a number of
different services, it can be tricky to set up to run through firewalls on a LAN (normally, a
LAN would not be firewalled internally, so this is not a common problem). On the other
hand, if the users require access to external networks – such as the internet – then this
absolutely should be set up through a firewall 8. Trying to run an LTSP service over a
public network such as the internet without any security precautions is foolhardy in the
extreme.
Estimating the bandwidth requirements of an LTSP network is also not an exact science.
The network traffic will be ‘point to point’ (terminal <-> server), which means that the
network card on the server is a potential bottleneck. A wise systems administrator also
steers users away from 'eye candy' applications which can generate unnecessary network
'chatter' (e.g. monitor applets displaying graphics in real time, or fancy screensavers with
lots of graphics). Network restrictions are another good reason for keeping to a 'maximum
100 terminals per server' rule.
LTSP User Survey 2002
The Questionnaire
Towards the end of 2002, a request was posted on the ltsp-discuss mailing list, asking for
users to record details of their live LTSP sites on a website set up for the purpose:
LTSP User Survey
All questions are optional, but the more information you supply, the more useful the
results will be. Please note that this survey only covers systems with a single server.
Please tell us about your server
Q1 No of CPUs
1 2 4 other...
Q2 Make/Model
(e.g. Intel P4)
Q3 CPU Speed
(MHz)
Q4 Memory
(MB)
Q5 Total Disk
(Gb)
Q6 Disk Type
JBOD RAID other...
Please tell us about your workstations
Q7 No.of workstations
(total)
Q8 Do any use local applications?
(tick if yes)
Q9 Do any use swapfiles on the server?
(tick if yes)
Q10 How long do workstations take to boot
(from end of POST to log in screen?
(average in seconds)
Q11 Typical number of concurrent users?
(average)
Please tell us about the software on your workstations
Q12 What window manager do you use?
Gnome KDE IceWM XFCe qvwm other...
Q13 Please list the main applications used? e.g. Mozilla, Evolution etc.
Please tell us about the your network
Q14 Network speed?
e.g. 100Mbs
Q15 Network Topology
Switches / Hubs...
Please tell us about your organisation
Q16 Name of Organisation?
Q17 Type of Organisation?
Commercial Educational Home Network
other...
Q18 Contact Email?
Q19 May we publish your email address?
(tick if yes)
The Results
A total of 75 replies was received during October and November 2002.
Some bullet points from the survey:







the smallest site had one terminal; the largest, 100
there was a wide variety of CPU types, speeds, and number, with no obvious
correlation to number of users
most servers ran between 640Mb - 1Gb of memory
very few sites (4%) used local applications
just over half (54%) used swapfiles on the server
applications reported covered pretty well the whole range of common Linux
applications: Galeon, Konqueror, Mozilla, Netscape, Opera; Applixware, kWord,
OpenOffice.org, Star Office, WordPerfect; Evolution, kMail, Sylpheed; The Gimp;
Crossover Office, Citrix, Win4Lin...
there was no clear winner on networking topology - sites used the full range from
10Base-T through to Gigabyte switches.
The chart below provides an analysis of answering organisations. Most 'other' were notfor-profit organisations (which should really have been a separate category on the survey
form):
IceWM was a surprising leader among window managers - however, this was due to one
commercial organisation recording multiple entries for their customer sites, most of whom
were supplied with IceWM. Without this, KDE and Gnome would have shared the honours:
One aim of the survey was to come up with server sizing examples, and see if the rule of
thumb quoted above - '256Mb memory minimum plus anything from 15-50Mb of RAM per
concurrent user' - is applied in practice.
As might have been expected, the sample showed much more variety than this simple rule
suggests. Most sites had between 40-110Mb of server RAM per concurrent user. The
following chart shows server memory plotted against the number of terminals supported.
Each point on the chart is one reporting site, so the scattering of the points along the X
axis shows the number of different sizes of site (note that the scale is logarithmic). The
scattering of the points across the body of the graph shows that larger terminal
populations generally require more RAM in the server. However, it's likely that the size of
RAM is equally influenced by the way it is bought: RAM comes in discrete chunks, and
some configurations are more popular than others for manufacturers' 'off the shelf'
offerings.
The author of this document wishes to place on record his thanks to all of those who took
the trouble to take part in the survey.
Appendix - Public Documentation License Version 1.0
The contents of this Documentation are subject to the Public Documentation License
Version 1.0 (the "License"); you may only use this Documentation if you comply with the
terms of this License. A copy of the License is available at
http://www.openoffice.org/licenses/PDL.html.
The Original Documentation is http://uk.homelinux.org/docs/scintro.sxw. The Initial Writer
of the Original Documentation is John McCreesh Copyright (C) 2002. All Rights Reserved.
(Initial Writer contact(s): jpmcc@users.sf.net.)
Contributor(s): ______________________________________.
Portions created by ______ are Copyright (C)_________[Insert year(s)]. All Rights
Reserved. (Contributor contact(s):________________[Insert hyperlink/alias]).
NOTE: The text of this Appendix may differ slightly from the text of the notices in the files
of the Original Documentation. You should use the text of this Appendix rather than the
text found in the Original Documentation for Your Modifications.
References
1 See http://www.ltsp.org
2 e.g. http://www.disklessworkstations.com
3 The LTSP software can also be set up to run telnet sessions instead of X sessions if basic
‘dumb terminal’ functionality is all that’s required
4 Or a bootable network card
5 Old monitors may work better at lower resolutions, allowing lower spec video - e.g. 1Mb
video RAM can produce 812 x 608 at 16 bpp
6 Etherboot is another open-source project which produces boot images for most common
networking cards - see also http://www.rom-o-matic.org/
7 See http://www.ibm.com/servers/esdd/articles/openmosix.html for a good introductory
article
8 It is recommended to have the firewall on a separate box and not run it on the LTSP
server