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.
- 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
harddrives, 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
shared equally by SCSI and EIDE [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.
and performance