Chris Holten wrote in a message to George Fliger:
 CH> SCSI does make the Vendor a bit more profit and there is
 CH> some kind of "down the road" justification for the client,
 CH> but that wasn't the point of the original message. They guy
 CH> already had a 6.4 gig WD Eide drive. You and mike tried to
 CH> make him think that he couldn't/shouldn't use that, instead
 CH> he oughta to go get a SCSI setup to gain 0 (Zero) increase
 CH> in performance on his novell server, cause according to you
 CH> two, you just always have to have SCSI on a novell server no
 CH> matter what the server is being used for, how many users it
 CH> has and whether it is 10bt or 100bt is irrelevant.
I went back and found the original post of the question by Mufutau Towobola:
   Is anyone here using the new Western Digital EIDE 6.4gig hard drive
   on their Novell Netware v3.12 or 4.1x server? Please how is the
   performance or if there is anything I should watch-out for. Thanks.
Now, MT is something of a regular in this conference, and I think he asked a 
fairly straightforward question.  He specifically asked for a comparison of 
performance, and that was the question that was answered.
 CH> (No body ever got fired by buying IBM either).
Certainly, I never would be.  :-)
 CH> Your comments, experieces on the matter were *obviously* not 
 CH> based on modern 1997 EIDE setups with moder pentium class 
 CH> chipset/bios or benchmarks on a 10bt ethernet. The type of 
 CH> performance example cited seems to me to be based more on 386 
 CH> and early 486 IDE/Bios/Chipset technology.  No doubt 3-10 years 
 CH> ago, SCSI could be significantly faster in a dedicated network 
 CH> file/print server environment and if that was the kind if 
 CH> equipment being used, you are spot on, especailly considering 
 CH> that back then memory was much more expensive and dedicated 
 CH> novell servers usually were not over endowed with RAM memory. 
 CH> That's all changed.
I think that you underestimate the level of experience possessed by some of 
the participants in this conference.  Personally, I feel that I have a pretty 
good understanding of how these I/O subsystems work because I've written the 
device drivers for them.
 CH> Modern EIDE setup will indeed much much more than saturate
 CH> the bandwidth of a 10BT ethernet cable. (10-18,000kbs for
 CH> EIDE vs at the very most 550kbs for 10bt ethernet). 
(Let's use lower case "b" for "bits" and use upper case "B" for "bytes.")
First of all, your math has some problems.  Sure, there is some overhead in 
sync leader and that sort of thing, but the theoretical bandwidth limit for 
10 Mpbs Ethernet is simply (10 Mbps) / (8 bits/Byte) = 1.25 MBps.  As a 
practical matter, you should be able to get realistic transfers of 900-1000 
kBps with even the most top-heavy protocols, such as TCP/IP -- if you have 
sufficient processing resources behind you.
On the other side of the coin, as it were, the disk is not capable of 
transfers at the speeds you are mentioning except from its local cache, which 
is typically very small, often only a few sectors for an IDE drive.  This is 
why the server-class SCSI drives have gone to UltraWide connectors and to 
higher rotational speeds, first to 7200 rpm and then to 10000 rpm.  On a 
really top-of-the-line IDE drive, I might be able to squeak out 2-3 MBps of 
sustained transfer rate -- "sustained" being the key idea here.  On a 
top-of-the-line 10000 rpm SCSI drive, I could sustain transfer rates 
approaching 10 MBps.
 CH> In view of those througputs, if you can only realistically
 CH> poke at most 550kps through a 10bt ethernet cable, how can
 CH> you possibly have the eide use anywhere near 30-50% of the
 CH> CPU just to retreive data off the hard drive. What is that
 CH> other 50% CPU capacity going to do?
To begin with, the CPU is going to figure out which data to read or write, 
whether it is in cache, whether you have access to it, whether it is or can 
be locked from access by other users, and so on.  In addition, the CPU has to 
allocate its processing and I/O resources among multiple users, some of whom 
may want the same thing as each other.  All of this takes processing 
erhead.
 CH> I think what you and mike are trying to relate to is what
 CH> you have read about  IDE vs SCSI performance on a local
 CH> desktop system an then try to apply that to a dedicated
 CH> Novell file/print server (the case of the original question
 CH> in this thread). Since the particular dedicated Novel
 CH> File/Print servers communication to the outside world is
 CH> through was through 10bt ethernet cable and not from a local
 CH> keyboard, video, or a network multiuser application as
 CH> something like Unix is typically used for, the whole crux of
 CH> a novell file/print servers performance is keeping the data
 CH> at the maximum rate that can be transmitted through a 10bt
 CH> cable. It doesn't matter if the CPU is at 80% utilization to
 CH> do that or at 10% utilization. All that matters is that to
 CH> keep the bandwidth saturated, that the demand on the CPU not
 CH> be over 100%. Doesn't matter if you have 1 user or 10000
 CH> users. If the bandwidth is saturated, that's the best you
 CH> are going to do. Period. Anymore CPU/Drive throughput
 CH> capacity than that needed to reach much more than 100%
 CH> bandwidth is unecessary. What you are and Mike are saying is
 CH> that to have 2-5 times or -more- the ability to saturate
 CH> 10bt bandwidth is not good enough if it is a busmastering
 CH> IDE drive, cause everyone knows that busmastering EIDE
 CH> drives, although they are as fast in througput are not
 CH> -quite- as good at busmastering as a top of the line PCI
 CH> SCSI controller. From your rules of thumb and postulation
 CH> about SCSI, You need to have 5-15 times that ability. That's
 CH> non-sensical and a theory that won't even work on paper, let
 CH> alone the real world (And it doesn't...not even close).
It might be worth pointing out that your assertions would imply:
   1. SMP is a scam.
   2. SCSI is a scam.
   3. High rotational speed (10000 rpm) is a scam.
   4. Scatter-gather is a scam.
   5. Cache is a scam.
 
-- Mike
--- 
---------------