Performance

HDTach 2.61

We will start our tests with HDTach 2.61. We have been using this benchmark for three years already and we have seen a lot of strange results, but this is absolutely unbelievable:

First of all, check out the Average Access Time results: 80GB HDDs appeared much better here than 120GB drives (although there is nothing to be surprised with, we have already told you about the cut-down platters of 80GB models). It was a different thing that surprised us: among all 80GB hard disk drives, the results of a Promise-WT + SATA80 combination stood out having shown only 12.6ms access time! The only explanation that comes to my mind right away is that the HDD doesn't do any lazy writes when the WT mode of Promise SATA150 TX2 Plus is enabled.

Secondly, if we take a look at the second line, Read Burst Speed, we will see a very strange picture: the results differences between the tested SerialATA HDDs are simply gigantic. The major "incendiary" appeared Promise controller: depending on the caching mode (WT/WB) the read speed from the HDD buffer (Read Burst Speed) varied from 60 to 334MB/sec!

It is also quite remarkable that the Read Burst speed depends a lot on the hard disk drive firmware versions and controller driver version! :)

But if we take a closer look at the obtained results, we will see that it would be simply impossible for any controller to transfer 334MB/sec via the regular PCI32/33MHz bus. It means that these results are of no value and HDTach benchmark cannot always measure the Read Burst speed for SATA HDDs correctly. As soon as we discovered that, a question arises: does HDTach measure the Read Burst speed correctly for regular hard drives? Or this benchmark is caught unawares only by the tricky Promise drivers?

Well, let's leave out the read speed, as there is nothing specifically interesting there. And as we come to writing...

Please tae a look at the maximum write speed of the ST3120024A HDD (ATA120-8 according to our abbreviations) – it is more than twice as big as by ST3120023A (ATA120)! It would be quite logical to suppose that ST3120024A HDD manages to reach such a high write speed not only due to the mechanical increase in cache-buffer size, but also due to a new caching strategy applied. A little later we will taker a look at the graphs screenshots for reads and writes, and in the meanwhile let’s check another strange phenomenon we discovered.

With the SiliconImage controller all SATA drives of various storage capacity showed not only different maximum write speed (we cannot disregard the possibility of occasional write speed boosts), but also different average write speed. And this happened even though both HDDs feature the same firmware and were tested with one and the same controller. This is really surprising...

Before we start talking about the actual benchmark screenshots, I would like to draw your attention to the processor utilization rate demonstrated by a SATA drive connected to Promise controller working in WB mode: the CPU utilization appeared 17.5%! Well, this is another piece of evidence proving our supposition about the software implementation of WB algorithm in Promise controller drivers. However, HDTach test has already disclosed some of its surprising secrets to us today, so I would refrain from drawing any conclusions so far.

Now, let’s have a look at the graphs obtained in the run of HDTach benchmark. Here is a screenshot taken during ST3120023AS tests with 3.00 firmware and Promise SATA 150 TX2 Plus (WB) controller:

ST3120023AS with 3.00 firmware and Promise SATA 150 TX2 Plus (WB)

The emotions awakened by the read graph are highly positive, but as we come to writing things turn pretty strange. In the very beginning the write rate sky-scrapes (up to 60MB/sec), after that it rests for a while at 50MB/sec and then drops down to 10MB/sec. then the write speed rises again but manages to reach 30MB/sec only and then again crashes down to 10MB/sec. Further on we will see the graph oscillating between the last two values, which will look like a thick green line on the graph.

As we understand, the write speed on the platter by Seagate Barracuda SATA V HDD cannot make 60MB/sec. Then it means that this value is none other but the data transfer rate at which the data block is transferred to the HDD cache-buffer. If this statement is correct then the speed upsurge in the beginning of the tests can be easily explained by the fact that the cache-buffer was filled with more than one request! If the HDD firmware assigns a significant part of the cache-buffer to the lazy write, then we will really see something like that. To double check this supposition I opened the log-file of the HDTach benchmark and was very pleased to discover that the write speed started dropping as soon as it came to the 8th request (as HDTach saw it). After that we resort to simple math1ematics: the cache buffer size is 8MB, the data block size used by HDTach is 1056KB (in reality this benchmark generates a pack of 33 requests with 64 sectors in each, but Promise controller drivers “combine them into one big request”, because the controller works in WB mode, as I understand it).

Unfortunately, the monitoring utility we used didn’t allow to get the request size AFTER it passed through Promise controller drivers. That is why our suppositions about the way Promise controller drivers work, are mere suppositions.

Now we multiply 7 by 1056 and get 7392KB. Let’s subtract from 8192KB (claimed cache-buffer size) the obtained 8392KB and discover that there was not enough room in the buffer for the 8th request! :)

Before the hard disk drive received the 8th data block from HDTach, it had to write at least 256KB of data on the platter (to free some room in the cache buffer for the complete 8th data block to be accepted). And this is possible only if the Seagate drive’s cache-buffer is organized in such a way that it allows uniting several cache blocks with different physical addresses into a single cache-line. Otherwise, the HDD has to rewrite all the data for one of the previous requests onto the platter, before it accepts the new data block.

Well, in reality things are even more interesting. To make a hard disk drive complete the write operation, which every normal HDD always tends to delay to perform a lazy write whenever possible, HDTach benchmark sends a read request (32KB) every time 33 write requests have been sent. What an insidious benchmark! :)