While the HP file is dated April 3, 1998, the PIIX.INF file has a date of December 4, 1997, and the PIIX.SYS file sports an earlier date of October 21, 1997.

Installing this version of the intel driver is much the same as all of the earlier versions I have installed.  Opening the EXE file unpacks the components to an IDE folder.  Contained in the folder with the INF and SYS files is a well-written README document and a driver version checking utility.  Once the IDE folder has been created and the files unpacked, it is a simple matter of switching to the control panel SCSI applet, removing the current driver, installing the new one, rebooting, and checking that DMA / UDMA has been enabled.

Even if you are a seasoned veteran of driver installation, the README text offers a lot of interesting information, including the disk drives and CD-ROMs that have been tested with this driver and this statement:

NOTE: 
*          This document refers to desktop systems with 
*          the following Intel PCIset devices: 
*          82371FB (PIIX1), 82371SB (PIIX3) or 82371AB (PIIX4) in 
*          conjunction with the following Intel PCIsets and 
*          Intel AGPsets:  430FX, 430HX, 430TX, 430VX, 440FX, 
*          440LX and all future Intel AGPsets.

A rather broad statement.

Testing and Retesting
My system is in a constant state of change.  I have often thought that it would be easier if my case cover was attached with Velcro rather than screws.  Recent changes have included switching to the most recent Abit AX5 BIOS (PAX58N.EXE), the addition of a NDC network interface card, and tweaking my SDRAM timings a bit quicker.  At the same time, my disk drives have become more populated with files.  As a result of this, the new benchmarks did not completely agree with my previous tests.  Since it is difficult to compare apples with oranges, this meant retesting all of the previously tested NT drivers.  I chose to start with a fresh installation of NT Workstation.

Those of you who have done a bit of benchmarking on different installations of the same operating system will have probably noticed that no matter how careful one is to keep the installations uniform, each installation benchmarks differently.  The differences are usually not drastic, but some installations bench better than others.   Sometimes the CPU marks will rise and the disk marks will decline, and sometimes it's the opposite.  In any event, the marks for my most recent tests were different enough (from the old results) for me to reinstall Workstation three times, each time testing all drivers to verify the results.

The following results are the average of three installations of NT, with each driver tested three times on each installation.  All previous hardware and software was used with the additions listed above.  Also included are the CPU results using Bench32 from U Software.  Unfortunately, the link I had for U Software (http://www.usoftware.com/) is no longer a valid link.  I have searched for a new link with no luck.  When I find one, I'll update this page.  All previously mentioned defragging and rebooting practices were used.

NT 4.0 Workstation - New Test 

The notable changes between these results and the old test results are the increase in Winbench's CPUmark results (faster RAM timing?),  the decrease in end transfer rates and increase in access time (drives have less free space?), and the unexpected decrease in CPU utilization for the MS drivers  in Threadmark.  (I haven't a clue!)   Also, the Intel 2.01.0.3 CPUmark32 have dropped relative to the other drivers I tested.

Real-World Timed Test
Again, I timed the transfer of a 500 MB folder of various types of files between my two disk drives.  The transfer was done three times from one drive to the other and back again for each driver on all three installations of NT.  The results were averaged.

Conclusion
No matter which driver you decide on, there is improvement to be gained by enabling DMA / UDMA.  In the latest batch of tests, it is hard to pick a clear winner.  My choices would be the Intel 2.01.0.3 and the Tyan 4021.  Up until this last test, I had been running the Intel driver without problems.  I have now switched to the Tyan drivers to see how they fare over time.

It is entirely possible that using NTFS rather than the FAT 16 file system would alter the results, but that is not an option for me at this time.  When it is, I'll retest.

News
For those people with the atapi version of Iomega's Zip drive who cannot enable DMA due to Iomega supplied drivers, Microsoft's hotfix  zip-fixi.exe seems to take care of this situation.  Once you have removed the Iomega driver, make sure you don't reboot until after the MS atapi driver has been installed in its place.  Thanks go out to Vasanth for his help on this.

More News
A little update is in order here.  Thanks to those of you who have been emailing me with your experiences with the various drivers.  It would seem that I am hearing of a growing number of people getting the dreaded blue screen of death with the MS driver after enabling DMA with DMAcheck or forcing it through the registry.  It would seem to be related to a possible conflict with the (non DMA?) CD-ROM on the secondary channel, as unplugging the CD solves the problem.  In all of the cases I have been told about, switching to the Intel driver has solved the situation.  DMA enabled and no BSOD with the CD attached.

The changes are as follows:

1.  Re-apply Service Pack 3.  Allow SP3 to replace the atapi.sys file with the older SP3 version. Reboot.

2. Install the Intel driver.  Reboot

3. Check for DMAEnabled : REG_DWORD : 0x1 (in this registry key).

4. That's it.  If you find that this fixes your situation, please email me.  I am putting together a list of components / systems that this has worked on.  Thanks to Dan for his great documentation on this.  :^)
 

MS Drivers work - Intel's don't
I have been receiving a lot of mail regarding different systems and what drivers are or are not working in various situations.  There have been too many letters to post them all, but here are a couple of the more recent ones concerning the MS driver being the driver of choice.  It would seem that the bottom line is to use the driver that works best for you.

• We have been having an enormous amount of trouble with LS 120 drives as the only floppy on PII 233 systems running Windows NT 4 SP3.  The drive would not format, or read and write 1.44 floppies as they were supposed to do.

The problem turned out to be twofold.  The first was the use of the Intel Bus Master driver (PIIX).  The LS 120 didn't like it at all.  The second was the atapi.sys that came with SP3.  Changing it for the version from a link on your page (dated 8 Jan 1998) fixed the problem!!  You've got no idea how long we have been working to fix this problem.

An added bonus was following your instructions to enable DMA by setting the registry entry to 0x2.  This worked very well, and our systems seem significantly faster.

Regards,
Tim Jones

• I've two UDMA disks, connected on the two different IDE channels and, on the second IDE channel, I have also a Pioneer IDE CdRom (32x). I have configured my disk as a mirror (1.5 Gb) disk and a striped disk (the remaining space) and, in this configuration, enabling DMA (0x2 in registry) causes machine lockups when accessing the CDRom using the PIXIIDE driver while, using the regular ATAPI drivers from NT works perfectly. I haven't tested the latest PIXIDE drivers (the HP ones) or the Tyan.

Saluti,
Massimo

• ......snip......A question:

>>Finally, what are the ramifications of forcing DMA support via the registry if DMACHECK fails to activate it?  >>Am I looking at potential data corruption, or what?

The reply from Bill Whipple:

>So far I have gotten this response from my request up through Microsoft:

>>In a word, yes, he's looking at data corruption.

He went on to say that Microsoft did not condone forcing UDMA via the Registry since that driver had not been corrected to properly use it (SP4 released any day now will).  While corruption had not been reproduced in the
lab, the chances of it happening were less than remote (tongue squarely in cheek).

Roj

My Thoughts
The last letter was written in June 98.  As of late August, SP4 is still not out and the Beta SP4 version I have seen still required the forcing of the 0X2 value to enable UDMA in the tested system.

While I would not recommend forcing the registry of a system used in a business environment, I have been running my home system this way for about 4 months with no data corruption or other problems.  As usual, a back-up of all data is a wise move before any changes are made.

Second Thoughts?
New drivers to be tested include the newest from HP, the version 2.04.0 series and a comparison of NT4-SP3 versus NT4-SP4 to see if there is any improvement.  I will say that if the beta version of SP4 was any indicator,  my system saw little if any improvement in transfer rates or system performance.

•  If you have come across drivers I haven't tested, find dead links, errors, want to enlighten me, or have questions, email me.

~Jim