omahony@swift.cs.tcd.ie (06/17/91)
In article <PCG.91Jun14183441@aberdb.aber.ac.uk>, pcg@aber.ac.uk (Piercarlo Grandi) writes: > Using a high speed machine with > high speed disks is wasted as a file server; in practice file service is > neither CPU bound nor IO bound, but network bound. and > Having a server than can provide an aggregate thruput of more > than 1MB/sec. is entirely pointless, and any modern (16Mhz) 286 AT with > some decent ESDI or SCSI disk controller and a couple of disks will do. > The argument above makes perfect sense technically, but is in complete conflict with current practice. Normally, small networks are built with a number of medium or low-powered client machines, and a fast server machine. Does anyone have a counter-argument? Does the ESDI or other fast-bus make much of a difference e.g. 10%, 20%, 50%?
dan@gacvx2.gac.edu (06/18/91)
In article <1991Jun17.145457.7964@swift.cs.tcd.ie>, omahony@swift.cs.tcd.ie writes: > In article <PCG.91Jun14183441@aberdb.aber.ac.uk>, pcg@aber.ac.uk (Piercarlo Grandi) writes: >> Using a high speed machine with >> high speed disks is wasted as a file server; in practice file service is >> neither CPU bound nor IO bound, but network bound. > and >> Having a server than can provide an aggregate thruput of more >> than 1MB/sec. is entirely pointless, and any modern (16Mhz) 286 AT with >> some decent ESDI or SCSI disk controller and a couple of disks will do. >> > > The argument above makes perfect sense technically, but is in complete > conflict with current practice. Normally, small networks are built with > a number of medium or low-powered client machines, and a fast server machine. > > Does anyone have a counter-argument? > > Does the ESDI or other fast-bus make much of a difference e.g. 10%, 20%, 50%? A fast machine will generally have more I/O bandwidth. When considering PC compatables, I/O bandwidth is currently more important than CPU speed (medium performance 386 systems still have the same speed buss that the original PC AT had.) A fast server will reduce the amount of time between receiving a client request and sending the response. A fast network will reduce the time it take for the requests to be sent (in both directions.) A faster bus will decrease the time it takes to move data from the network interface, and from the disk controler. Almost all of the above parameters apply to clients as well. I suspect that the above could be reduced to some math, but the real point is that the network isn't the only bottleneck. Data must be pipelined from the client, through the network, arround inside the server, and back out to the client, each step represents a delay. A wide bus like MCA or EISA help since they can transfer more bytes per cycle. To take advantage of them, it is best to by a network card and disk controler that can take advantage of the full width of the bus. -- Dan Boehlke Internet: dan@gac.edu Campus Network Manager BITNET: dan@gacvax1.bitnet Gustavus Adolphus College St. Peter, MN 56082 USA Phone: (507)933-7596
ecn947z@vaxc.cc.monash.edu.au (06/25/91)
>> Using a high speed machine with >> high speed disks is wasted as a file server; in practice file service is >> neither CPU bound nor IO bound, but network bound. > and >> Having a server than can provide an aggregate thruput of more >> than 1MB/sec. is entirely pointless, and any modern (16Mhz) 286 AT with >> some decent ESDI or SCSI disk controller and a couple of disks will do. >> > > The argument above makes perfect sense technically, but is in complete > conflict with current practice. Normally, small networks are built with > a number of medium or low-powered client machines, and a fast server machine. > > Does anyone have a counter-argument? > > Does the ESDI or other fast-bus make much of a difference e.g. 10%, 20%, 50%? On a small 2.5MB/sec ARCNET Novell 286 SFT LAN the console shows peaks of 40-50% server activity with reasonably heavy ARCNET activity. It appears to be Network bound. I have heard of `crashes' on a larger Ethernet/ARCNET Novell 286 SFT LAN doing 'NCOPYs' of 6MByte files from one subdirectory to another with mirrored drives. It appeared to forget about the LAN while performing the NCOPY and crashed (repeated a number of times to confirm the cause). IO Bound is the guess. A couple of 'large' XCOPYs from some fast 386/33 PCs can slow the same LAN configuration to snails pace, but no crashes. Network bound again. A >250 fileserver Novell 286 LAN `RESET ROUTER' console command can push activity to a short peak. A Higgins exchange combined with a heavy user load (60% activity), or an abnormal Higgins sorting load with light user load (5-10% activity) can push activity to a sustained 100%. Processor bound is the guess. Ethernet `storm' with few valid packets and 95-100% processor activity. Network bound, a faster processor or disks will achieve nothing. These are just a small number of examples with a few details. Normally the problem is funding and not technical, the users have the lowest cost machine to increase the number of available machines. Of course there are some fast (costly) PCs purchased for status and the normal purchasing policies may not apply. Sorry that I can recommend a perfect solution to your questions. User load on a LAN determines what you need, the person supplying the money determines what is possible, and middle management determines how poorly it will be implemented. Try some of the suggestions in Chapt 12 of "Operations research for immediate application", Woolsey and Swanson" 1975.