Now let’s check what’s going on in HDTach 2.61 and HDTach 2.7 during write speed measurements:
And we see almost the same thing as during reading. Both benchmark versions send a pack of 33 requests 32KB big with sequentially increasing address and finish the pack with one read request. Probably this very last read request should make the HDD perform all the previous write requests, i.e. perform the lazy writing immediately.
If this supposition is correct, then measuring the HDD write speed is in no way a true measurement of this parameter, because as we have just seen, there is one read request in the queue.
I wonder why they forced this single read request in order to execute all writes? Anyway all the writes will sooner or later be pushed out by the new incoming write requests. Besides, there is the good old Flush Cache command, which could also be of some help, I suppose… :)
Well, it’s high time we made some conclusions.
Well, the “autopsy” revealed that the test algorithms in HDTach version 2.7, which have been inadequate for contemporary controllers and hard disk drives, remained unchanged since the times of HDTach 2.61. In fact the new version of this benchmark differs from the old one only by a more advanced interface design and much shorter operation time. Unfortunately, the read and write speeds measurement precision has been sacrificed for the sake of faster testing. Although I wouldn’t claim that the previous HDTach 2.61 was very precise here, too.
So, I don’t think it makes any sense to use HDTach 2.7 as it is now for hard disk drive testing. Moreover, it can be used for flash-drives testing only if we do not find anything better than that.
Now all we can do is wait patiently for the absolutely modified new HDTach version, which was promised by the developer a while ago (see this link for details), and hope that they will really take care of a proper HDD testing algorithm.