One of the most important decisions you must make when you configure a Windows NT system is which mass storage subsystem to use. Even if you've spent only a short time in the NT universe, you've likely heard time and time again that Small Computer System Interface (SCSI) is the best choice for NT computers. However, enhanced versions of the Integrated Drive Electronics (IDE) specification such as EIDE/ATA-2, ATA-3, and Ultra ATA tout new and improved features that claim to give SCSI a run for its money. In addition, you can purchase these newer, faster IDE-based drives for significantly less money than comparable SCSI drives. Meanwhile at the high end, countless new SCSI specifications have arrived on the scene, promising better performance and features than previous incarnations of SCSI. To help you separate facts from marketing hype, let's explore the various flavors of both technologies and compare their features and shortcomings.
NT and SCSI: A Marriage Made in Redmond
Since the inception of NT, Microsoft has strongly urged system designers and end users to choose
SCSI for their NT systems to maximize performance. This recommendation appears throughout the NT
documentation and white papers, as well as in computer industry publications. Perhaps the best place
to start comparing SCSI and IDE is to examine the reasons behind this recommendation and find out
why people feel so strongly about using SCSI with NT.
Origins of SCSI
The SCSI interface, which debuted in the early 1980s, was designed to be a universal,
multipurpose I/O bus for personal computers. As you might remember, older PC hardware arrangements
used a separate controller for almost every kind of device, so a system might have a number of
different controller cards: one for the hard disk, one for a tape drive, one for a scanner, and so
forth. These other technologies typically defined specifications involving one or more dumb
peripherals attached to a controller to handle all the I/O operations. SCSI, in contrast, introduced
a specification that called for intelligent controllers and peripherals, and let one controller card
control up to seven daisy-chained devices.
The first implementation of SCSI, dubbed SCSI-1, was an unofficial, de facto adoption of SCSI by various vendors in the mid-1980s. SCSI-1 offered an 8-bit wide data path and a 5MHz bus clock rate, yielding asynchronous transfer rates of up to 1.5MBps and synchronous transfer rates of up to 5MBps. (Asynchronous transmission requires a handshake, or signal, between the sending and receiving computers for each byte transferred; synchronous transmission transfers a series of bytes before handshaking occurs, which increases the data transfer rate.) Among SCSI-1's benefits was the ability to process multiple, overlapped commands simultaneously. SCSI-1 drives could overlap I/O operations with other SCSI-1 drives in the system, processing data in a concurrent, parallel (rather than serial) fashion. Unfortunately, numerous incompatibility problems plagued SCSI-1 products because vendor implementations of the specification differed significantly.
SCSI and More SCSI
As a result of SCSI-1's incompatibility problems, the ANSI-approved SCSI-2 standard emerged to
provide a unified SCSI implementation and assure interoperability between SCSI hardware from
different vendors. This new flavor of SCSI offered a faster 10MHz bus clock yielding a maximum
synchronous data transfer rate of 10MBps. Devices complying with the faster transfer rate were
labeled Fast SCSI-2. The specification included a 16-bit wide version of SCSI (dubbed Fast/Wide
SCSI-2) that doubled bus throughput to 20MBps and increased the maximum number of devices on the
SCSI bus from 7 to 15. Other enhancements included features such as parity checking and an improved
connector specification.
The continued popularity and success of the SCSI-2 standard begat the SCSI-3 standard, which includes several related SCSI specifications, including the parallel Ultra SCSI standard (8-bit data path at a 20MBps transfer rate) and the Ultra Wide SCSI standard (16-bit data path at a 40MBps transfer rate). Luckily, the Ultra SCSI and Ultra Wide SCSI implementations use the same connector types as SCSI-2 (Fast and Fast/Wide) and are fully backward-compatible with SCSI-2 controllers. Table 1 summarizes the data path widths, data transfer rates, and recommended cable lengths for the various SCSI implementations.
Power, SCSI-Style
Without a doubt, the most important feature of SCSI is its ability to perform overlapped,
multitasked I/O. NT's asynchronous I/O model, which lets NT conduct multiple I/O operations
concurrently with multiple devices, enhances SCSI's multitasking capabilities.
SCSI also provides a relatively low CPU utilization compared with other disk controller standards, such as IDE. Most IDE disk subsystems use a Programmed I/O (PIO) method of data transfer that requires the system CPU to handle all I/O on behalf of the drive interface. In contrast, SCSI uses Bus Mastering direct memory access (DMA) to transfer data to system memory. Bus Mastering DMA uses DMA controller logic built onto the SCSI host adapter (rather than the system DMA controller) to control the bus and transfer data directly to system memory, bypassing the system CPU entirely. For more information about the different data transfer methods that disk controllers use, see the sidebar, "Data Transfer Methods."
SCSI also includes features that help improve performance. For example, to improve the efficiency of bus utilization, SCSI provides features such as tagged command queuing (which lets the SCSI host adapter handle queued commands in the most efficient order, rather than in the order the host adapter receives them), scatter/gather (which provides multiple host addresses for data transfer in one command packet), and disconnect/reconnect (which lets SCSI devices disconnect from the bus when they aren't using it and reconnect when they need to transfer data).
SCSI Pitfalls
As the old saying goes, every rose has its thorn. Although SCSI-2 and SCSI-3 are
high-performance, robust standards, implementing them can be difficult. In addition to cable
termination and SCSI ID problems, mixing slow and fast devices on a bus can cause timeout and reset
errors. With reasonable planning, you can easily avoid these problems. (For more information about
SCSI termination, see the sidebar, "SCSI Termination," on the Windows NT Magazine
Web site--http://www.winntmag.com. For tips about troubleshooting SCSI problems, see Bob
Chronister's Tricks & Traps columns, or post your questions on the Windows NT Magazine
forums--http://www.winntmag.com/forums.)
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.