These are two almost identical curves, though one of them is a little above the other. And where are the qualitative differences? Maybe we should pay special attention only to the part of the graph for 1-32 requests queue? No problem:

But even when we take a closer look at this given part we do not notice any principal differences in the dependence of the HDD performance on the workload. We see a “flat area” typical of the IDE drives under low workload, and a slight increase in the gap between the two testing participants as the workload grows. If this small gap is the only effect made by the CQ, then I should admit that I am pretty disappointed. But the results shown by WD740GD are most likely to be growing faster because of the faster actuator used in this HDD.

Well, let’s try and play this trick with the queue depth on a SCSI drive, just to make sure. If the graph showing the dependence of the HDD performance on the requests queue depth differs for SCSI drives with enabled and disabled CQ, then… Ok, let’s first look at the graphs:

As we see, the old trick works fine on the SCSI drives. Having reduced the queue depth for tagged-requests, we prevented the SCSI drive (in our case it was Maxtor Atlas 15K) from processing these requests in the optimal way from its point of view. That is why it is not at all surprising that the HDD performance under any type of workload laid by the Intel IOMeter pattern equaled the HDD speed for queue=1.

But look how scalable is the HDD speed when we enable TQ! Even when we had only two requests the HDD sped up a lot: and we do not see any flat spots on the curve.

So, the experiment with a SCSI drive showed us the efficiency of the TCQ technology. However, we haven’t come any closer to the question: does Command Queuing work properly by WD740GD? If the graph for WD360GD HDD, which doesn’t support CQ, were similar to that of Maxtor Atlas 15K with disabled TQ support, then we could have stated with all certainty that WD740GD wins due to the implemented CQ support. However, both WD drives proved equally scalable depending on the workload and the performance difference between them is determined only by faster seek time of the new WD740GD.

Our supposition about WD740GD requiring some special SATA 1.0 controller in order to have the TQ working properly also didn’t prove true. We tested the drive with all sorts of SATA controllers but we didn’t notice any significant performance differences.

Summing up everything mentioned above I believe there remain two versions, which sound more or less reasonable:

1. WD740GD hard disk drive does support CQ, but the exiting SATA controllers ignore PATA CQ. And the performance growth we detected during workload increase can be explained by a banal requests sorting performed by the driver of the SATA controller.
2. The efficiency of the PATA CQ is so low that it is hardly noticeable against the background of the performance growth resulting from the optimization of the requests processing order by the controller driver.

Here I would like to stop our discussion, but I will definitely return to this interesting topic later in the upcoming articles.