Apparently Derek replied personally by accident?
Anyway... ---------- Forwarded Message ---------- > There is a city in the US, Largo, that does it's entire administration (a > few > hundred clients I think) on thin clients. They say an extra KDE session > weights in at an extra 11 megs of ram. Add to this apps (lukily memory > management in linux is good, it shares all the mem it can so app's don't > get > loaded twice). Star office is a bigger problem. You have the advantage you > only got to start it once but I maybe it's a good idea to try how many mem > an > extra openoffice program takes by starting like 10 staroffices as different > users on the same machine, with swap disabled, just to see how much mem > each > extra one takes. > > As for network, remote X is pretty bandwidth-intensive. It's best to > separate > NFS server and the server with the powerful cpu's where the X clients run. > Put gigabit stuff in each, consider maybe making use of the bonding driver > support if that works with ltsp (no experience, my personal setup only has > 1 > client :-) ). > For the nfs server, where probably the swapfiles will be located (saves on > electricity if your clients are diskless): use REAL fast hard drives. > For the ltsp server: You'll need whole gigs of ram (Go for 8) and a quad > CPU > system at least. Maybe it's best to set up some test case with 30 clients > or > so and see what disk speed and memory that requires. Forget about using > ia32 > or ia64 as an ltsp server, it's unscalable or dead-slow. Consider using a > system with alpha processors or something like a sun server - well figure > it > out for yourself, I always find it funny to assemble dream machines I can > never afford :) . If I start from a sun fire v880 I end up spending 120000 > USD, that's about 240 per client, which means you're going to spend way > more > money per client on the servers as on the clients - which you can get in > bulk > from some bankrupt company ;). I recommend pentia for the clients with 32 > megs of ram. 16 is possible, but will put a greater strain on your > swap-server. It will depend on your screen resolution and on how fancy you > want your desktop to be how much mem you'll need (images stuff are stored > server-side, I mean: in the X-server's side.) I exchanged a couple of e-mails with the guy that did the Largo project. That seems very successful. My understanding based on my conversation with him is that he has a login server that handles the logins and kde sessions, and then all the applications run on separate servers. For example, if you were providing StarOffice, there would be a StarOffice server, and the users would click an icon that would fire up StarOffice on another box via rsh (or ssh.) Of course, depending on the load, you could put multiple applications on one of the "application" servers. This serves a couple of purposes. If you have a hot login server that is just handling the sessions, you can handle a lot of concurrent sessions on one login server. Also, if you have separate application servers, if one process runs away on you, the worst it can do is bring down one application. I have been playing around with this on my system. When I click the Mozilla icon from a LTSP session on my system, it fires up mozilla on one of my office desktop machines. As soon as I get a few minutes, I'll write up a quick document on how to do this. While this might not be the most efficient way to scale, it strikes me that it is a very reliable way. I would disagree that ia32 or ia64 can't do it. That's the beauty of LTSP, Linux and X Windows. You have the choice of using inexpensive, commodity hardware to accomplish what used to only be possible with expensive, proprietary hardware/software. The user never has to know where the processing/memory is happening and you can add/distribute resources as necessary accross multiple boxes if you need to. HTH, Derek -- Derek Dresser Gould Academy Bethel, ME 04217 (207)824-7700 ------------------------------------------------- This mail sent through IMP: http://horde.org/imp/ ------------------------------------------------------- _____________________________________________________________________ Ltsp-discuss mailing list. To un-subscribe, or change prefs, goto: https://lists.sourceforge.net/lists/listinfo/ltsp-discuss For additional LTSP help, try #ltsp channel on irc.openprojects.net
