MB> 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-.
 MB> Well, it's probably deserved.
I suppose, but I have a feeling they could all still be running CPM or OS/2 
and then people would have to blame CP/M for the plethorea of IDE drives on 
the market today. We certainly wouldn't want to consider cost/performance 
factors at all would we?
 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.  
 MB> What you are saying has some grain of truth when 
 MB> speaking of the NetWare 10 years ago, but not today.  
 MB> NetWare, although it does not have virtual memory, and 
 MB> this was a conscious design decision for performance, 
 MB> is very much capable of application serving.  Don't 
 MB> forget that, on an NT machine, all sorts of processing 
A grain of truth?? . 
Novell might be capable of applications serving and no doubt Novell is 
pushing that as hard as they can (or they are going to become even more of a 
dodo bird than they are now), but that's not why most people are motivated to 
use Novell nor what most existing novell systems are being used for. 
Personally I don't give Novel much of a shot at anything more than just plain 
simple dedicated file/print serving. They just can't compete with the *nix, 
OS/2 or Windows NT because of thier rigid and archaic methodolgy. That's why 
Novel's market share has been falling like a rock for the past 3-4 years. No 
doubt it is the best dedicated file/print sever NOS on the market and has 
been that for more than a decade now but that's about all it is -really- good 
for. Novell has -nothing- on the horizon that would indicate they have even a 
remote chance of changing that either.
 MB> goes to support plain waste by file server standards, 
 MB> such as a GUI that you are forced to run.
Sure, but even Unix, Windows NT and OS/2 with a GUI can easily saturate a 
10BT ethernet setup. Matter of fact they can saturate a much wider bandwidth 
than that with most modern equipment, so who cares? We are not using 286, 386 
or even many 486's for file/print servers anymore and memory is cheep cheep 
cheep.
 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? 
 MB> No, of course I'm not saying this.  However, a lot of disk data does not 
 MB> end up on the network wire, and this is an important 
 MB> issue.  Disk mirroring will double the amount of disk 
 MB> data transferred, with no effect on the wire.  Server-
 MB> based backup, usually using tape drives, will not touch 
 MB> the wire.  Internal processing overhead, including 
 MB> cache management, security management, and directory 
 MB> services, will never directly touch the wire.
But the guy that wanted to know about using a 6.4 gig EIDE drive on his novel 
server, as most novell server setups, wasn't doing any of this. As far as 
backups, anyone with any savvy at all will schedule them to go off at a time 
that the file/print server is not being utilized (IE 3am).
 MB> Sure, I might be able to do simple tasks, such as file 
 MB> copying, and saturate a 10 Mbps Ethernet LAN for brief 
 MB> periods.  However, for ordinary operations, in a real-
 MB> world environment, IDE is suitable only for a lightly 
 MB> loaded server.
With 10bt cabeling no matter what you do with a dedicated file/print server, 
you can only lightly load it. That's the whole point I'm trying to make to 
you.
 CH> Does your company sell the hardware for all these networks
 CH> you set up Mike? 
 MB> Let's try to keep this discussion to technical subjects.
Perhaps a study of the motivation of why some one proposes the more expensive 
solution 100% of the time with no thought or design consideration about 
individual systems and needs  does merit a bit of technical discussion. 
 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. 
 MB> Yes, I am saying that, in real-world situations where multiple users are 
 MB> accessing multiple files, it is extremely challenging 
 MB> for a file server to saturate the wire.  Certain types 
 MB> of operations, such as file copying, place less 
 MB> processing load on the server relative to the amount of 
Ah, this is grossly exaggerated Mike. When was the last time you even 
benchmarked/used a file/print server using an IDE drive through a 10bt 
network?
 MB> data moved.  Other types of operations, such as file 
 MB> open/close or lock set/reset, will place very 
 MB> substantial load on the server relative to the amount 
 MB> of data actually moved on the wire.
As in how relative Mike? You have somwhere between 50 and 200 times the 
capability with a Pentium system to keep the 10bt line saturated. Are you 
saying that these operations result in a sustained load that is 10 to 50times 
greater than the 10bt bandwidth, cause it would seem to me like common sense 
would indicate that just is not even remotely possible, unless you are 
running on a greatly underpowered 386 or slow 486 file server with not much 
memory.
--- Maximus/NT 3.01b1
---------------