So, what do the benchmark results tell us? Let's recap the results and see what we can understand from them.

Business Disk WinMark 99

Instead of a incredible difference in performance, we saw only a miniscule improvement in performance with IDE Block Mode enabled. Mathematically speaking, IDE Block Mode improved performance by approximately 1.7% over the disabled mode.

High-End Disk WinMark 99

In the high-end portion of the WinMark disk tests, the system showed absolutely no change in performance whether the feature was enabled or not.

Winstone 99

Enabling the feature definitely improved overall system performance but only by a miserly 0.4%.

From the results, it's evident that IDE Block Mode improved the raw transfer rate by a maximum of about 1.7%. This translated into an improvement in the overall system performance of only 0.4%. Note that this is only for office applications, as used in the Winstone 99 benchmark suite.

Games may benefit more or less depending on its reliance on the hard disk. Naturally, games with minimal graphics will benefit less while games that uses lots of textures or other streaming data will benefit more from the feature. However, the maximum benefit realized should be rather lower than the improvement of 1.7% seen in the Business Disk WinMark 99 test. This is because games do more than just transfer data. :-)

Now, that's pretty pathetic considering what we would have expected from such a promising feature. Remember  that instead of just transferring 512 bytes per interrupt, IDE Block Mode allows transfers of up to 64KB per interrupt. On cursory examination, one would have converted that fact into an improvement in transfer rate of 128X in magnitude!

Unfortunately, that would be a wrong way of looking at things. Note that while IDE Block Mode increases the amount of data that can be transferred per interrupt, it does not directly increase the throughput of the hard disk. Any increase in throughput after enabling this feature should be considered wholly as a welcomed side effect, one that's due to improved efficiency.

Instead, IDE Block Mode's main purpose is to reduce the overhead of IDE transactions. Transferring 1MB (1024KB) of data will require 2048 interrupts with the standard IDE protocol. But with IDE Block Mode, the number of interrupts could be reduced to only 16. I only wrote "could" instead of "would" because some data transfers will definitely be less than 64KB in size. So, the number of interrupts required with IDE Block Mode would generally be more than the 16 stated above for a 1MB transfer but will definitely be a lot fewer than the 2048 interrupts required by the standard transfer mode. In any case, the sheer potential in the reduction in overhead is quite apparent.

With fewer interrupts, less processor time is taken up if DMA transfers was not enabled. But if you are using a bus-mastering driver from your chipset manufacturer (or have enabled DMA transfers for the bus-mastering driver shipped in Win9x/2000), the fewer interrupts mean that the IDE controller will be able to process them faster and spend more time transferring data instead of shuffling data requests. This translates into greater efficiency which accounts for the slightly higher transfer rate recorded by the benchmarks.

So, if you not using a bus-mastering driver (or have left it disabled), you should expect less CPU utilization with IDE Block Mode enabled. It wouldn't be as low as it would be with a bus-mastering driver because the processor is still burdened with the job but it would definitely reduce the load. So, the processor will be able to allocate more time to process other tasks, instead of IDE transactions.

But if you are using a bus-mastering driver, the chipset has already taken over the processor's job of handling IDE transactions. There would not be any improvement in CPU utilization as a result because the processor's involvement has already been minimized. But there would a significant improvement in efficiency because of the huge reduction in the number of interrupts to be processed. The end result would be faster access to the data (due to a much lower overhead) and a slightly higher throughput.