|
IDE vs SCSI and Windows 2000
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:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Class\{4D36E96A-E325-11CE-BFC1-08002BE10318}\0000\
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
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class\{4D36E96A-E325-11CE-BFC1-08002BE10318}\0000]
"EnableUDMA66"=dword:00000001
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.
end
|
