I have pondered the relative merits of thin-client solutions to the "fat client" alternative, and wanted some views on its merits (it was previously discussed here on this list in connection with OSiE and from then I have looked into it more). For example, I have noticed that the thin-client model requires a bigger server and one that after formation can only appear to handle up to 30 clients with significant power. Does this raise the relative cost savings as opposed to using a fat-client model, or do away with them altogether. Or is it that the thin-client model does in fact save money both on server and clients? How does running thin-clients work when, say, multimedia useage is needed? Any takers? TIA Paul
hi Paul and list On Monday 26 March 2001 15:52, paul munro wrote:
I have pondered the relative merits of thin-client solutions to the "fat client" alternative, and wanted some views on its merits (it was previously discussed here on this list in connection with OSiE and from then I have looked into it more).
For example, I have noticed that the thin-client model requires a bigger server and one that after formation can only appear to handle up to 30 clients with significant power. Does this raise the relative cost savings as opposed to using a fat-client model, or do away with them altogether. Or is it that the thin-client model does in fact save money both on server and clients?
ok, from an initial purchase point of view, thin clients will save you money, especially if you recycle, (a cost 20-50 quid for an upgraded network card), a 486/8Mb machine with a bootable network card will do it, 10Mbps card. however the big cost saving is with TCO (total cost of ownership), the configuration of server and all clients is all on the one machine, not scattered around 30 odd machines. servers are not neccessarily expensive, memory, disk space etc aren't expensive and also you can cluster smaller, lower spec machines (even just using the DNS a la Felsted)
How does running thin-clients work when, say, multimedia useage is needed?
LTSP does support 'local apps' and can load kernel modules on the fly for sound, additional graphics etc.
Any takers?
yep, i'm a fan, especially as unlike Citrix you dont get bombed by the licensing costs, you can put this towards support and also more terminals add in applications like rdesktop, Tarantella etc you can integrate fully with your existing NT4/Win2k terminal services if you need to..... Malcolm
Paul
-- ------------------------------------ Malcolm Herbert Red Hat Europe t:+44 1483 734955 m:+44 7720 079845 ------------------------------------
I have pondered the relative merits of thin-client solutions to the "fat client" alternative, and wanted some views on its merits
Note that "thin clients" can mean three things - a) machines that do their processing remotely, (b) machines with no local configuration or (c) diskless machines, or any combination. Let's not argue over definitions.
For example, I have noticed that the thin-client model requires a bigger server and one that after formation can only appear to handle up to 30 clients with significant power. Does this raise the relative cost savings as opposed to using a fat-client model, or do away with them altogether. Or is it that the thin-client model does in fact save money both on server and clients?
The thin client model saves a large amount of both hassle and money at all stages.
How does running thin-clients work when, say, multimedia useage is needed?
It doesn't work well with multimedia. Although you can run a number of low-bandwidth video channels down a 10MB ethernet, you normally get jerky video and interrupted sound. It doesn't work well with large classes. At one stage (when I was running on a single 256MB 500MHz Athlon) I found a class of 12 could start up and run StarOffice OK, but jammed the system when they logged off. The reason was that a class takes five minutes to start up, but when it's the end of the lesson and you say "OK, off you go" they all close down within five seconds. Now I have two p3-733's each with 512 MB, this is not a problem. But one class I have of eighteen does strain these, and if I had larger classes I'd need more power. The problem is like that faced by theatres. You need enough loos for the entire audience to use during a ten-minute interval. For most of the other 24 hours each day you need very few. But if you can install enough power for class startup/closedown, you have a very fast system the rest of the time. And your support issues are transformed. Our thin clients take negligible technician time, and nearly all the issues they face would be the same with thick clients (mouse, keybaord & cable problems). Our thick clients take vast amounts of technician time. This makes a huge difference to the number of working machines. We have one thick-client classroom, in which there's hardly ever 12 machines working out of 12, and sometimes three or more are down. We have a 21-station thin client room, in which there's hardly ever even one machine down. Our main 19-station room is similar - there are normally 19 stations working out of 19, and there's hardly ever a fault that cannot be cured by an observant pupil (e.g. push the mouse lead back in). One pro with thin clients is that you depend on server power and memory. Our 12MB thin clients can run graphic or other jobs that take hundreds of megabytes of RAM: the RAM is in the server. And most servers have very good memory sharing for the applications, e.g. "copy-on-write" virtual memory, so that if one copy of StarOffice or GIMP or Netscape takes 50MB RAM, ten copies might take 70MB and thirty 90MB. But (a con, but it affects thick clients too!) if your client graphics cards can only display 256 colours at 800 by 600, that's your limit, no increase in server power can get over that. The fact that you can't use the machines if the server is down isn't in my view a serious problem, largely because nowadays you probably can't use thick clients either. You are probably dependent on the server for any serious class work. How powerful your server needs to be depends entirely on how much concurrent access you need, because most computer applications are spiky in their demands and you can run a hundred clients off one modest server if they are used asynchronously - as we do, with stations dotted around the school. The main thing you have to eliminate is "screen savers". Another problem I have noted is when web pages have too much animation, but this is never as serious as the startup/closedown problem. But the cost savings are really tremendous, and in many non-obvious ways. We have been thin for many years, and for most of those our computer centre has drawn about fifteen amps. Installing more modern machines over the last few years has increased this load to 25 amps (that's not thick clients, it's old 486's which we use as thin clients, but newer machines with more appropriate power supplies would help a lot. Real thin clients save electricity). And we can leave our thin clients open for unsupervised access on a 24-hour basis with no problems, and in many parts of the school that are hardly ever locked. When the thieves came last term they walked away with thick clients, not thin, though I know one can't trust all burglars to be intelligent. These ones entirely avoided my unlocked computer centre and instead targeted two other areas of the school that had standard Windows machines. Nor are thieves attracted by headless rackmount servers. Thin clients are extremely resistant to the depredations of teenage boys. Most of our problems with thick clients are caused by this dangerous species, unknown to business and industry. Overall, I fail to understand why schools, who are supposed to be short of money, can ever consider thick clients as a viable proposition. -- Christopher Dawkins, Felsted School, Dunmow, Essex CM6 3JG 01371-820527 or 07798 636725 cchd@felsted.essex.sch.uk
participants (3)
-
Christopher Dawkins
-
Malcolm Herbert
-
paul munro