Chris Holten wrote in a message to Mike Bilow:
 MB> Windows 95 is the reason why IDE hard drives are so popular and 
 MB> cheap: since you don't get any performance improvement by going 
 MB> from IDE to SCSI under Windows 95, most people don't do it.  
 MB> Worse, many of the published disk I/O benchmarks are based on 
 MB> Windows 95 hosted tests.
 CH> For crying out loud. Now I've seen Windows 95 blamed for
 CH> -everything-.
Well, it's probably deserved.
 CH> Since this is the Novell Conference, I won't even debate with 
 CH> you how wrong you are about a good busmastering ultrawide SCSI 
 CH> setup not improving Windows 95 setup over an IDE setup.
Actually, this is *not* the NOVELL conference. :-)
 CH> We are talking about Novell, whose primary use is a file/print 
 CH> server, -not- an applications server and certainly not a system 
 CH> for running desktop apps whilst peer-to-peer networking in the 
 CH> same manner as OS/2, 95, NT, or Linux. Novel's architecture and 
 CH> use is completely differenct than the multitasking/multitasking 
 CH> systems you are using as a example to justify a good 
 CH> bustmastering SCSI setup.
Novell's NetWare OS *is* a multitasking architecture.  The NetWare OS memory 
architecture is very different from the NT memory architecture, but it most 
certainly is multitasking.  Low-level components such as SCSI are similar.  
In addition, NetWare has evolved a great deal since the days when all it 
would do was file and print serving, and even that requires a lot of CPU 
overhead for cache management, security management, and directory services.  
As I asked earlier, why do you think NetWare 4 supports SMP?
 MB> No, the internal architecture of NetWare is 
 MB> substantially similar to that of OS/2, NT, and Linux.  
 CH> -Except- with 99% of them, you are not running Multiuser
 CH> apps nor are you running Desktops apps. As you should well
 CH> know, Novell is -not- really recognized as much of a
 CH> multiuser operating system nor is it used much  in
 CH> that environment. 99% of Novell's application is as a
 CH> file/printer server. Period. That makes it a completely
 CH> different application/architecture than the other OS's you
 CH> are trying to relate busmaster SCSI setups too.  
What you are saying has some grain of truth when speaking of the NetWare 10 
years ago, but not today.  NetWare, although it does not have virtual memory, 
and this was a conscious design decision for performance, is very much 
capable of application serving.  Don't forget that, on an NT machine, all 
sorts of processing goes to support plain waste by file server standards, 
such as a GUI that you are forced to run.
 CH> But hey, answer the crux of the question. If you can much
 CH> more than saturate a 10 base T bandwidth with and IDE
 CH> pentium system (which with modern cheap pentium 6.4gig
 CH> systems, you *easily* can) other than that's the way you've
 CH> always done it and philosophize (with some one elses money)
 CH> that you should -always- use SCSI with Novell what
 CH> speed/performance benfifit would you get from SCSI if the
 CH> IDE setup already, even under the most extreme useage can
 CH> keep the 10bt bandwidth saturated? Are you saying that if
 CH> you use SCSI then some how the effective bandwidth of 10bt
 CH> ethernet cable will be increased? 
No, of course I'm not saying this.  However, a lot of disk data does not end 
up on the network wire, and this is an important issue.  Disk mirroring will 
double the amount of disk data transferred, with no effect on the wire.  
Server-based backup, usually using tape drives, will not touch the wire.  
Internal processing overhead, including cache management, security 
management, and directory services, will never directly touch the wire.
Sure, I might be able to do simple tasks, such as file copying, and saturate 
a 10 Mbps Ethernet LAN for brief periods.  However, for ordinary operations, 
in a real-world environment, IDE is suitable only for a lightly loaded 
rver.
Most benchmarks which purport to measure disk speed actually measure nothing 
else, and this leads to useless or even deceptive results.  EIDE can, as you 
have pointed out, under some conditions result in FASTER raw disk transfer 
speed than SCSI, but with the side effect of fully occupying the server's 
attention and inducing an overall performance penalty.
 CH> Whether there are 10 or 1000 LAN users on a 10bt network, if
 CH> the server can much  more than saturate the bandwidth, how
 CH> can putting in a faster server help? The limit is the total
 CH> amount of data the cable can carry on a continous basis, not
 CH> how fast the data comes off the hard drive. 
It depends upon what the clients are doing.  If you are using your file 
server as the respository of shared data files for a low-end database system 
such as Borland/Corel Paradox or Microsoft Access, then you will be calling 
upon the server to open and close files, to set and reset locks, to keep 
access synchronized by numerous users, and so on.  None of this presumes 
departing from the traditional file server model by running database NLMs on 
the server, either, but just a lot of complicated file access.
 CH> Does your company sell the hardware for all these networks
 CH> you set up Mike? 
Let's try to keep this discussion to technical subjects.
 CH> But before you answer any of the above, are you trying to
 CH> say that a Pentium system with an IDE busmastering
 CH> controller setup as a dedicated Novell File/Printer server
 CH> can't keep a 10bt ethernet bandwidth saturated???? Cause if
 CH> you -really- believe that, then the rest of this thread is
 CH> irrelevant. 
Yes, I am saying that, in real-world situations where multiple users are 
accessing multiple files, it is extremely challenging for a file server to 
saturate the wire.  Certain types of operations, such as file copying, place 
less processing load on the server relative to the amount of data moved.  
Other types of operations, such as file open/close or lock set/reset, will 
place very substantial load on the server relative to the amount of data 
actually moved on the wire.
 
-- Mike
--- 
---------------