[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [seul-edu] X-Terminals - Opinions sought
On Sat, 23 Oct 1999, Pete St. Onge wrote:
> This is sort of off-topic, but here goes:
> I know of a school having a roomful of P100 and P133 boxes with bootable
> nics. These machines would boot into Win3.1, and all apps would run
> locally (in local memory space).
> The intent for that lab is to upgrade the machines sufficiently to run
> Win NT. Unfortunately, that means adding hard drives to all of the
> machines, as well as licencing issues. And unless they increase RAM and
> processor speed, this is going to be a very scary proposition. Either
> that or a very expensive one.
> What I'm trying to suggest to them as an alternative is to buy 2-3
> other machines to run as linux-based application servers (using X) and
> NIS. One server would also run NFS. Since the local boxes are already
> booting off the server, this should present no real client config
> issues. Running NFS will allow everyone to have their own home
> directories of substantial size (50 MB or so), proper network
> permissions, and the money saved on client station upgrades could be
> spent on larger monitors/PCI video cards, zip disks, etc).
Sounds similar to what I am trying to do (94GB of RAID 5 (with hot spare)
storage, big app servers, etc).
DO NOT RUN LINUX on the NFS server. Linux NFS SUCKS!!! I have been
dealing with this for the past three months, trying Coda and AFS to fix
it, etc. What we will be doing is using FreeBSD for the NFS server.
> Much of the software being run will be fairly unspectacular, mostly text
> and spreadsheets. There will be other applications that would demand a
> little bit more in terms of power (some stats programs as well as a
> mapping program), but these will be rarer.
StarOffice would fit the bill well. You will need a good amount of ram in
the App Servers (I am looking at 4 app servers myself, each with 512MB of
ram, maybe 768 depending on prices when we get funding for this).
> Based on this though, I would like to ask for opinions and a few
> - Will running 17" or 19" monitors at good resolutions, say 1200*800
> or 1600*1200, on the clients impose a substantially greater load on
> the network (100BaseT) than running 15" monitors @ 800*600?
I would not go wtih 19" monitors, unless money is really plentiful. a
good 17" will be fine, and I would run it at 1024x768 at the most. X can
eat up a lot of power and bandwidth if you go over that. Also consider
running 16 bit color (though 24bit will work).
Another thing you will want is switched to the desk. Switched 10Mbit is
fine, but X uses a lot of small UDP and TCP packets, and it does much
better going over a switched connect to the workstation.
We are going switched 10 (on a netgear FS524 switch, 10/100 on all ports),
due to the nics we have. After a NIC upgrade, they will be on switched
> - If so, would having three identically configured application servers
> (good machines) be sufficient to ensure good servicing of the
How many clients? I am looking at four K7-550Mhz systems with 512MB ram,
to handle about 60 systems. We are running things like Wine, Basilisk II
(Mac Emulator, etc).
> I'm not really looking for definitive answers here, rather I would
> greatly appreciate any ideas or gut-feelings that folks might have,
> particularly if they are based on their experiences playing with X.
> I think I can make a very good case for this, not only financially, but
> as a solution which maintains currency over the next decade (which
> realistically is how long it will be in place) rather than until the
> next version of NT.
Yep, a simple upgrade to the app servers (extra ram, new motherboards)
will result in a speed boost for EVERYONE. Also remember that a system
that might seem like it would be a little too slow might not be, since
idle time is used up by other students (especialy if this is a free use
This type of setup is NOT quick to setup the first time. I would probably
suggest the ENTIRE summer vacation, for about three people.
> Many thanks.
> > Pete >
> Pete St. Onge