Intel IOMeter: Sequential Read

The algorithm used for read and write speed measurements in this test is completely different from what we saw in HDTach benchmark. In our IOMeter patters the HDD receives read and write requests with a fixed queue depth (queue=4), i.e. the hard disk drive is always under a certain workload. At the same time, we do not mix together the reads and writes thus making it easier for the HDD to work. Really, if we need to know the maximum write speed of the hard disk drive, why should we ask it to write and read simultaneously? The second difference of our approach to measuring the read and write speeds is the fact that we make the hard drive work with the data blocks of different size instead of using data blocks of the same size.

As a result, our methodology provides us with much more information about the HDD tested, and not only about it!

Well, let’s begin with SequentialRead. We measure the read speed of the HDD working with data blocks of different sizes. The table below will illustrate the dependence of the read speed on the data block size (the sizes are given in the first column):

Let’s have a look at the test results taken for hard disk drives of different capacities separately. We will start with the 80GB drives:

This diagram allows us to compare the read speed of a regular ATA HDD with the read speed of the SATA HDD, moreover, the latter was tested with three SATA controllers. Yes, there is no mistake: we used three controllers. As you remember, the special Cache Config utility mentioned in the beginning of the article allows us to turn our Promise SATA 150 TX2 Plus into two completely different controllers.

As we see incase the data blocks are small, the SATA HDD working with Promise SATA 150 TX2 Plus controller in WB mode appeared twice as fast as its rivals. I don’t know what you think about it, but I am pretty concerned about this repetition factor. :)

But I am also concerned about the fact that when we set Promise SATA 150 TX2 Plus controller into WT mode, the SATA hard disk drive appeared even slower than the regular ATA solution.

SiliconImage controller didn’t show any outstanding results: the performance of a combination with this controller was about the same as the performance of the regular ATA HDD working with a “regular” Promise Ultra100 TX2 controller.

When we work with bigger data blocks (>86KB) all SATA controllers and drives appeared equally fast and the ATA drive fell a little bit behind them. Its read speed reached 40MB/sec (as soon as the data block size grew up to 16KB) and stopped there.

The results indicate that SATA controllers without specifically optimized drivers do not increase the HDD read speed in case of smaller data blocks. But let’s not hurry with the conclusions too much, because as you remember, we saw some unknown chip on the Seagate drive picture. Maybe it is the one that prevents SATA interface from working to the utmost of its powers?

Let’s check the performance of 120GB HDDs now:

As we see, ATA HDDs are the winners this time. Moreover, a solution with 2MB cache-buffer appeared faster than a solution with a larger cache-buffer.

It is hard to say what made SiliconImage SATA controller and SATA HDD work so slowly. Especially, since the 80GB drive performed just fine with the same controller, as we saw in the previous tests. Well, let’s add this question to our list of mysteries :)

And now let’s discuss another phenomenon: the read speed of a SATA hard disk drive with Promise SATA 150 TX2 Plus controller. Being a dedicated materialist, I claimed that this performance growth is simply impossible without any special optimization. With quite a big probability, we dare claim that the requests are processed and cached by the controller driver, which automatically lays the entire workload onto the system CPU.

IOMeter test also measures the CPU utilization during disk operations processing, so that we can compare the results shown by all our controllers and double check our suppositions:

Take note of the upper graph: it proves just excellently that the WB mode of Promise SATA 150 TX2 Plus controller is implemented on the software level. When the data blocks are of small size the CPU is loaded almost completely. At the same time, as the requests size increases (here we are talking about requests sent to the HDD and hence received by the controller driver), the CPU utilization drops down rapidly. When the data blocks are of larger size, the CPU utilization reaches around 30% and then drops down to the level of other testing participants.

A little bit earlier I expressed a supposition that the controller drivers in WB mode combine the data blocks with sequential addresses, but the CPU utilization graph suggests that the driver algorithm is far nit that simple. But there is one thing, which we can state with all certainty: the driver doesn’t optimize the requests more than 64KB big.

By the way, Promise SATA controller managed to show not only the highest CPU utilization in this test, but also the lowest! Take a look at the results shown by a SATA HDD and a Promise SATA 150 TX2 Plus controller in WT mode. When the data blocks size is below 4KB, the CPU utilization of this combination is lower than that of all other configurations. And the most curious thing about it, is the fact that it hardly depends on the data block size! What tricky drivers Promise has got!