Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!apple!bloom-beacon!tut.cis.ohio-state.edu!husc6!rice!sun-spots-request
From: sgf@cfm.brown.edu
Newsgroups: comp.sys.sun
Subject: Re: Are fileservers a waste of money
Keywords: Hardware
Message-ID: <8905091642.AA01538@snake.lfm.brown.edu>
Date: 16 May 89 14:56:42 GMT
Sender: usenet@rice.edu
Organization: Sun-Spots
Lines: 79
Approved: Sun-Spots@rice.edu
Original-Date: Tue, 9 May 89 12:42:42 EDT
X-Sun-Spots-Digest: Volume 7, Issue 287, message 1 of 13

The basic question here is how to most efficiently distribute disk, memory,
and server cycles. You want to avoid buying another server or upgrading
CPU whenever significant performance gains can be had through cheaper
means.

For both OS 3.5 and 4.0:

Most people want at least an 8MB machine. Except for the sys-admin, there
isn't really anyone who can use 4MB painlessly in today's application and
development environments. 4MB machines put an unfair paging load on the
server.

For OS 3.5:

The server bottleneck is the >>ie<<, not CPU or disk (well, disk can be
if you're runniing slow controllers). Let's assume that you've got a 451
with 2 SMD disks and a Ciprico (my preference in SMD controllers) with 2 SMD-E
disks on a 3/280 that serves 4MB 3/50's. If the 50's average VM usage is
12MB then neither the CPU nor the disk I/O capacity of the 280 will be 
anywhere near max'ed. It'll be the poor 16b ie chugging along on its
slow driver which slows the server (the bulk of the server load is nd
page faults with some swapping). (AND there's no point in a server with
more than 4MB if you're not allowing user logins).

For OS 4.0:

(...and the above descibed hardware...) (I haven't been willing to try
this until I upgrade the 50's to at least 8MB.)
There's been a lot of talk from people at Sun claiming that 4MB 50's can
run well under 4.0 with proper tuning. I think that they can limp along
(I have used them, but I don't want them on my network, which is CFD 
research...). The most painful effect of a 4MB 4.0 50 is on the server
load. Even if the buf cache on the server goes into memory pig mode
(makes the disk I/O faster, saves some CPU), 4.0 has the nasty
effect of increasing the server CPU required for a client page fault (no
RG, NFS can't possibly run in as few cycles as nd) to the point that a 3/280 
CPU max's out before the ie (I postulate this based on some hard performance 
monitoring on two networks: 3.5 3/280 serving 4MB 3/50's (our network); 
multiple 4.0 4/280's serving 8MB 3/60's (browncs). I hope to confirm it soon 
by installing 4.0.1 on our network just before popping in the memory 
upgrades.). I assume that a 4/280 with enough load will once again max out the 
ie before anything else (anybody have a driver for the 32b Interphase Eagle? :-)


The bottom line is that (especially given the product line pricing
structure - gee, isn't it a shame when companies get too big...):

1. Check to see where your bottlenecks are and what is causing the load
   (paging or normal NFS operations).

2. If the load is paging and the limit is the ie definitely put more
   memory in the clients.

3. If the limit is disk I/O get a faster controller and/or more disk and
   distribute the client root/swap evenly among all disks. (and if the
   load is paging put more memory in the clients.) There is basically no
   reason for a server to be limited by disk I/O.

4. If the load is paging and the limit is CPU (especially under 4.0) put
   small (minimize cost) SCSI disks on the clients for swap space (after
   being sure that they have a reasonable amount of memory). There are
   plenty of suppliers of small (5.25" form factor) enclosures with
   integral power supplies, so grow your own shoeboxes.  


One thing that irks me is that  (as an example) Sun COULD sell a
modified 3/280 with >>3X<< the server performance capacity for an
addtional $12,600 list, and at the SAME MARGIN (no additional disk;
based on the Dec. 1, 1988 price list). The same sort of thing could be
done for any of the servers (of course it would mean selling fewer
servers :-(.

Maybe now that X-terminals are getting popular Sun will take the NeWT
(NeWS Terminal) out of mothballs...

Sam Fulcomer, Head Zookeeper
Brown University Center for Fluid Mechanics, Turbulence and Computation
sgf@cfm.brown.edu
uunet!brunix!sgf