Home > Data Storage Media > Hard Disk Drive > SCSI Drive > EIDE vs SCSI - Why purchase SCSI

 SCSI Disk
EIDE vs SCSI - Why purchase SCSI by P.A.P. Den Haan
Why use SCSI by Michael Neuffer
How to install SCSI Hard Drive by Rad
Determining Single-Ended SCSI or Differential (HVD) SCSI Interface by Paralan Corporation
SCSI - A game with many rules and no rulebook by Gary Field
SCSI Interface by David Risley
The Ten Commandments of SCSI by Gary Field
The Complete Guide to SCSI for the Powerbook by Charled Moore


EIDE Versus SCSI - Why purchase SCSI?

The article published below is part of a complete article from Peter Den Haan


What interface technology to choose, SCSI or EIDE? This has been the topic of sometimes interesting, occasionally silly and often 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?


Supports more devices, high end devices, and a wider range of devices
A single SCSI channel supports up to seven devices. Two channels, for a total of fourteen devices, are becoming more and more common. On the EIDE side of things, four channels are defined, giving eight devices. However, common hard- and software supports only two channels so beyond four devices things become stickier.


Real high end devices are available in SCSI guise only. Fairly common examples are extremely large or fast (7200rpm) harddisks and DAT tape drives. For that reason alone, if you need the utmost in capacity or performance, SCSI is your only choice.


SCSI supports many different types of devices. With the ATAPI protocol EIDE can support a fairly wide range as well, but in practice only hard drives, CD-ROMs and tapes are really common. Magneto-optical devices etc. are possible and may eventually materialize. Scanners and so forth won't arrive in EIDE versions anytime soon, since it does not support external connections.


Summarizing you could say that EIDE meets the needs of the majority, but not all, of the users.


More reliable
EIDE has the problem that it targets, among other things, the low end market. Some vendors and manufacturers tend to save a dollar too much. This has resulted in badly designed and downright buggy interfaces and chips [2]. The worst excesses appear to be behind us, I'm happy to add.


EIDE PIO mode 4 has proven relatively unreliable for a number of reasons. These problems have been addressed by the ATA-3 spec, and the even faster modes of Ultra-ATA ensure data integrity using CRC checksums. It will take time for all this to filter through to the marketplace though. In the mean time, mode 4 may or may not work reliably in your brand new setup. Thank God mode 5 has remained vaporware.


SCSI has no such reliability problems as long as your cables are decent and everything is properly terminated. One warning: if you want to retain your busmastering ISA bus adapter when upgrading to a modern PCI system, be careful; this can result in data corruption, depending on the PCI to ISA bridge used on the mainboard [3].


Translation, the scheme used to access disks of more than 504MB through the BIOS, has stabilized by now. It's still not ideal (you cannot switch between LBA and LARGE translation in some setups). Then again, the mapping used by different SCSI interfaces isn't always identical either. More worrying are the common BIOS bugs showing up at 2GB and 4GB capacity points. These are bugs, not EIDE limits per se, but that knowledge doesn't help you much if there's no updated flash BIOS available for your mainboard. The maturity of SCSI is a definite advantage here.


Finally, there is an 8GB barrier looming on the horizon, but that one is a PC-specific BIOS limitation affecting SCSI and EIDE equally [4].


Even today, SCSI is probably a safer choice; but whatever you choose, you're better off not buying the cheapest hardware available.


Busmastering support is better
Even though modern EIDE interfaces (for example the PIIX used with the Intel Triton and Natoma chipsets) can handle busmastering, this is a relatively recent development. Support for SCSI has matured for years. This shows in superior features (scatter/gather), quality (drivers) and ease of use with SCSI compared to inconsistent EIDE support.


To give an example of the latter, attempts to use busmastering with an ATAPI (IDE) CD-ROM still all too often fail; let's not even mention other ATAPI devices such as tapes. Even if the busmastering driver works correctly, it may still use old fashioned PIO for the CD-ROM device, because many of these simply don't support DMA, or the interface has funny restrictions with respect to ATAPI equipment.


This situation will improve in time, not least due to standardization efforts on the hardware level. Once busmastering works, it drives the CPU usage of EIDE devices to low enough levels that it's not much of a consideration for single user systems.


Busmastering is important in multitasking environments, since it greatly reduces the number of CPU cycles consumed by data transfers. Do not expect it to rise the transfer rates themselves. For single user machines, EIDE busmastering implementations do a decent job. Servers, on the other hand, exist to pump large amounts of data around; for these, you wouldn't consider anything but the best busmastering capable interfaces (ie. SCSI).


Access to multiple devices
With SCSI you can put all your devices to work simultaneously, provided you're using an operating system supporting this feature (DOS and Win3 do not). The devices will interfere slightly with each other due to the limited total bandwidth of the SCSI bus (10-40MB/s for today's hardware; actually, the command overhead may be more of a problem).


With EIDE, only one of the two devices on each channel (cable) can be active at a given time. Between different channels though there is no such restriction. Modern interfaces and operating systems like OS/2 or Linux allow access to as many devices as you've got channels -- usually two. This can be put to good use with some careful planning [5].


Exceptions to this rule are some badly designed interface chips which prevent this or even corrupt data if you try (CMD640!). Probably for that reason, this feature has some support in Win95 only for the PIIX (used on Intel Triton and Natoma based mainboards). In all other cases Win95 will access no more than one EIDE device at any given time, which really impacts performance if multiple tasks are performing I/O. This is especially bad with ATAPI tapes and CD-ROMs, since commands on these devices can take a pretty long time to complete.


EIDE will certainly incorporate some form of command overlap in the future but it's unlikely to be as powerful as SCSI.


Access to multiple devices is important in multitasking environments, and positively vital in multiuser and server type applications. SCSI is, and will remain, more flexible here. EIDE suffers doubly because of the loveless support offered by Win95.


SCSI has more streamlining options
The intelligence of the SCSI controller and protocol allows some nifty optimizations. One of the most important is tagged command queuing; a device can absorb a number of commands and execute them in a different order than they were issued.


The operating sytem will do the same to some extent: if you need to access a harddisk on, say, cylinder 0, 1000, and 500, it doesn't take many CPU cycles to figure out that you'd better swap the last two. But a device can always do a better job of it because it has complete information on its own internal structure and current state. Many devices aren't all that intelligent about it in practice, though. The effects are difficult to quantify but usually small.


This, too, is a feature that really comes into its own in multitasking situations.


SCSI is 40MB/s as opposed to 16MB/s for EIDE
Sorry, this is not as much of a consideration as you might think. The first thing to note is that no single device except a solid-state drive can achieve 16MB/s sustained throughput, let alone 40MB/s. The reason that SCSI bandwidth should be exceptionally high is that it needs to be shared by all devices on the bus. Multiple devices may very well generate a combined data flow of tens of megabytes per second. On the other hand, the 16MB/s bandwidth of the EIDE bus is shared by just two devices, making the per device bandwidth higher than even UW-SCSI [6].


Even so, the most recent development in EIDE is Ultra-ATA, which adds a 33MB/s DMA mode (DMA/33) to its repertoire. This is more of marketing than practical value at present.


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,98 by P.A.P. den Haan (pieterh@sci.kun.nl). This page last modified Jan 14, 1998.