Computer Services

Tel 650.548.1010
Burlingame, CA USA


IDE vs SCSI and Windows 2000

Revised on

If you use a computer and you're a nut like me always hunting for the fastest and the best system then you've most likely had to decide whether to go with a hard drive system based on the more common IDE interface or the tried and true (expensive) SCSI line. Windows users on both side have battled it out over the years like the Hatfields and Mckoys.

There's a similar either/or feud among Windows 2000 people. The one I'll be discussing today is the hoary question of IDE vs. SCSI in Win2K. The simple verdict is: Go SCSI if you can afford it, but today's IDE is cheap and fast, provided you tune Win2K to take advantage of it.

In the bad old days, SCSI drives and controllers were far more reliable, more high-end, and more well, professional than IDE. Not to mention bigger -- always a good thing for a server -- but also much more expensive. Unfortunately, if you wanted to run a server, there really weren't any other choices around; at least none that you would probably be willing to stake your information on. As a result, support for IDE drives in Windows NT (3.5 and 3.51, mostly) was written in such a way that it was treated like a variety of SCSI controller.

In fact, to this day, the BOOT.INI files in Win2K use an addressing scheme to locate the system files that owes more to the
controller/device ID enumeration system of SCSI than anything else. Consequently, support for SCSI in NT and Win2K has always been a little more robust than support for the various flavors and implementations of the IDE/ATA spec.

None of this is to say that NT/2K hasn't bothered to support IDE/ATA -- just that support for it out-of-the-box, at least, has been markedly different. For instance, each make and model of SCSI controller gets a devoted driver, while just about all IDE/ATA
controllers are managed with the generic ATAPI.SYS driver. Part of this is out of necessity, because almost no two SCSI controllers work the same way, while the IDE/ATA spec is supposed to be an industry-wide hardware standard. The reality is very different.

In some cases, as with the Promise family of ATA controllers (both the most famous and infamous variety of such controller), there's a manufacturer-provided driver that needs to be loaded when you first install Win2K. Unfortunately, people often assume that ATA controllers are going to be universally interchangeable, and let the generic ATAPI.SYS driver run the shooting match. Not such a good idea.

Another major reason IDE/ATA often gets shunned on higher-end machines, servers included, is because of the CPU cost for data throughput. The way IDE/ATA controllers function is by using a small percentage of the computer's CPU power to move the data through the PC's bus. SCSI controllers do all of the data movements themselves, leaving the CPU free to do other things. The last thing you want your server doing is wasting CPU power just slavishly moving data around. You want it to be crunching numbers and serving Web pages.

The earlier versions of the IDE/ATA spec used a method known as programmed I/O to move the data, and there were four implementations, or "modes," of programmed I/O, each faster than the last: PIO 1, PIO2, and so on. Eventually, the IDE/ATA spec was rewritten to include a new type of data transfer system, Ultra DMA (Direct Memory Access). UDMA, as the name implies, works by having the disk controller open windows directly into the system's memory and moving data into and out of them on its own. The amount of CPU time involved is a fraction of what was needed for PIO, even with high-speed high-volume transfers.

Today, IDE drive rock with speeds hitting highs of ATA100 or 100MB per sec rivaling the SCSI camp for almost a third of the cost. Last month (5-1-2001) I picked up a IDE IBM Deskstar 30GB ATA100 for 89$ at my local electronics store.

A note about 66 vs. 100: From what I've found, there's little practical difference between ATA/66 and ATA/100 performance, except when you're dealing with multi-drive scenarios.

Now we get to the practical applications. In my own work with various machines, I have found that with the proper care and planning, an ATA/66 or ATA/100-equipped server can substitute reasonably well for a SCSI-equipped server, especially if you're on a tight budget. Exceptions do of course exist: If you need hot-pluggable drives or other SCSI-only features, then go SCSI, by all means.

The key words to the above are "with the proper care," since many people don't know how to get the most out of IDE/ATA on Windows 2000. For one thing, UDMA is neither enabled nor optimized by default in Win2K -- meaning that if you put a UDMA-enabled device in Win2K, you won't be getting the most out of it unless you explicitly tell Win2K to do so.

The first thing to do is find out exactly what flavor of UDMA, if any, you have in your PC. The best way to do this is to get your
manufacturer's specs and read them over. Most PCs shipped within the last year or so are ATA/66 or ATA/100; most shipped the year before that are ATA/66 or ATA/33.

Next step is to see whether or not UDMA is enabled for the controller in question. To do this, right-click on My Computer in Win2K and select Properties; then choose Hardware and click on Device Manager. Expand the "IDE ATA/ATAPI controllers" reference in the device tree, and right-click on the Primary IDE Channel. Get Properties. Under Advanced Settings you'll see two listings for each device on this IDE chain, each with a setting labeled "Transfer Mode." Set both to "DMA if available," hit OK, and then modify the properties of the second IDE channel the same way. When you're done, reboot.

That's the first step. Once you have that in, you'll need to manually enable ATA/66 speed -- provided your system supports it -- through a Registry hack. (In other words, don't do this unless you're sure you have ATA/66 support or better.)

Navigate to this Registry key:


There should be a DWORD key under \0000 named EnableUDMA66. If there isn't, create it and set it to 1. Reboot.

If you want to, you can simply copy the following into a .REG file and double-click it to add it:

Windows Registry Editor Version 5.00


Not initially enabling UDMA/66 support in Win2K appears to be a preventative measure to avoid data corruption, but it also has the downside of being irritatingly slow. To enable ATA/100 support, do all of the above, and also make sure you have Service Pack 1 installed. The SP1 version of ATAPI.SYS fixes problems people had with ATA/100 controllers.

If you're installing Win2K clean on a system with an ATA/66 or ATA/100 controller, the odds are that Win2K's built-in driver set
won't be able to work correctly -- or will drop back to ATA/33 compatibility mode at best. The safest thing to do in such a case is to use the manufacturer- provided driver. However, another sneaky trick can be used if you either don't have the driver or can't get Win2K to take it during setup.

Part of the way the controller is able to identify what type of drive is plugged into it is via the signal cable. ATA/66 and ATA/100 cables have more grounding wires to dissipate noise, and are usually marked with blue connectors, blue cables, or both. Conventional IDE/ATA cables are black and gray. You can force the system to boot as plain old ATA by simply swapping the old variety of cable, or by disabling ATA/66 support on the controller if it has its own BIOS setup routine. Once you get Win2K running, you can substitute in the new (correct) driver, change the registry settings, change the BIOS and cables, and reboot. Naturally, one should never mix and match ATA/33, ATA/66 and ATA/100 devices on the same chain.