Chris Holten wrote in a message to Mike Bilow:
 MB> The problems of IDE have nothing to do with the 
 MB> particular operating system, and the same disadvantages 
 MB> of IDE are experienced with NT, OS/2, or any other 
 MB> truly multitasking operating system.  You do not see 
 MB> the IDE penalty with Windows 95 because it cannot 
 MB> multiplex I/O even if the hardware supports it.
 CH> What's windows 95 have to do with it mike?
Windows 95 is the reason why IDE hard drives are so popular and cheap: since 
you don't get any performance improvement by going from IDE to SCSI under 
Windows 95, most people don't do it.  Worse, many of the published disk I/O 
benchmarks are based on Windows 95 hosted tests.
 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.
No, the internal architecture of NetWare is substantially similar to that of 
OS/2, NT, and Linux.  Where NetWare gains most of its speed relative to these 
systems is by foregoing virtual memory, so the disk cache is a huge chunk of 
physical memory.
The inherent advantage of SCSI is two-fold.  First, significant processing is 
offloaded from the main CPU onto an intelligent controller, freeing up the 
main CPU for other work.  Second, multiple devices connected to the same SCSI 
bus can usually disconnect while processing and share the bus efficiently.
 CH> No doubt on most any network, 95, like any multitasking or 
 CH> multiuser system performance could be significantly sped up 
 CH> with a good busmaster SCSI controller because of reducing CPU 
 CH> load.
The point is that it makes no difference under Windows 95.  You can free up 
the main CPU, but it still can't do anything with its free time.
 CH> No doubt IDE can use a significant amount of CPU resources
 CH> as compared to a SCSI, which is why I run SCSI on high
 CH> performance desktop or multituser systems. That's obvious.
 CH> What obviously isn't to some folks is that if your system
 CH> has enough CPU strength / drive throughput to much more than
 CH> saturate a 10 base T ethernet band width, than that extra
 CH> money you spent on a more expensive SCSI setup was not
 CH> necessary. Don't confuse what's required for a multiuser
 CH> system with Novell, because Novell as a file/print server is
 CH> not a multiuser application. 
I completely disagree.  A NetWare server is doing a lot of processing, even 
for file and print services.  If nothing else, its cache management takes a 
considerable amount of CPU processing.  If you have less CPU processing 
headroom, you will get less effective cache management.  Even something as 
simple as a server-based tape backup can benefit enormously.  A big 
performance hit is NDS on NW 4, and it is critical to do this quickly.
In addition, many NetWare servers do function as applications servers.  Many 
run mail, databases, or even web servers on NetWare these days.
 CH> The same engineering principles apply to Novell, but as far
 CH> as novell and the discussions I'm following in this
 CH> conference about Novell and SCSI vs IDE, they are grossly
 CH> exaggerated and the benifits of using a SCSI on a novell
 CH> 10bt file/print server, as compared to modern IDE system are
 CH> nil. Use a bit of logic. Why are you concerned with a system
 CH> whose sole purpose in life is file/print server have more or
 CH> less CPU useage with IDE than SCSI? You are not running
 CH> multiuser or desktop apps with it, so aAll the system has to
 CH> be able to do is staturate bandwith, which with 10bt
 CH> ethernet, any Pentium or better, IDE, SCSI, whatever system
 CH> can do standing on it's head. What you are saying is that
 CH> one must spend more money so that the CPU is 20-50% utilized
 CH> during peak useage instead of 30-80% utilized. As long as
 CH> the system can keep the bandwidth saturated (which modern
 CH> busmastering IDE/Pentium or better system *easily* can) you
 CH> are wasting money on SCSI on a dedicated file/print server.
 CH> You may evaluate a 100bt setup and decide that there is some
 CH> benifit to SCSI, but that is not the network the original
 CH> thread to this message was concerned when the blind "always
 CH> use SCSI" recommendations were made ("Nobody ever got fired
 CH> for using IBM" either). Each installation should be
 CH> evaluated and designed for optimum performance/economics.
 CH> Blindly stuffing a SCSI controller in every Novell/File
 CH> print server because of an attitude/rule of thumb Novell and
 CH> it's deciples started promulgating 10 years ago may not be
 CH> best for the people who hire some one to design a network
 CH> for them or a person that already owns a 6.4gig busmaster
 CH> IDE drive.
Ultimately, I would concede that this is a matter of opinion, but my opinion 
is that you are dead wrong.  Why do you think Novell offers SMP support out 
of the box in NW 4?  You probably don't have much experience dealing with 
very large networks, where hundreds or even thousands of users will be 
competing for a bank of server resources.  Given the couple of hundred 
dollars extra that SCSI will cost you over IDE, it is utterly foolish not to 
buy SCSI.
 CH> No doubt on 386 systems and slow 486 systems that didn't
 CH> have enough memory, SCSI Busmastering improved performance
 CH> on a 10BT network, but you are really over engineering and
 CH> underdesigning if you think that you should only use SCSI on
 CH> a novell 10bt network. "Spending someone elses money"..if
 CH> you will.  
I feel that it is a mistake in all cases to buy minimum capacity.  If you 
decide to run mail or database serving or even NDS on your server, then you 
don't want to have to rip the drives out to get acceptable performance.  If 
there is one absolute rule I have learned through many years experience, it 
is that overbuying capacity initially will always be enormously cheaper than 
adding capacity later, and you will always need more capacity later.
 CH> Also, with newer more modern IDE drives and modern
 CH> busmastering IDE chipsets (Intel HX/VX/TX for instance) than
 CH> the ones you tested years ago when you came to the
 CH> conclusion that running two IDE drives on the same channel
 CH> would greatly slow down the system has not been an issue for
 CH> at least a couple of years now (Starting Intel Triton II
 CH> chipset and most major brand mode 4 1.2 gig or better IDE
 CH> drives mfg'd in the past three years).  The guy with the 6.4
 CH> gig drive can use 3 more just like the first one, for 24meg
 CH> total with no slowdown in performance with one as compared
 CH> hanging 3 or 4 of them in his Novell system. 24 meg oughta
 CH> hold for a while .
The newer chipsets and IDE protocols can speed up raw transfer rates, but do 
nothing to improve device changeover time.  There is still the same inherent 
penalty when changing which device on an IDE channel is active.  There is no 
provision for SCSI-style disconnection, for example.
 CH> Heck I'd put the fast SCSI setups on the Workstation that
 CH> need the extra speed Mike. I sure wouldn't waste them on an
 CH> archaic old Novell Server file print server .
We don't have any "archaic old Novell Server" machines.
 
-- Mike
--- 
---------------