🚀 go-pugleaf

In article <pLMYl5dhX7hK-pn2-bmRtSYdnH0CM@ALEX>
           krw@ibm.net "Keith R. Williams" writes:

">     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.

    Umph.  I've read (or at least skimmed) about 100 posts.  Most
 of the pro-EIDE ones failed to restrict themselves to clients
 And big servers, including eg RAIDs and other multi-drive
 topologies, have featured quite a lot.

">  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.

    "Things", ie the logical activities involved in pulling data
 off a disk, buffering it, sending it down a MAC (ethernet-type) cable,
 buffering it at the other end and transferring to another disk
 have not changed in the least (though the commercial offerings
 have).  The 1970s computer science is perfectly valid, provided
 that the new (?) techniques of sequencing and buffering are
 factored in.  Cost is not an element of such equations.

">     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.

    See comment above.  You may well be right.  The point I am
 making is that it is by no means obvious that the raw disk/RAM
 data-rate on the disks is the dominant factor in a networking
 situation, or for that matter in any multi-threading or multi
 access situation.  Even if the network, ie the MAC-cable
 problems, are factored out, there will undoubtedly be a stage of
 multi-activity on a single-user multiple-simultaneous-process
 computer where the required disk access becomes so chaotic and
 the buffering requirements so large that seek times will be the
 dominant factor.  Whether any current activities even approach
 this point, I do not know.  (I'm tempted to think that Grim95
 would actually become the limiting factor long before <g>).

">  (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.

    Design was well optimized.  Hardware supported only a slow rate
 on the MAC-cable, and the disks involved (pre-MFM) were dead
 slow.  Z80s were not good at using extra store for buffering.  So
 if more than one or perhaps two pupils tried to download the
 software at once, there was a shocking combination of disk-thrash
 and packet-collisions.  (And this was, I think, before CSMA had
 replaced the early MAC logic.)  But it is still a good example of
 the necessity of locating the limiting factor of performance
 correctly.

    Perhaps it is a pity not to start new threads when several
 rather different subjects come up.  And the number of posts and
 subjects (also, for that matter, opinions) has been large.

                                    Chris K.
-- 
Chris Kennington (newshound)                        01491 574065
  You can mail me with suitable modifications to header-addresses,
   or to "chris <at> inf-eden.demon.co.uk", replacing the <at>.