Learn about Linux
Download Linux
Get Linux helpSpecial Offers
Feature
Linux and thin clients
Share
Print
CommentsThis article is excerpted from the newly published book "Linux in a Windows World."
In a thin client configuration, most computers are thin clients -- relatively limited computers that consist of a keyboard, a mouse, a monitor, and just enough computing power to display data on the screen and communicate with a central login server. This login server is a multiuser system that can handle all of the network's users' ordinary desktop computing tasks. As such, the central system must usually be quite powerful. Because a typical desktop computer's CPU is mostly idle as a user types or reads, and because a multiuser system can save memory by using shared libraries and similar tricks, the central system doesn't need to be as powerful as the combination of all the workstations it replaces. For instance, consider an office of 10 users that require 10 2GHz Pentium 4 computers with 512MB of RAM. In a thin client configuration, you probably don't need a 20GHz Pentium 4 with 5GB of RAM (if such a computer even existed!); something along the lines of a dual 3GHz Pentium 4 with 2GB of RAM will suffice. Actual requirements will depend on the specific applications, the network bandwidth, and other factors.
The thin clients themselves can be either dedicated hardware devices or recycled older computers. Even an 486 system might make an acceptable thin client. Thin clients frequently boot from the network using Ethernet cards that support network boots and an appropriate set of servers. You typically need a DHCP server and a server running the Trivial File Transfer Protocol (TFTP). One type of thin client is known as an X terminal. This is basically a computer that runs an X server and little else. Other thin clients can use the RFB protocol or other protocols. Several dedicated Linux thin client distributions exist, as well as tools that enable thin clients intended for Windows to connect to Linux servers.
One big advantage of thin clients is that, by centralizing the bulk of the desktop software on one system, you can simplify system administration tasks. The thin clients themselves are simple enough that they require little in the way of maintenance, and as they download their OSs from a server, you can even administer them centrally. More important, the central login server is just one system -- admittedly, one with many users, but one system nonetheless. Instead of rolling out a software update to dozens of computers, you can deal with just one. Particularly if you have a number of old computers on hand that you can recycle as thin clients, this approach can save money on hardware compared to upgrading desktop systems.
Thin clients are not without their drawbacks, though. Because GUI displays must be copied over the network, they require better network infrastructure than is required in a more conventional workstation configuration. The central login server will be particularly hard-hit by this requirement. You may need to upgrade your network to a higher speed or segment it and give the central server multiple network interfaces. As a rule of thumb, an unswitched 100Mbps network can handle about a dozen thin clients; if you use switches, the number goes up to about 100 users. Configuring the thin clients to support sound and give users access to local floppy disks or other removable media may take extra effort. Because the entire network is wholly dependent on a single computer, a failure of that computer will be devastating.
Linux can function as a thin client OS. Typically, you'll prepare a custom Linux installation and configure it to load from the network or from a hard disk in the thin client itself. When connected to a Linux remote login server, you're likely to use X's networking capabilities to handle the communications. However, Linux can be used with RFB or with other protocols to provide users with remote access to a Windows remote login server.
Linux can also function as the central login server. Typically, you'll use X terminals (either dedicated hardware X terminals or old desktop systems configured as X terminals) as the thin clients, but you can use RFB instead, if you prefer or if you've found thin clients that support this protocol but not the X protocols. As a multiuser OS, Linux is particularly well-suited to function as a central login server. Of course, for all but the smallest network, you'll need a pretty powerful computer to fill this role -- probably a multi-CPU system with several gigabytes of RAM.
Comments
on Linux and thin clientsNote: Comments are owned by the poster. We are not responsible for their content.
1) The number of users given is for usage with the X protocol. Using something lighter like VNC, terminal services (rdesktop) or Citrix' ICA allows for a lot more users (in the 10 thousand range). In my experience, also, VNC doesn't work very well (even under Linux). rdesktop and ICA are *much* better. I have yet to test Nomachine's NX...
2) While it's true that 486 would work, in practice they're unusable. Things like Macromedia Flash, scrolling thru texts (which is done locally on the thin client itself) require a faster machine. I've tested a 266Hz machine and deemed unacceptable. I suspect a x86 500MHz would be minimally satisfactory; a 733MHz machine proved ok.
3) Beware of programs that monopolize the CPU, one user might stop the whole show. Although uncommon in Linux/Unix, this happens all the time in a certain monopolistic OS...
HTH.
Although uncommon in Linux/Unix, this happens all the time in a certain monopolistic OS.
Now, now. Enough of the Apple bashing.
Of course if all you are displaying is a database frontend for a retail or warehouse operation with minimal colour and no html/xml the necessary resources would be a LOT less and a 486 might do it.
This, at least, is what I surmise. Others I'm sure have hands on experience with what is required.
>> A full KDE desktop would then not display well on a 486;~)
---
With <A HREF="http://openfacts.berlios.de/index-en.phtml?title=NX_Components" title="berlios.de">FreeNX</a berlios.de> it will! See also <A HREF="http://osnews.com/story.php?news_id=8139" title="osnews.com">developer interview</a osnews.com>.
Some of us have been doing this for years, when 700MHz was a dream you would want as the server.
Obviously the freenx people have done some tremendous stuff with compression, caching and bandwidth utilisation. To run an X session well over a dialup connection, all I can say is wow!!
I have to wonder though what the difference would be between a P133 with 32mb ram and a p3 with 256mb ram.
So the video card would render things like the mouse cursor, for instance. What about flashing cursor, menu animation and video?
I don't have the figures at hand but would that imply needing a 32mb video card to do 1024x768 with 32bit colour or is the colouring and resolution all rendered by the x client?
HA! Maybe I should read the book;~)
I am the original poster (of this "I do this for a living" comment).
I've tested a Pentium I 75MHz as thin client. It was sluggish. Movies could certainly be watched, because they were rendered in a powerful server. Applications started instantly (e.g., Word seen through rdesktop).
Nonetheless, Flash was bad and scrolling was very annoying -- unless when using pure X without compression... read on, please.
One replier talked about having a decent video card. This may be real useful -- mainly if it's AGP. All that I've tested was onboard (they were real thin clients, no PCs), except the Pentium 75MHz, which used a Trident 9680 (an old 2MB card), IIRC. I suspect the main problem was network compression and local decompression. Using pure X protocol, results were fairly good, even with a Pentium 75MHz, but the network wouldn't bear the many users we have. Besides, we already used the LAN for fileserver access, email, data exchange between servers etc.
> I laugh when someone who claims to know about this tells me that I need 700MHz for a good thin client.
I _know_ about this, but I understand you don't need to believe me. Also, schools must deal with dire budgets, while we at work had to deliver an experience at least similar to a good desktop PC -- or we'd lose credibility.
Do you have any way of reducing network bandwidth consumption while still keeping decompression (and hence, local CPU overload) to a minimum?
All TightVNC compression schemas weren't specially useful on a 75MHz machine, but they could work on a 133MHz one.
Since I must connect to Windows servers and VNC doesn't work well in Windows (compared to how good it is on Linux), we opted for a proprietary protocol with a free Linux client [<nobr> <wbr></nobr>;-) ].
All I can say is: It is annoying in a 266MHz National Geode thin client, according to my experience. It's ok for normal use (e.g., in a charity) -- even moreso if you remove the flash plugin -- but professional people demand higher performance.
But if you're using with the few users the author mentions (12 or 13, as you say), and using pure X protocol without any compression, I believe a Pentium 133Mhz would be good enough.
Now NX is totally different. I have tested it over long distances with ping times on the order of 1-2 seconds, and still had a reasonably performing desktop.
Now let me put a qualifier in here. My testing has all been done with "business" type applications such as web browsers, office suites, and other non-media type applications. I do use linux heavily for media, but I heve never done it with a thin client type environment.
"Do you have any way of reducing network bandwidth consumption while still keeping decompression (and hence, local CPU overload) to a minimum?"
Again, take a look at NX or NoMachine.com. 90 percent opf their performance improvement comes from data caching so that the display terminal doesn't actually have to send a message over the network to get a screen re-draw. It doesn't take much CPU horsepower to plop a bitmap in a specific spot, and it doesn't take much network bandwidth to look display station side first to see if the required data is already in hand. I know they also use some other tricks to minimize both the bandwidth and the round trips, but these are the ones that stuck in my mind as being the basic ideas that they seem to have worked from.
I really forgot to talk about latency and how it is far more important than bandwidth (moreover, bandwidth is quite easy nowadays... at least when you're on a LAN==just pure Ethernet).
Thanks for the NX tip, I really shall experiment with it ASAP.
Thanks!
I didn't mean to be insulting when I said "claims to know," but you obviously deal with a different kind of client configuration than what the author was writing about.
Anyway, on a 100Mb switched network, you can run uncompressed without any real problems up to 20-30 clients. The issue you faced was probably not processor speed (though I wouldn't mess with anything below 100MHz), but low video memory. Also, if you were doing a lot of compression, then the CPU DOES come into play, but, as I said, you don't need it over a LAN, anyway.
The simple solutionto bandwidth that most people use to keep their networks quiet is to put 20-30 thin clients behind a server, with shared homes and app servers (including rdesktop) outside. The traffic between the servers stays under control and the client can run uncompressed for maximum speed. Everyone is looking forward to NX being easily used, not for any compression, but because of the caching.
Anyway, I think you're hooked on VNC, and that may be your problem.<nobr> <wbr></nobr>;) FWIW, I've been on thin clients for about 6 years now, since LTSP alpha<nobr> <wbr></nobr>.9 or something.
No offense taken. In fact, you're kinda right, I was being arrogant. But, that is not my normal nature; I was just using arrogance as part of the message, to convey the idea that we deal with a lot of simultaneous users.
It was like using a suit to "look serious".
Just FYI, you have more experience than me. I've been dealing with this stuff for some 3 years.
On the local side, if you deal with, say<nobr> <wbr></nobr>;-), more than 2 thousand users (simultaneously logged), you *must* use compression to save bandwidth. Compression itself generates latency (i.e., degrades user experience) and requires a more powerful thin client processor.
Thanks for your views on the subject. I intend to use a thin client configuration at home, too, and they were valuable for me.
Almost all of the X terminal thin clients that I have been able to find have been the same price or more than a cheap PC. This is very frustrating to me as, I would much rather use a true thin client machine with no fans or moving parts and the small form factor. Using old machines doesn't really help me except in the cost aspect. Old machines still have fans and sometimes even hard drives, floppies at the least and are prone to failure. They take up too much space, make too much noise and heat and are ready to die at any moment.
I'd even say thin clients are bound to be more expensive, because PCs are sold (and made) in greater numbers.
Thin clients' real advantage comes from reduced support cost:
- less hardware maintenance -- they're simpler with no moving parts;
- less installation -- they get only a barebones OS, all apps run on the servers;
- less thin client upgrades -- same reason;
- less software maintenance -- their OSes can be specialized (like Linux), so they don't get viruses;
- easier global upgrades/updates -- you change the servers not the client;
- less energy consumption -- thin clients are economic...
But you only get these kind of advantages if you have to get support for the machines, or upgrade them or keep them protected against viruses. Ther larger the number, the greater the benefit...
Old machines as thin clients are ok, but they'd require more effort to maintain (since usually they are different, cause they were acquired at different occasions).
HTH.
I find that for an average user a P2-300 with a PCI card graphics card and 64mb RAM (NFS Swap too) works fine. For a power user having an AGP card instead of a PCI card makes a huge difference. Bumping the RAM up to 128mb makes it even snappier.
I am just using decent P2-300mhz - 500mhz and all the thin clients are quick with full sound and local device support. Even watching movies with mplayer, totem or real-player works good altho real-player lacks esound support still.
A Pentium I 133 MHz with 32 MB RAM will shine as a PXES <a href="http://pxes.sf.net/" title="sf.net">http://pxes.sf.net/</a sf.net> as a thin client in any of the environments you mentioned (RDP, ICA, VNC, XDM, NX, etc.)
You may be right. This is a configuration I did not test; I found a National Geode 266MHz t be lacking -- but processor architecture does make a difference.
Besides, a thin client is responsible only for image output... a very fast video card would work even in a Pentium 100, as one poster already mentioned.
There are still some things the 233s aren't so hot at, but they seem quite snappy enough at 1024x768. Like you, I'd recommend newer machines for any new deployment, but if you have serviceable older systems around, don't write them off immediately.
As for NX, you should really check it out. Over high latency, low bandwidth networks it's jaw dropping, though I doubt it's as good as ICA. It does a good job on a LAN too, especially with large images, etc - the things X loves to transmit uncompressed.
With a dual-processor Linux server, expect zero problems with programs that monopolize the CPU. Even on a single CPU it's not a big deal, but on dual processor boxes you won't even notice runaway programs (they happen much more than I'd like). Similarly, with a sensible ulimit memory gobblers aren't a problem. What does become a serious issue is disk activity - make very sure to get a disk subsystem well suited to multiple users with random access needs, and make it fast.
Bah! Using '95 data - '05 NX can do much better!
Posted by: Anonymous Coward on April 15, 2005 02:46 AMI wholeheartedly agree to the viability of a Thin Client / Fat Server concept for Linux. From this point of view I welcome any publication promoting this.
But oh, how I hate it, if they all use the data and arguments from 10 years ago:
>> As a rule of thumb, an unswitched 100Mbps network can handle about a dozen thin clients;
My dear friend -- this is data that describes plain vanilla X11 connections. These may have been state of the art back in 1995. But now we have 2005. Today there exists a technology called NX which does a marvelous job in compressing X(11) and even VNC and RDP traffic. With NX a remote X connection becomes really usable even over 56kbps modem links, or ISDN. You can hardly tell the difference to a local session. NX can easily cram 1,000 NX ssessions into a 100MBit link -- because each one will run with a bandwidth consumption of 40 kkbps or less. And then the link is not even saturated yet. Make your LAN a switched one, and you go up to 8,000 sessions at the same time cramming into the 100Mbit cable.
>>10 users [...] require [...] something along the lines of a dual 3GHz Pentium 4 with 2GB of RAM.
For your kind information: with NX, such a machine will be able to host at least 40+ user sessions, put in another 4 GB and host 120+ sessions on it. This scenario assumes that every user runs a full KDE desktop, plus OpenOffice for word processing, plus Firefox for web browsing, plus Konqueror for file management, plus KMail for emailing, and it knows for sure that *at the most* each user session will only take 50 MHz of CPU and 50 MBytes of RAM...
Roderick, you are doing the Linux community a dis-service with the kind of figures you name. Because our main competitors on this field, Citrix/ICA and Microsoft/RDP are both *much* more efficient than what you describe. Both can run very responsive sessions on a dial-up link (even non-DSL ones).
No-one in a top 1000 enterprise will ever consider switching from Windows with Citrix or Terminal Servers to your solution if the performance you describe is all that is available.
To compete with the level of ICA or RDP network performance (and even surpass it) you'd need to turn to the new kid on the block: NX.
Roderick, please use current facts, figures and arguments to back up your book. Please describe state of the art technology, not 10 or 20 year old one. Read up, <A HREF="http://www.nomachine.com/testdrive.php" title="nomachine.com">test it yourself</a nomachine.com>.
I am not going to buy the book now that I know you do not even mention <A HREF="http://www.nomachine.com/" title="nomachine.com">NX</a nomachine.com>, <A HREF="https://mail.kde.org/mailman/listinfo/freenx-knx" title="kde.org">FreeNX</a kde.org> or NoMachine.
I have used NX, and it is comparable to Citrix. The only problem is that it doesn't run on a windows server, doesn't have a user web login interface(like nFuse), and possibly doesn't have the same standard of management tools. By standard, I mean raising priorites of application or desktop processes among other things.
I don't know if there is a solution yet. But if somebody gets NX or a clone running well on a windows server, that will take away 90 percent of the headache and 90 percent of the cost. 20 client/user licenses in Citrix are $12,000.00. Add the $2000.00 for TS CAL's and 2K/2K3 software per server after that. You have 60 people logging in, and you could hire a FTE to install the apps and maintain them for you. It really is disappointing cost-wise.
The application vendors are always the weakest link. And most app vendors are in vertical markets, and so they tend to suck for OS's diverging from Microsoft. No, I take that back- they always suck. They are the reason why I'm paying so damn much for all of this software. And I hate them. You hear me you bastard programmers! Put the VB/.NET dick down! Losers.. anyhow, that's where I'm at. YMMV, but I doubt it.
That said, I haven't looked into it in detail.
The other issue you'd face would be that you'd still have to pay CALs for your Windows remote users, no matter what remote access technology you use. Fantastic, isn't it...
I'm currently running raw X11 terminals at work for our more basic users. They don't need access to any windows apps, and it's been working well. Unfortunately, that little issue with small & semi-custom software vendors in vertical markets is beginning to get to me as I look for a replacement for our extremely ancient and troublesome terminal-based accounts system (runnning on SCO OpenServer emulating Microsoft Xenix - it's ooooold). Wish I had a good fix for that problem...
Re:Bah! Using '95 data - '05 NX can do much better
Posted by: Anonymous Coward on April 15, 2005 06:27 PMWill NX allow me to do the same? (Use only a disk to boot or connect to server NX?)
My previous experience is that NX Client is an application within an Operating System Host. Therefore, it does not offer me the same freedom as LTSP.
Probably the LTSP team can implement on compression methods in the future I hope.
Re:Bah! Using '95 data - '05 NX can do much better
Posted by: Anonymous Coward on April 15, 2005 10:21 PMIIRC they are working on adding the NX client.
NoMachines NX protocol is compression and caching layer which you can tunnel X through. I'm kinda of surprised that LTSP hasn't fully incorporated FreeNX yet, but you can use <A HREF="http://pxes.sourceforge.net/" title="sourceforge.net">PXES</a sourceforge.net>, which does have support for NX and also replaces most of the functionality of LTSP. Unlike how LTSP is usually run, PXES doesn't work with NFS exports. Instead it's more like a tiny compressed live cd image which the clients boot from either using local CD or over the network using PXE which grabs the boot image from a tftp server. Although I've never done it, it's my understanding that you configure LTSP to work in essentially the same fashion, and can even use the PXES image.
"http://www.sun.com/software/index.jsp?cat=Deskto<nobr>p<wbr></nobr> &tab=3&subcat=Thin%20Clients"
<a href="http://www.rokulabs.com/products/photobridge" title="rokulabs.com">http://www.rokulabs.com/products/photobridge</a rokulabs.com>
works nicely as a thin client. It has a processor, 100MB Ethernet,
and the ability to connect to a monitor or TV.
There is an open-source VNC client for it that lets you connect to a
server and control the mouse using the PhotoBridge's remote control:
<a href="http://frequal.com/roku/VncSix/index.html" title="frequal.com">http://frequal.com/roku/VncSix/index.html</a frequal.com>
this means beerier "clients" but has many of the administrative advantages. sound and local storage (your usb stick if this is a library for example) are easy (they being local and all) movies, flash etc. play just fine (i have used flash over X11, its usually not bad over 100mbs)
if you really want performance, load / and some other directories into ram. sure booting might take awhile (havent tried this yet), but other than that this should be pretty sweet.
one studio (dont remember which) kept all thier workstations in the machine room with very long kvm cables to everyones desks, and, i think, serial cables plugged into them for the admins use (these were all running irix) not completely related, but thought it was neat, and this remembed me of it.
4 4 port graphics cards, USB adapters to support 16 keyboards, mice and USB speaker systems. You would probably need a motherboard that would have 6 or 7 PCI slots, but that should support 16 users, and not a network cable in sight.
Maybe one of the old 4 or 8 way servers on ebay would be better. Some of the old Compaqs have 16-20 pci slots in them, and also support 8-16 gigs of ram. There are even one or two models that aren't too costly that even sport SDram.
Hmm, Now where did I put the rest of the users who used to live in my house? Now I could economically hook them all up with computers, and none of them could accuse me of putting them on thin clients, because each would be directly connected to the main computer.
Oh, wait. That was in last night's dream. I never did have 16 computer users in my house. Oh well.
Just an excerpt, not the whole coverage of the sub
Posted by: Anonymous Coward on April 15, 2005 09:19 PMIn short, this excerpt sucks in comparison to the other great information he provides about thin clients later in the book, this was just a very small portion of an introductory chapter.
He also provides stellar coverage of Samba, one of the best descriptions of PAM and beginning LDAP I've read, and I love his instructions for authenticating Linux boxes off a Windows Domain.
bla bla nx bla bla network performance bla bla lts
Posted by: Anonymous Coward on April 16, 2005 02:03 AMRe:bla bla nx bla bla network performance bla bla
Posted by: Anonymous Coward on April 16, 2005 05:31 AMIf, on the other hand, you have 10 or 15 old under-powered PC's laying arround and you don't have the $400 each to buy the thin clients, then it might just be worth your time to get LTSP running -- about a 4 hour project when I first started working with it, but should be only about a 1 hour project to get it working now.
Now let's figure. If your time is worth $80/hour and it will take you 4 hours to get the thing working, that's $320. How many terminals would you have to save yourself from buying in order to pay back your investment of time? If that's too much for you, I bet someone else would be glad to have your cast off PC hardware. In fact, I think I read something on the k-12 LTSP site relative to donating old PC's to schools for use with the LTSP software. You might at least get a tax writeoff for the old equipment.
They all have 2.8G P4's with 512M of RAM on each desk, what a waste to try and convince them to buy a super dooper server with 50G of RAM. Now all those $2,000 machines sitting there become dumb terminals.
What I would like to see is the client runs as a thin client but there is an agent loaded that makes it part of the distributed virtual computer allowing it's CPU to be utilized.
We just left the existing workstations alone, but used thin clients for all the new stuff.
Check the OpenMosix project. It changes unused thin clients into nodes of a Linux beowulf (a cluster).
For simultaneous use as a thin client and a normal computer, provided you have such a powerful machine (2.8GHz ec.), I guess there would be no problem... and probably no swapping wit 512MB RAM.
Do some tests with LTSP before spending money...
http://www.ltsp.org/
ltsp is an add-on package for Linux that allows you to connect lots of low-powered thin client terminals to a Linux server. Applications typically run on the server, and accept input and display their output on the thin client display.
Today (19 april 2005), the brand new 4.1.1 version is born !
</TT>
The nice thing about having PC's on the other side (and decently powered 500Mhz+) is that you have plenty of CPU. There are some locations at my work that have over 100 thin clients connected off a server. How can it handle it? Look outside the box. No hard disk, no cdrom, no anything really useful in the thin client box. Aha, you do have RAM, a CPU, and a NIC which is all you need to run software. If you simply create a ram disk and run the software out of a ramdisk, you can achieve great things. Using NFS or AFS as well for file shares, user directories, and possible shares to run non-OS critical stuff off of works as well. With how cheap memory is, look at this option. You centralize your image, make management a little easier and are not chewing up your server.
Check out etherboot, mknbi and nbi utilities, how to utilize a initrd image for creating ramdisks and setup as a rootfs and how to setup a rootfs in the kernel to make it work. That is really the start of how to make your own bootable image with a ramdisk space for programs.
-John
http://www.unixsystemengineer.com
www.safedesksolutions.com
smallest?
Posted by: SarsSmarz on April 14, 2005 11:23 PM#