Path: utzoo!utgpu!jarvis.csri.toronto.edu!db.toronto.edu!jonah
Newsgroups: comp.arch
From: jonah@db.toronto.edu (Jeffrey Lee)
Subject: Re: X-terms v. PCs v. Workstations
Message-ID: <1989Nov28.204639.11237@jarvis.csri.toronto.edu>
References: <1128@m3.mfci.UUCP> <1989Nov22.175128.24910@ico.isc.com> <3893@scolex.sco.COM> <39361@lll-winken.LLNL.GOV> <17305@netnews.upenn.edu> <1989Nov25.000120.18261@world.std.com> <1989Nov27.144016.23181@jarvis.csri.toronto.edu> <1989Nov27.213238.24130@cs.rochest <1989Nov28.223422.6817@cs.rochester.edu>
Date: 29 Nov 89 01:46:40 GMT

quiroz@cs.rochester.edu (Cesar Quiroz) writes:

>    THE PROBLEM IS NOT TECHNOLOGICAL.

Part of it is, part of it isn't.

All we can say is that the centralized horsepower seems to work better
for us.  But then we have an *unusual* setup.  Let me try to describe
it for you.

Our department is rather large.  Our computing resources are broken
into mainly area/project related *pools* of equipmemnt.  Most of the
pools are subsidiary to one of two camps.  (Nothing like a little
competition.)  Each of the main camps has large computing facility
in addition to their support of the splinter groups.

One of the camps has a predominantly decentralized (fileserver plus
workstation) model.  General users are only allowed to login to
workstations leaving the file servers to manage NFS requests plus one
other task (mail, nameservice, news, YP, etc.)  Performance used to be
miserable in the middle of the day with constant
NFS-server-not-responding messages and *slow* response for swapping.
This has improved somewhat recently due to changes in the setup of our
news system.  [Thanks Geoff and Henry.]

The other camp has workstations and X-terminals.  It allows users to
login to one of two combination file/compute server machines.  The
workstations are mostly used to run an X server with remote xterms for
login sessions.  All CPU time is charged at the SAME hourly rate to
encourage users to run their jobs on the fastest machines.  The
reason:  swapping over NFS puts a higher load on the servers than
running the same jobs on the central machines.  Also, more gain can be
had from adding 32MB to each server than adding 4MB to each
workstation.

[We also have access to a more traditional centralized computing
service, which is largely ignored by most members of the department.]

Both camps are relatively open on quotas: they are imposed from below.
You (or your sponsor) are charged for your CPU, modem/workstation
connect time and disk usage.  When your disk partition fills up, you
can't create any more files.  [Any everyone in your partition will gang
up on you if you are at the top of the disk usage list.]  CPU and
connect charges are regulated by your sponsor (who complains when your
bill gets to high).  [Terminal connections are not charged for connect
time and minimal-priority jobs get cut rate CPU.]  The rates are scaled
to cover costs and help expand the facilities--not to make money.  Both
camps provide centralized backup, system administration, and
expertise.

Both camps are expanding their facilities.  The centralized computing
camp is planning to add more memory to one of the central machines
which is starting to get bogged down with swapping.  They are also
planning to buy more X-terminals to improve accessibility.  The
distributed camp is waffling on adding memory to each of their many
workstations.  A new four-processor CENTRALIZED COMPUTE server is also
now coming on stream in EACH of the two camps.

The net result: our experience show that (our brand of) centralized
computing is a win over diskless-workstations.

j.

Disclaimer: mileage may vary...


Brought to you by Super Global Mega Corp .com