Origins of IDE
Besides SCSI, the other widespread controller storage standard for PCs is IDE. The original 1985
IDE specification (its formal name is AT-Attachment-- ATA--because of its compatibility with the AT
bus used in IBM PC/AT-compatible computers) defined a 40-pin interface that ran on the ISA bus and
offered a maximum throughput of 8.3MBps (although real-life average throughputs usually hovered
around 2MBps to 3MBps). IDE also defined several modes of operation, including three PIO modes (0,
1, and 2), and one DMA mode of operation (DMA Mode 0). Compaq and Western Digital spearheaded the
specification, which offered several major benefits to PC hardware vendors. Cost savings and
simplicity, rather than performance, inspired the development of the IDE/ATA interface. By
integrating drive controller electronics on the drive rather than on an expensive controller card,
IDE let manufacturers produce cheaper drives that offered decent performance. This cost
effectiveness still holds true today: IDE drives typically cost 25 percent to 40 percent less than
SCSI drives of similar capacities.
In addition to cost-saving features, IDE offered features that simplified configuring hard
drives. You could set up IDE drives in a master/slave relationship without concern for electrical
termination. However, different vendor implementations of the original IDE/ATA specification caused
drive incompatibility problems: Drives from one manufacturer sometimes failed to work with those
from another. As with SCSI, however, the ease of IDE/ATA device interoperability has improved as the
specification has evolved and matured.
EIDE and Beyond
With the advent of Windows 3.x in the early 1990s, the demand for faster PC performance grew to
new levels, and IDE began to show its age. In 1993, Western Digital offered the Enhanced IDE (EIDE)
specification, which permitted faster, higher capacity drives. EIDE supported the use of IDE on a
local bus (e.g., a VL-Bus) in addition to the slower ISA bus. EIDE offered a variety of new features
that removed the four primary limitations of the original IDE specification: EIDE supported drives
exceeding 528MB capacity; significantly faster data transfer rates (up to 13.3MBps for DMA Mode 1
operation); an additional channel for up to four IDE devices; and a new interface specification, AT
Application Programming Interface (ATAPI), for connecting non-disk drive peripherals such as CD-ROMs
and tape drives. Ironically, the ATAPI specification is essentially a simplified SCSI command set;
it owes much to SCSI's design for device communications.
Since EIDE's introduction in 1993, standards organizations, such as ANSI and the Small Form
Factor (SFF) Committee, and drive vendors have extended and improved the IDE/ATA specification. The
second version of IDE, dubbed ATA-2, encompasses several proprietary vendor implementations,
including EIDE and two specifications (Fast ATA and Fast ATA-s) promoted by Seagate Software and
Quantum. The ATA-2 specification also defined two new PIO modes, PIO Mode 3 (at 11.1MBps) and PIO
Mode 4 (at 16.6MBps). ATA-2 introduced two new DMA-based modes, DMA Mode 1 (at 13.3MBps) and DMA
Mode 2 (at 16.6MBps).
The latest ATA-3 specification defines still faster data transfer modes, including PIO Mode 5
(at 22.2MBps) and DMA Mode 3 (at 33.3MBps). Quantum's implementation of ATA-3, Ultra ATA, appears to
be the early favorite at press time--a large number of hardware vendors are supporting it. Together,
these new specifications have extended IDE's life span and keep it a viable desktop technology for
use with most modern operating systems.
IDE and NT: Oil and Water?
Unfortunately, even with all these new specifications, IDE/ATA still suffers from some inherent
design limitations that make it less than appealing for use with NT. For example, IDE is highly
CPU-intensive compared with SCSI, burning precious CPU cycles to perform its work. With IDE PIO
modes, the host system's CPU carries out all the I/O operations for IDE devices, which can drain CPU
resources and decrease system performance.
ATA-2 interfaces also suffer from a problem known as slipped revolutions, whichprevents
the interfaces from keeping pace with fast ATA-based drives. (For an explanation of this problem,
see the sidebar, "A Little IDE Math," page 170.) The new ATA-3 and Ultra ATA
specifications eliminate this problem by doubling the interface burst transfer rate to 33.3MBps.
(Table 2, page 167, summarizes the data transfer modes and the relative transfer rates defined by
various implementations of the ATA interface.) An ATA-3 or Ultra ATA interface can keep up with even
the fastest ATA-based drives and optimize the performance of the IDE subsystem. However, the new
ATA-3 and Ultra ATA specifications do not solve IDE's CPU utilization problem. Despite enhanced ATA
features such as DMA Mode 2, Bus Mastering DMA, larger block sizes, and 32-bit addressing, the host
CPU still must perform a significant number of I/O operations compared with SCSI.
As I mentioned previously, NT's asynchronous I/O model works most efficiently with a SCSI
subsystem because SCSI can handle multiple I/O requests simultaneously. IDE/ATA systems can handle
only one I/O operation at a time, which limits their performance under NT. The drive controller
talks to only one drive on a channel at a time; any other drive that needs I/O servicing at the same
time must wait its turn until the first drive has finished. This aspect of IDE/ATA drives is the
reason why you should never consider using them on NT servers, which must handle heavy loads of file
I/O requests.
These types of problems aren't nearly as prevalent under operating systems such as DOS and
Windows 3.x, which employ serialized I/O models. Even Windows 95 lacks a fully asynchronous I/O
model and maintains a significant degree of serialization in its low-level drivers. You frequently
see head-to-head comparisons of Fast ATA-2 and SCSI-2 or Ultra SCSI drives yielding similar
performance results under these operating systems. In these situations, choosing an IDE/ATA drive
probably won't cause any significant performance loss. You can make a similar claim about
single-tasking environments in which a user typically runs only one application at a time; SCSI's
performance benefits don't really take off until two or more SCSI device- related tasks run
simultaneously. At that point, the multitasking features of SCSI generate a significant performance
advantage over ATA-based systems.
Here's another interesting note about native IDE/ATA support under NT: Currently, NT's highest
supported ATA PIO mode is PIO Mode 2, which defines an 8.3MBps burst data transfer rate. Even if you
use a Fast ATA-2 subsystem capable of 16.6MBps with a PIO Mode 4 drive, under NT you realize a
maximum potential throughput of only 8.3MBps.
Keep in mind that the IDE/ATA specification relies on the system's BIOS, and IDE/ATA features
such as ATAPI support and disk capacities that exceed 528MB require three-way support by the system
BIOS, the peripherals, and the operating system. Although software BIOS enhancements extend BIOS
features and allow (for example) hard disk partitions greater than 528MB on older systems, many of
these utilities are not compatible with NT. Fortunately, almost all modern PCs include Logical Block
Addressing (LBA) support for IDE drives. LBA uses a logical addressing scheme similar to what SCSI
uses to break the 528MB barrier.
More Bad News
A final thought for the would-be IDE drive purchaser: IDE has other built-in limitations besides
the ones I've already mentioned. IDE/ATA specifications define a significantly shorter maximum cable
length than SCSI implementations. Whereas most SCSI implementations (differential SCSI excepted)
provide for cable lengths of approximately 3 meters (about 10 feet), the maximum length for cables
on IDE/ATA subsystems is 45 centimeters (slightly less than 18 inches). To make matters worse, use
of drives supporting the fastest PIO or DMA modes cut this distance in half--to just under 9 inches.
With such cabling limitations, you can easily understand why no specifications exist for connecting
external IDE/ATA devices: There wouldn't be enough cable to connect them to the host system.
Remember to make provisions for devices' internal electronics when you calculate cable distance;
these invisible lengths count as part of the total bus length. In some cases, this distance can be
as high as 6 inches or more (you typically can budget about 3 inches to 5 inches per device).
Another gotcha with modern IDE is the difference between the primary and secondary IDE
controllers on most motherboards. As you probably know, all modern implementations of the ATA
interface include two separate IDE channels (usually built onto the motherboard), each of which can
handle two devices. What you might not know, however, is that sometimes these two channels differ
significantly. Many older Pentium motherboards place the primary IDE channel (which typically uses
IRQ14) on the PCI bus (which can operate at rates up to 33MHz), but place the secondary channel
(which typically uses IRQ15) on the slower ISA bus. This arrangement limits the maximum data
transfer rate of this channel to ISA's 8MHz transfer rate. If you configure an IDE drive subsystem
on these older systems, you need to avoid putting fast PIO Mode 4 drives on the slower channel
whenever possible.
You can expect significant performance penalties when you mix different kinds of IDE devices on
the same IDE channel. IDE slows down when you combine fast and slow IDE/ATA devices on the same
channel. For example, combining a fast ATA-2 PIO Mode 4 hard disk on the same channel with a slower
PIO Mode 2 IDE CD-ROM drive effectively cripples the performance of the hard disk by forcing it to
continually wait for I/O operations when the CD-ROM is active. Under these circumstances, the fleet
effect takes place: The fleet goes only as fast as the slowest ship. In these circumstances, a
better solution is to place your slower IDE peripherals (such as CD-ROMs and tape drives) on IDE's
slower second channel, keeping them off the channel that contains your fast hard disks. However, if
you use more than two IDE hard disks on your system, you won't have a choice; you will be forced
into the fleet effect situation. With SCSI, these issues are non-existent.
As if these issues aren't bad enough, you can find a significant number of IDE/ATA controllers
that use only a single command queue shared between the primary and secondary IDE channels. This
situation can result in major performance delays when devices on both channels try to talk to the
system simultaneously. The problem is further aggravated when the two channels are fully populated
with IDE devices.
The Best Choice
Because of its extensive array of performance-related features and its leveraging of NT's
asynchronous I/O model, SCSI is clearly your best choice for disk subsystems on NT
computers--especially disk-bound computers such as file servers and systems you use for application
development. However, if finances or other factors require you to deploy IDE subsystems in your NT
systems, be sure to limit such use to basic user workstations and other light-duty machines in which
the effects of increased CPU utilization and serialized drive access won't hurt as badly. If money
isn't a problem, I recommend you use SCSI whenever and wherever possible on your NT systems. By
doing so, you'll reap the rewards of a highly sophisticated and versatile interface, and maximize
the performance of NT.
Additional information that supplements this article is available at the Windows NT Magazine
Web site: http://www.winntmag.com.