We are going to start by checking the controller’s ability to reorder the commands in a special pattern that contains requests to read random-address sectors.
Steadily increasing the load of the disk subsystem (the number of requests) from 1 to 256 stepping 1, we will judge as to the presence/absence of TCQ by the increase of the performance gain (the drive’s speed when processing the incoming requests) depending on the request queue depth.
We have already employed this type of load to determine the TCQ support of the WD740GD on the Promise SX8 controller, but we had an engineering sample of that controller then and we couldn’t measure precisely the value of the gain.
Besides the results of the Talon ZL4-150 controller the diagram also shows the results of the same WD740GD drives on a Promise S150 TX4 controller which does not support TCQ.
As you see, enabling TCQ you get a considerable performance bonus. What’s most important for users, this bonus is also noticeable at small loads. The results of the WD740GD on the Talon ZL4-150 controller with disabled TCQ look similar to its results on the Promise SATAII 150 SX8 controller (see our Raptor 2 review).
The disabled TCQ works the same way – up to a queue of 32 requests the commands cannot be executed out of order, both on the drive level and on the controller’s driver level (see the green graph). After that we see a sudden growth of the controller’s speed as its driver starts to sort the requests out.
The “TCQ On” graph of the Talon controller resembles the graph we got earlier with the Promise controller: there’s a flat stretch around the load of 32 requests and there are two “humps” at high loads. So, TCQ does work on Pacific Digital’s controller, too.
Meanwhile, the results with disabled TCQ support have no practical meaning as the controller just stifles the performance of the drives in this case.
Let’s now see how the Talon ZL4-150 can handle a mixed stream of requests.