Now let’s try to figure out if the implementation of the CQ affected the WD740GD performance in any way. The easiest and the most illustrative way to estimate the CQ efficiency is to compare the performance of the drive with the enabled CQ support with the performance of the same drive with the disabled CQ support. As a result of this simple comparison we could get exactly this particular efficiency value, but we discovered some unexpected problems on the way.

It turned out much harder to disable CQ support by WD740GD than to find it!

On reading these words many of you could have recalled that most SATA controllers use SCSI mini-port as a driver. And it means that there is a SCSI Properties page, which appears in the HDD properties window. And on this page you can see “Disable tagged queuing” option. This all absolutely true: there is a page and there is an option.

Of course, we selected this option immediately. However, our experiments showed that the HDD performance doesn’t depend on the fact whether the “Disable tagged queuing” option is selected or not.

This is unbelievable! But the surprises do not end up here. It turned out that selecting this option doesn’t have any effect even for the SCSI HDDs! We tried to check how the thing works with an Adaptec 39320D controller and different hard disk drives, and suffered a complete fiasco.

Well, it looks as if we will not manage to disable CQ in the SCSI Properties page. But let’s not give in so soon. I have already had a chance to “play” a little bit with the supported queue depth on SCSI drives by editing the registry key (see our article called Ultra320 SCSI Interface: Highs and Lows. Part II for details):

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\adpu320\Parameters\Device\

But then I simply changed the queue depth from 32 to 64 or 256. And if we set it to 1 or 2? Will this automatically disable CQ?

Let’s check this out now! We find a section of the registry where the SATA controller driver left a track (for instance if we use a Promise S150 TX2 Plus controller):

Well, we see the magic word “Tag” and the number “33”, which stands for “32+1”. So, we change this parameter, run the benchmarks anew, and… Nothing changes! The HDD performance remained the same! Unfortunately, this method didn’t work for any of the SATA controllers we had at our disposal. This parameter of the SATA drives seems to be used for some other purposes, I assume…

Maybe we could try to estimate the CQ efficiency by comparing the dependence of the HDD performance on the queue depth? For this purpose we create a simple pattern in Intel IOMeter, which contains requests for random sectors reading, and run the benchmark a few times for different queue depths varying from 1 to 256 requests with 1 request step. We run the tests for two WD drives: WD740GD and WD360GD. If the dependence graph for the HDD performance under this type of workload will be shaped differently for both drives, then we can suppose that it is the effect of the CQ. So, what do we see?