🚀 go-pugleaf

On Tue, 9 Dec 1997 18:11:35, Newz@inf-eden.demon.co.ux (Chris 
Kennington - newshound) wrote:

> In article <348c422b.31666353@news.demon.co.uk>
>            bob@lintilla.demon.co.uk "Bob Cousins" writes:
> 
> ">Workstation performance is dominated by sustained transfer rate and not
> ">access time.
> "
> "I think that's completely untrue. Only in very few situations do you get
> "conditions where sustained transfer rate would be dominant. [snip]
> 
>     I've been reading the part of this thread to do with access
>  rather than EIDE/SCSI in a somewhat bemused fashion.  Let's skip
>  the parts that are to do with stand-alone systems (most of the
>  posters are discussing servers), 

I believe this is your mistake.  I thought we were talking client
or stand'alone systems when we were discussing the lack of merit 
of SCSI.  I don't believe anyone questioned SCSI's usefulness in 
a server. 

>  and think about the dominant
>  factors in a network data transfer.  All this work was done in
>  CompSci departments in the 1970s (if not 1960s).

Things have changed, with cost being the primary change.
 
>     It is really not safe to say that any one factor is dominant
>  in determining average transfer-rates, except in tightly defined
>  circumstances.  I have not noticed a single post discussing the
>  effect of two simultaneous transfers (of different data), or of
>  network bandwidth limitations, etc.  

You haven't followed this discussion long then.  My argument is 
that on a client workstation SCSI is useless, with one (as I 
noted) or two exceptions.  On a server, SCSI is obvious because 
of the multiple requests and drive optomization allowed.  Not all
drives are created equal either. 

> The effects of
>  'disk-thrash', 'ethernet degradation' etc can be massive.
>  (Frinstance, in the early days of classroom networks, where a
>  single pupil could download the software in 20 seconds, it could
>  take 30 minutes for a class of 10 to do so if all started
>  simultaneously.)

This must be the limiting case of a poorly designed network.

>     In general terms, in any situation where there are likely to be
>  simultaneous transfers going on, putting reasonable figures into
>  the calculations is likely to show that transfer-rate will be
>  improved more by massive buffering, read-ahead logic and large
>  logical packets on the LAN than by speeding up raw disk-to-RAM
>  transfer rate.  The concept is to do quite a lot of one thing
>  before you switch to another, rather than switching frequently.

Sure, this is a server.  This is not what was being discussed 
(unless I cross-threaded things again).  Anyone who would argure 
against SCSI (vs. IDE) for servers is nuts.  On the desktop 
things reverse.

>  The major loss of time is associated with changing from one thing
>  to the next.  (Consider the well-known effect on car-traffic-flow
>  of making traffic-light cycle-times longer.)
> 
>     Where's my flame-proof vest?

I hope you found it ;-)>

----
  Keith R. Williams
  krw@ibm.net