[to Baden's Home Page]

IDE VERSUS SCSI

(Check out two other documents on speed and performance.)

Why purchase SCSI?


What interface technology to choose, SCSI or EIDE? This has been the topic of sometimes interesting, occasionally silly and ofttimes heated debate for years, and the subject of many a magazine article ranging from the excellent to the atrocious. On this page, I'll attempt to give an up to date, reasonably detailed technical overview without treating the matter as a religious issue or trying to force a definite choice down your throat.

Why should you choose SCSI over EIDE [1]? Before trying to answer this question, let me straightly state a simple fact. SCSI is technically superior in virtually all respects. EIDE is primarily a solution for those on a limited budget. If money is no consideration and you're using something more modern than DOS or Windows version 3, buy SCSI.

Unfortunately, for most of us budget is limited, and there's a real choice to be made between a SCSI based system on one hand, and an EIDE based one with more RAM, a slightly faster CPU or better screen, on the other. I'd like to supplement the simple fact above by a second one: EIDE may not be as technically inferior as you think. You need to weigh their merits against each other in your specific situation. So: why purchase SCSI?

A final remark. There's very little end user consciousness about important performance options in EIDE hardware and software, which of course doesn't tend to encourage rapid improvement. Command overlap across channels has already been mentioned. Another example: ATAPI devices (tape, CD-ROM) may or may not support advanced PIO modes, may or may not support DMA, and there are three different operating modes which can make a real difference in CPU usage (microprocessor DRQ, interrupt DRQ, accelerated DRQ). Almost no-one knows about them and it wouldn't really surprise me if you could find 8 speed CD-ROMs with uP DRQ and no DMA support so they can be sold $5 cheaper.

The half-hearted EIDE support offered by Win95 has already been remarked upon. Microsoft has caused a tiny uproar on the ATA mailing list by declining to commit to further development... not in favor of SCSI though: they want to focus their efforts on the next generation interface, which will be a fast serial one. We'll see.

In the mean time, the choice for most of us is still pretty much limited to either SCSI or EIDE. The choice may not be any easier now, but I hope this information was of some help in navigating these muddy waters. If you have anything to add, correct, or ask, I'd love to hear it.


[1] In this document, EIDE will generally refer to baseline EIDE (the combination of ATA-2, ATAPI, a translating BIOS and a secondary interface) and up; SCSI to everything from Fast-SCSI-2 to UW-SCSI, unless otherwise stated.
[2] The most (in)famous examples are the widely-used CMD640 and RZ1000 interface chips.
[3] Bruce Lane (kyrrin@concentric.net) alerted me to this. Unfortunately we have no further information which bridges are problematic.
[4] This is the hard limit of the int13 interface used by boot loaders and some operating systems to communicate with the BIOS. Extended int13 calls have been defined to break this 8GB barrier but not all BIOSes and adapters support them.
[5] Unless you make very little use of your ATAPI CD-ROM and tape, it is best to place such slow devices on a channel of their own, and connect the harddrive(s) to the other channel. At least until command overlap arrives. If you have a tertiary channel and two or more harddrives, consider connecting the ATAPI devices to this channel and spreading the harddrives over the first two.
[6] This is a deliberately provocative statement. One one hand, in ordinary situations only a few devices on the UW-SCSI bus will be active simultaneously so there's bandwidth to spare; on the other hand, (E)IDE devices can make less effective use of the bus; see Quantum's Ultra-ATA paper for a discussion.


©1996,97 by P.A.P. den Haan (pieterh@sci.kun.nl). This page last modified Feb 4, 1997.



[to page top]