Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!cornell!uw-beaver!rice!sun-spots-request
From: aarons%cogs.sussex.ac.uk@nsfnet-relay.ac.uk (Aaron Sloman)
Newsgroups: comp.sys.sun
Subject: Re: Are fileservers a waste of money
Keywords: Hardware
Message-ID: <11565.8905061911@csuna.cogs.susx.ac.uk>
Date: 11 May 89 10:57:31 GMT
References: <550@trlamct.oz>
Sender: usenet@rice.edu
Organization: Sun-Spots
Lines: 74
Approved: Sun-Spots@rice.edu
Original-Date: Sat, 6 May 89 20:11:35 BST
X-Sun-Spots-Digest: Volume 7, Issue 283, message 5 of 13

munnari!trlamct.oz.au!paul@uunet.uu.net (Paul Elliott) writes:
[I've abbreviated quite a bit]

> fileserver	Sun3/260	16M memory	xylogics 451
> 						1 x fujitsu eagle
> 						1 x fujitsu swallow
> 1 x client	Sun3/60		12M memory	(lisp programming)
> 3 x clients	Sun3/50		4M memory	(lisp programming)
> 2 x clients	Sun3/50		4M memory	(C & fortran)
> The performance of the above network can deteriorate markedly as swapping
> activity increases.
>
> We will be adding some extra clients over the next few months and wish to
> upgrade the existing hardware and/or buy a more powerful server.
>
> What we would like to know is where to spend the money.

Here is an unconventional answer: Do as much of your AI-type programming
as possible on a powerful central server with a lot of memory (> 32 Mbytes
if possible) and use your 3/50s and 3/60s only to manage windowing and
graphics. This works fine with a networked window manager.

This recommendation is based on the following assumptions:

1. each user is mostly typing into an editor and using a relatively small
working set much of the time, but occasionally requires a large working
set, causing paging on a small machine.

2. programs are rarely CPU-bound (not true if you are doing image
processing or neural net simulations, for example).

3. each user is going to need a garbage collection (GC) every now and
again, and when that happens (especially on a 4 Mbyte machine running a
big program) there will be an awful lot of paging across ethernet to the
server. This will slow EVERYTHING down.

4. Disk traffic is enormously reduced if enough memory is available during
a GC to avoid paging.

5. If a lot of the memory is allocated to a process when it requires a GC
this will generally interfere with other processes FAR less than all the
paging would.

6. Assuming (2) above, the gains obtained from 5, plus the fact that the
server has a much faster processor, considerably outweigh the losses
resulting from having to share the server CPU. (This argument becomes even
stronger if the server is a Sun-4, or something even more powerful.)

7. The only way to get equivalent performance without putting all your
lisp processes on the server is to buy so much memory for each diskless
machine that it does not need to page during a GC. This will generally be
a far more expensive solution.

The above argument will not apply to all patterns of work. Eg. if your
program is doing a LOT of graphics and screen manipulation, doing it over
ethernet from the server could be worse than the paging during garbage
collections.

However, my belief is that for many kinds of teaching and research, the
best approach is to time share a large powerful central machine using
relatively cheap workstations to handle windowing and graphics. We do
this, and even have some VDU users logging through to the server.

Aaron Sloman,
School of Cognitive and Computing Sciences,
Univ of Sussex, Brighton, BN1 9QN, England
    INTERNET: aarons%uk.ac.sussex.cogs@nsfnet-relay.ac.uk
              aarons%uk.ac.sussex.cogs%nsfnet-relay.ac.uk@relay.cs.net
    JANET     aarons@cogs.sussex.ac.uk
    BITNET:   aarons%uk.ac.sussex.cogs@uk.ac
        or    aarons%uk.ac.sussex.cogs%ukacrl.bitnet@cunyvm.cuny.edu

    UUCP:     ...mcvax!ukc!cogs!aarons
            or aarons@cogs.uucp