Path: utzoo!censor!geac!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!zaphod.mps.ohio-state.edu!caen!umich!terminator!pisa.ifs.umich.edu!rees
From: rees@pisa.ifs.umich.edu (Jim Rees)
Newsgroups: comp.sys.apollo
Subject: Re: VME SCSI controller in DN10000
Message-ID: <4e74a258.1bc5b@pisa.ifs.umich.edu>
Date: 7 Dec 90 15:43:43 GMT
References: <9012071403.AA02580@richter.mit.edu>
Sender: usenet@terminator.cc.umich.edu (usenet news)
Reply-To: rees@citi.umich.edu (Jim Rees)
Organization: University of Michigan IFS Project
Lines: 16

In article <9012071403.AA02580@richter.mit.edu>, krowitz@RICHTER.MIT.EDU (David Krowitz) writes:

     Where the trade off point is between CPU
     speed and memory capacity for caching network disk I/O is unknown at  this point.
     If anyone has done any testing, they haven't posted it to the net (hint, hint, guys
     and gals).

I think that queueing theory predicts you're better off putting your memory
on the clients than on the servers, unless your network is very fast or your
server memory size can be made larger than your total (across all clients)
working set.  I think this has even been verified by experiment for fairly
wide ranges of disk and network speed.  A guy I used to work with at
University of Washington (Ed Lazowska) did some work along these lines.

Then again, I haven't seen any work on this lately, and I don't have any
references right at hand.