World Magazine 2024
Microsoft® Windows 2000 Knowledge Center
Taking Control of UDMA in Windows 2000
If you have arrived here through a search engine, and do not have a menu to the left, click here!
The focus of this article is two-fold. First, some background on what has brought UDMA and Ultra-ATA into the forefront. Second, to dispel some of the myths of how to handle UDMA or Ultra-ATA issues in Windows 2000. It’s not merely a matter of checking a few boxes and hacking the registry!
Some Background
Deep in the inner-sanctum of the technology mindset, there is this simmering controversy of just which drive interface is better, SCSI (Small Computer System Interface), or UDMA/Ultra-ATA. Just when SCSI seems to be the clear winner for versatility, speed and reliability, IDE developers up the ante. This has always been a controversial issue for the Windows NT operating systems, especially in server and data center environments, and Windows 2000 is no exception. We can say, without reservation, that SCSI is the way to go if you need speed, reliability and the ability to mirror drives/volumes, presuming that you can afford it. Today’s IDE interfaces are cheap and fast, and Raid solutions are beginning to surface. However, to obtain optimal performance from these UDMA/Ultra-ATA solutions, you have to tune Windows 2000 to take advantage of them. Microsoft’s NT developers have been long been prejudiced in favor of SCSI as the controller of choice, and its obvious that this prejudice spills over into the way Windows 2000 works with IDE interfaces.
In the recent past, SCSI drives and controllers were considered the most reliable, fastest, and more professional approach to serving up data. The only drawback has been the exceptionally high cost of implementation. As far as developers were concerned, including those at Microsoft, IDE was definitely not a consideration when important data was at stake. This narrow minded focus on SCSI and the shunning of IDE has had a inhibiting impact on the evolving IDE technologies that we are seeing today. As a partial result, support for IDE drives in Windows NT 3.5, 3.51, and NT 4.0 has written in such a way that it is being treated as a variety of the SCSI controller, rather than a separate technology. We see change on the horizon though, at least in the development of alternate solutions using UDMA and Ultra-ATA.
If you’re wondering what supports the contention that NT developers are singularly focused towards SCSI, just take a good look at the Boot.ini files and the addressing scheme used to locate system files used in Windows NT, and then compare them to the recently released Windows 2000. There’s no difference between the two operating systems, and what you see is directly tied to the evolution of SCSI controllers and device ID enumeration. Anyone who has spent time with Windows NT has probably reached the same conclusions, support for SCSI is considerably more robust than that of the various implementations of the IDE and UDMA/Ultra-ATA specification. We’re not saying that Microsoft hasn’t bothered to support IDE and ATA in Windows NT and Windows 2000, just that the support provided is measurably different for IDE/ATA. Microsoft, by design, has made sure that their has been a devoted driver for each and every make and model SCSI controller, while at the same time managing IDE/ATA controllers with their generic ATAPI.SYS driver. Obviously, this approach is necessary with SCSI, as no two controllers work the same way, however the IDE and ATA specification is supposed to be a hardware standard in its own right. With the advent of high speed Ultra-ATA controllers, there’s an obvious need for similar support.
Given the recent developments in ATA device technology, especially that involving manufacturers such as Adaptec and Promise, end-users are implementing ATA controller devices and Ultra-ATA drives in place of SCSI as a form of cost saving. In doing so, they are presuming that all IDE interfaces are alike, generic if you will, and are letting the generic ATAPI.SYS driver that comes with Windows 2000 handle the interface. Unfortunately, in most cases, this approach hampers expected performance as these new IDE/ATA controllers require their own special drivers because the generic ATAPI.SYS driver is inadequate.
Let’s look at the upside and downside of IDE and ATA..
Some users shun IDE for no other reason than someone told them that SCSI was a better way to handle data, but they really have no idea why. IDE/Ultra-ATA controllers, unlike SCSI controllers, rely on a small percentage of CPU power to move data through the system bus. SCSI controllers, on the other hand, handle all of this data movement within the controller, thereby leaving the CPU free to handle important tasks. Obviously, this leaves you with a choice, do you want your server wasting CPU cycles moving data, or would you rather it devote those cycles to tasks that it was designed for? CPU load is another factor. CPU intensive transactions load the CPU, forcing IDE data transfers to wait for CPU time. The most compelling reason for using SCSI is that data handling is synchronous while IDE data handling is asynchronous.
Early IDE methods relied on a data transfer method known as programmed I/O. This specification began with PIO 1, and eventually progressed through PIO mode 4, with each new release faster then its predecessor. Not too long after PIO mode 4, we saw the release of DMA (Direct Memory Address) drives and then UDMA (Ultra DMA). UDMA employs a new type of data transfer system, in that the disk controller has direct access to system memory for the purposes of moving data, without complete reliance upon the CPU. This substantially reduces the amount of CPU time involved as compared to the older PIO modes. As Ultra-ATA controllers develop, reliance on the system CPU will be eliminated, thereby putting these controllers in the same class as SCSI. Would you like to see a speed comparison between PIO and ATA?
In the last year or so, we have seen a fast evolutionary trend in IDE/ATA controllers and drives that no one thought possible just five short years ago. Today, there are highly reliable 30 to 100 Gigabyte 7,200 RPM drives with burst rates of 66MB/sec to 100MB/sec that have become commonplace. These new devices aren’t terribly expensive, especially when compared to their SCSI brethren.
On systems utilizing only a single hard drive, we feel the jury is still out on whether there is a practical performance difference between ATA/66 and ATA/100 systems. Even the latest Intel 8xxxx and VIA chipsets and system buses can’t really take full advantage of an ATA/66 drive at a sustained 66MB/sec, let alone 100MB/sec. Stand-alone systems utilizing multiple drives, and small departmental servers can benefit from these higher burst speeds, but a single drive system really doesn’t benefit. Obviously, if the cost is minimal between a system that has ATA/100 drives as opposed to ATA/66, then go with the ATA/100 drives if for no other reason then to avoid a drive upgrade in the future. On the server side, with a little thought, and some careful planning, an ATA/66 or ATA/100 based server can perform as a reasonable substitute for a SCSI based server, especially if you’re budget is strained. Obviously there are exceptions, but today even if you need hot-plug drives, there are IDE solutions coming onto the market. Unfortunately, at the moment, there are some SCSI features only available to SCSI based systems.
Okay, now that you have some background..
As we mentioned above, most users ignore the specialized drivers that come with their IDE/ATA controllers, and those using the latest motherboards without these separate controllers really don’t know how to get the best performance out of their on-board IDE/ATA controllers in Windows 2000.
Fact: UDMA is not enabled by default when installing Windows 2000, it must be enabled. When UDMA is enabled, it is not optimized by default. You must explicitly do both, but there are questions as to the best route to take. There are exceptions to the above facts!
In order to enable UDMA and optimize it in Windows 2000, you need to do a little research, and the best place to start that research is with the components that make up your system. You will need to know exactly which UDMA specification is being utilized in your system, if any. This information can usually be found in the motherboard (main board) manuals for your system. Although we suspect that most computers that shipped within the last year are ATA/66 or ATA/100 capable, this is not a given and should be researched carefully. There are mandatory requirements to be met before you can enable UDMA/Ultra-ATA support.
After you have determined your systems capabilities, and presuming that your system is either ATA/66 or ATA/100 capable, you will need to determine whether UDMA has been enabled, especially if your system came with Windows 2000 preinstalled. Obviously, if you have built your own system, you should know whether these capabilities exist, whether you have installed the appropriate drivers and whether or not you have enabled this support. If your system came with Windows 2000 pre-installed, or you have recently installed Windows 2000 on a system that was previously Windows NT or Windows 95/98, you will need to determine whether the correct controller drivers are available from the manufacturer.
We have reviewed a large number of articles appearing on the Internet regarding the subject of enabling UDMA/Ultra-ATA in Windows 2000, most of which have been written by some of the more prominent technical writers. Most suggest that the only way to determine whether UDMA/ATA has been enabled is though Device Manager and the property sheets for the respective IDE buses. This is an assumption of the writer, and their statements can be misleading. If you’ve been researching the subject, and have read some of the same articles we have regarding the subject UDMA and Ultra-ATA in Windows 2000, there’s a good chance you’re as confused as we were. Next, we will try and dispel some of the myths and eliminate some of the confusion.
Enabling UDMA/Ultra ATA (Facts and Fiction)
Notice: Windows® 95, Windows® 98, Windows® NT, Windows® 2000 and
Microsoft® Office are registered trademarks or trademarks of the Microsoft Corporation.
