[comp.unix.aux] Academic workstations -- Followups to comp.unix.questions ONLY

cline@sun.soe.clarkson.edu (Marshall Cline) (06/10/89)

To avoid confusion, followups to this are requested to ONLY go to one
newsgroup.  I suggest comp.unix.questions.

In article <507@lclark.UUCP> cullum@lclark.UUCP (Mike Cullum) writes:

>We are in the process of considering the purchase of workstations for
>a small lab in our Computer Science Department.  Our proposed 
>configuration calls for 8 workstations (8Mb RAM, 200+Mb disk, large
>monochrome display) and a server.  
>...
>Any advice?

Clarkson University has quite a number of workstations, so I guess I
have enough experince to answer.  However (almost) all ours are Sun's,
so I can't compare.  However, I can _STRONGLY_ recommend one feature
in particular:

We have a SINGLE disk server in our School of Engineering, all other
workstations being diskless (thin wire 10Mb/s Ethernet), being
connected via Sun's NFS.  There are probably 20 or more "clients"
running off this one server.  Although we're pushing the performance
of the disk server, the concept of a single disk server is the BEST
THING SINCE SLICED BREAD.

The problem can be illustrated with our micro-computers (5000 or so AT
class machines on the campus, well over 1000 with hard disks).
Consider a student "Joe".  Joe's files are on a particular machine.
If that machine is busy today, he has to copy his files onto whatever
machine he happens to get.  Thus he duplicate all his files on all the
machines he might be working on.  Then there's the "which is the
latest version?" question.  The end result is that our students have
to floppy-jocky everyday.

Having a central location for files (the disk server) means that each
workstation that you log onto acts like it has your files.  No two
versions, etc.

Thus your comment for workstation having a 200+Mb disk is one which you
may want to reconsider.

There's a binary-compatibility problem with the NFS scheme, but we have
almost all Sun-3's (68020, 68881).  When we go to SparcStations (Sun-4's),
we'll have to address the multiple /bin directories, etc.

Hope this helps.
Marshall
--
	________________________________________________________________
	Marshall P. Cline	ARPA:	cline@sun.soe.clarkson.edu
	ECE Department		UseNet:	uunet!sun.soe.clarkson.edu!cline
	Clarkson University	BitNet:	BH0W@CLUTX
	Potsdam, NY  13676	AT&T:	(315) 268-6591

rpd@apple.com (Rick Daley) (06/10/89)

In article <CLINE.89Jun9165618@sun.soe.clarkson.edu> 
cline@sun.soe.clarkson.edu (Marshall Cline) writes:
> We have a SINGLE disk server in our School of Engineering, all other
> workstations being diskless (thin wire 10Mb/s Ethernet), being
> connected via Sun's NFS.  There are probably 20 or more "clients"
> running off this one server.  Although we're pushing the performance
> of the disk server, the concept of a single disk server is the BEST
> THING SINCE SLICED BREAD.
> 
> The problem can be illustrated with our micro-computers (5000 or so AT
> class machines on the campus, well over 1000 with hard disks).
> Consider a student "Joe".  Joe's files are on a particular machine.
> If that machine is busy today, he has to copy his files onto whatever
> machine he happens to get.  Thus he duplicate all his files on all the
> machines he might be working on.  Then there's the "which is the
> latest version?" question.  The end result is that our students have
> to floppy-jocky everyday.

The original question had to do with which UNIX workstation to buy for a 
student lab.  I'm obviously biased about that, but I do have a comment
about Marshall's push  for a diskless environment.  His argument is that
this keeps students from having to use  floppies to move
their files between machines in the lab.  Well, this is indeed important, 
but it has nothing to do with whether the machines should be diskless.  
All this means is that student's files should be stored on an NFS file 
server.  The machines could still have local disks which are used for the 
OS and for paging.  This should give you better performance because local 
disks should be faster than networks, but it also adds to the cost and 
administration effort.

                                                Rick Daley
                                                rpd@Apple.COM

bzs@bu-cs.BU.EDU (Barry Shein) (06/10/89)

>This should give you better performance because local 
>disks should be faster than networks, but it also adds to the cost and 
>administration effort.
>
>                                                Rick Daley
>                                                rpd@Apple.COM

Bad guess, go measure it, because servers almost always have faster
disks, controllers and bigger disk buffers remote disks are usually
faster than local disks (assuming a reasonable network loading which
doesn't have to be zero.)

An ethernet can deliver data at almost 1MB per second, go look at the
specs on your standard 27msec SCSI cheapo, 20KB/sec is not unusual for
maximum disk transfer rate, about 1/40th the speed of an ethernet.

In some cases remote disks are much faster, particularly where the
server CPU is much faster (and the disk system) and your process is
causing some amount of parallelism to occur (this doesn't have to be
purposeful, something simple like a find with a grep on each file can
end up exploiting both CPUs as one resolves the file system as the
other pumps away at the raw data.) Remember all those gripes about the
overhead of namei()? Where do you think namei() is running in an NFS
environment?

Many network load problems are due to badly configured or managed
networks with lots of junk traffic (eg. ARP or other broadcast
screamers going unchecked.)

However, I will agree that blaming it on the diskless workstations is
a wonderful alibi, the yokels believe you and rarely ask you to
actually do your job and find out what's really causing the problem.

It's the diskless workstations, it's the diskless workstations (we
know those diskless workstation users will never buy the local disks
you recommend so it's a safe bet to blame it on them.)

Another problem is political, the enforced memory shortage has
temporarily made the disk/memory balance unnatural. But don't confuse
economic realities with technical ones.

I agree none of this would apply to a Mac-II acting as an NFS server,
it doesn't support the disk architecture necessary to get any
performance advantage over a local disk.

I am not saying there aren't cases where a diskful workstation is far
better, I'm just saying most people don't know what they're talking
about or have motives other than understanding the technology.
-- 
	-Barry Shein

Software Tool & Die, Purveyors to the Trade
1330 Beacon Street, Brookline, MA 02146, (617) 739-0202

grunwald@flute.cs.uiuc.edu (Dirk Grunwald) (06/11/89)

>> Bad guess, go measure it, because servers almost always have faster
>> disks, controllers and bigger disk buffers remote disks are usually

This isn't really true, you know, unless you always buy the most up to
date controller. Smaller disks get better faster, and your incremental
cost is much much lower.

E.g., we have two CDC Sabre drives, 741 controller serving a 3/260. Total
cost at the time (university discounts, etc), about $27,000 for everything,
and we get about 650Mb of storage plus a fast central server if you need
compute-bound jobs (although extensive use of the server slows down everyone
else). The disk has about 1.5Mb/second transfer and 16ms seek

You can buy SCSI CDC Wren-V's that have 1Mb/second transfer rates & 16ms seek
for about $2500. Pick up 10 of those for your 10 clients that you can
serve off the 3/260 & you get 6000Mb of storage, and you still have enough
left over to buy a 2Gb tape backup system.

You get system redundancy (i.e. if a disk croaks, make that station be
a client of another), higher aggregate throughput and 10x the storage.
You don't have the central server, but hey, that can be an advantage
since you can now mix & mach your configuration (i.e. you want 10 stations,
now you have have 5 Sun/i386 stations & 5 DEC-3100's).

--
Dirk Grunwald -- Univ. of Illinois 		  (grunwald@flute.cs.uiuc.edu)

bzs@bu-cs.BU.EDU (Barry Shein) (06/11/89)

Yes, Dirk, you're right, a PDP-1 with drum memory is probably not a
cost-effective NFS file server these days. Thanks for pointing out
this oversight in my message.
-- 
	-Barry Shein

Software Tool & Die, Purveyors to the Trade
1330 Beacon Street, Brookline, MA 02146, (617) 739-0202

grunwald@flute.cs.uiuc.edu (Dirk Grunwald) (06/11/89)

oooo..cheeky cheeky

The 3/260 is less than a two years old.

At that time:
	+ Wren IV had same bandwidth as Wren V, less density.
	+ 741 was best controller available on the market, other
	  than Rimfire, which didn't work with 4.0

Hardly a PDP/1.

The point of the message was that disk aggregate bandwidth increases faster
for smaller disks; central file servers devote high $$ resources to
serving clients. The ability to incrementaly upgrade your system decreases
(witness that we still have that 741) and your total performance is poor.

For example, a 3/60 with a local CDC Wren-V runs small latex jobs about
10% to 20% faster than a 3/60 serviced by a an idle file-server on an
idle network. And it'll do it for less money.


--
Dirk Grunwald -- Univ. of Illinois 		  (grunwald@flute.cs.uiuc.edu)

spector@vx2.gba.nyu.edu (Alexis Rosen) (06/12/89)

Barry Shein posted a message proclaiming the virtues of network servers.
I don't have anything to say pro or con for this position- I'll leave
that to those better qualified. He also stated that the Mac has very
slow disk channel speed, and quoted an average time for small disks of
20KB/sec.

This number is ridiculous. Even the Mac Plus can do better than that.
You'll see about 50KB/sec. with cheap 20-30MB disks. You can do quite a
bit better with the faster ones. But this article wasn't discussing
Mac Pluses, but rather Mac IIs. And the difference between the two is vast.

I have attached to my machine three disks: and old Quantum Q280, a
Wren III half-height (90MB), and a Wren Runner full-height (320MB).
The old Quantum, which has a lousy controller, does about 5Mbit/sec.,
or abuot 625KB/sec. - roughly 31 times faster than Barry's estimate.
The Wrens are much faster. The (also old) Wren III does better than
1MByte/sec., and the Runner (which is the fastest disk 5.25" disk I
know of) consistantly does better than 1.5MBytes/sec, more than 75
times faster than Barry's claim.

For all this, I won't say the Mac has a particularly fast disk
channel. It doesn't, and it has no provision for DMA. Fortunately,
this will be corrected this summer. Apple will likely be introducing a
macine with a faster DMA SCSI controller. Even if it doesn't, though,
for $600 you'll be able to buy a synchronous SCSI DMA board that
should drive disks like the Wrens at about 4MB/sec. (burst, of course,
since disks can't suck up information that quickly off their platters).

---
Alexis Rosen
spector@vx2.gba.nyu.edu (temporary guest account)
alexis@rascal.ics.utexas.edu  (last resort)

heberlei@iris.ucdavis.edu (Todd) (06/12/89)

In article <32705@bu-cs.BU.EDU> bzs@bu-cs.BU.EDU (Barry Shein) writes:
[stuff deleted]
>However, I will agree that blaming it on the diskless workstations is
>a wonderful alibi, the yokels believe you and rarely ask you to
>actually do your job and find out what's really causing the problem.
>
>It's the diskless workstations, it's the diskless workstations (we
>know those diskless workstation users will never buy the local disks
>you recommend so it's a safe bet to blame it on them.)
>
[stuff deleted]
>-- 
>	-Barry Shein
>
>Software Tool & Die, Purveyors to the Trade
>1330 Beacon Street, Brookline, MA 02146, (617) 739-0202

I have been doing traffic analysis, and it is our diskless
workstations which are pulling down our network.  Our network
throughput is starting to drop because of the high collision rate,
BUT...

I work in a reasearch environment (and the two other places that I
have checked were research environments), so we have lots and lots of
workstations with lots of users pushing the workstations pretty hard.
If you have only a small isolated lab (or one connected to a larger
network by a bridge (not simply a repeater)), diskless stations may be
a better buy.

(The poor poster who started this thread probably has given up on
getting his original question answered)

Todd Heberlein

markley@celece.ucsd.edu (Mike Markley) (06/12/89)

In article <507@lclark.UUCP> cullum@lclark.UUCP (Mike Cullum) writes:
>
>>We are in the process of considering the purchase of workstations for
>>a small lab in our Computer Science Department.  Our proposed 
>>configuration calls for 8 workstations (8Mb RAM, 200+Mb disk, large
>>monochrome display) and a server.  
>>...
>>Any advice?
>

It somewhat depends upon what your overall objective is but
here is my $0.02.  If you want a distributed file system where
you have access to all of your files from any workstation
without having to copy them to the local disk buy Apollo
workstations.  The Apollo file system is IMHO orders of
magnitude easier to administer than NFS.  The Apollo registery
is also easier to set up and administer than Yellow Pages from
SUN.  In SUNs favor is cost and amount of inexpensive software
available.  This is becoming less of a factor now that SR10
from Apollo is available.  Just configure your machine as a
BSD4.3 machine and the compatability questions dim.  If you
need to develop graphics software the SUN is easier to program
unless you go with X-Windows and then the systems are the same.
The X11R3 software is much more stable on the SUNs then it is
on the Apollos.  If you are looking for pure integer
performance than SUN is much more cost effective.  The
SparcStations are very fast in the integer environment.  For
floating point I would say consider buying a fast server and a
bunch of cheap diskless workstations.  You can put 2.8Gigabytes
on an Apollo DN10000 and then run all of you diskless stations
of of this.  It is several times faster than the SparcStations
for floating-point calculations.

My recommendation overall is to go with Apollo.  Their
workstations are IMHO much easier to take care of and their
network is much easier to grow.  A single command adds new
workstations, and the workstations file system(s), to the network.

Mike Markley
University of California, San Diego
markley@celece.ucsd.edu
markley@kubrick.ucsd.edu

darcy@tci.UUCP (Jeff d'Arcy) (06/13/89)

In article <32705@bu-cs.BU.EDU> bzs@bu-cs.BU.EDU (Barry Shein) writes:
>
>>This should give you better performance because local 
>>disks should be faster than networks, but it also adds to the cost and 
>>administration effort.
>>                                                Rick Daley
>>                                                rpd@Apple.COM
>
>Bad guess, go measure it, because servers almost always have faster
>disks, controllers and bigger disk buffers remote disks are usually
>faster than local disks (assuming a reasonable network loading which
>doesn't have to be zero.)

Certainly, servers (at least those configured by sane administrators)
are likely to have faster, bigger disks etc. than would be feasible
for individual workstations.  However, latency is likely to suffer due
to the overhead associated with protocol encapsulation etc. especially
in heterogeneous environments.  If the application is doing something
simple such as a huge block transfer the performance hit won't be that
bad, but more complex operations involving random disk accesses will
hurt.

>An ethernet can deliver data at almost 1MB per second, go look at the
>specs on your standard 27msec SCSI cheapo, 20KB/sec is not unusual for
>maximum disk transfer rate, about 1/40th the speed of an ethernet.

At risk of repeating myself, this observation only applies to the simple
case where transfer speed is the limiting factor.  Unfortunately, latency
is frequently more important and is the first thing shot to h*ll in a
network environment.

>[very good points about parallelism and network administration
> deleted to save network bandwidth]

>However, I will agree that blaming it on the diskless workstations is
>a wonderful alibi, the yokels believe you and rarely ask you to
>actually do your job and find out what's really causing the problem.

>It's the diskless workstations, it's the diskless workstations (we
>know those diskless workstation users will never buy the local disks
>you recommend so it's a safe bet to blame it on them.)

>[attempted disclaimers deleted]

>I am not saying there aren't cases where a diskful workstation is far
>better, I'm just saying most people don't know what they're talking
>about or have motives other than understanding the technology.

"...don't know what they're talking about..."?  Disagreement is not
a sure sign of one party's ignorance, Barry.  I'm not saying that
local disks are the one and only way to go, but they are superior for
a wide range of applications.  I make my living in this field and I
am probably not alone in being offended by your implication that those
who disagree with you on this point are either foolish, lazy or
dishonest.