Introduction to hard drive technology

Native Command Queuing

Native command queuing, or NCQ, is a feature that has been included in many consumer SATA drives in the last few years. Command queuing is a technology that was introduced in 1994 as TCQ (tagged command queuing) with the SCSI2 standard, so it’s by no means a new development.

The technology allows for significant performance improvements when used in server environments by reordering commands sent to the drive, optimising them so that there is as little head movement as possible when servicing the commands.

As a simple example, consider four requests were sent to a drive involving accessing (reading or writing) data on tracks 8, 4, 7 and 1. For this example, we’ll say that the drive’s R/W head was located at track 1 before these requests were sent to the drive.

A drive without command queuing would service these requests in the order in which they were received whereas a drive utilising TCQ or NCQ would rearrange these to 1, 4, 7, 8. In the case of this example, let’s assume for simplicity that it takes 1ms for the drive head to move one track. From the table below you can see that command queuing significantly improves performance by dramatically reducing the time required to service the four requests from 21ms to 8ms.

In that case, command queuing is a winner all around, right? Not necessarily, because command queuing introduces a slight overhead to the drive’s access times. In a typical server environment, queue depths are high and requests are random, so the performance gained from command queuing more than outweighs the overhead. In a desktop environment, a drive is rarely asked to service more than one request at a time, so when NCQ is enabled most of the time the drive is “reordering” a single request. Even in heavy drive access multi-tasking scenarios, queue depths don’t generally exceed a couple of requests.

The occasional performance improvement when there is a queue depth of greater than four requests does very little to claw back the overhead of NCQ or TCQ. Desktop applications typically suffer around a five to ten percent drive performance deficit when command queuing is enabled. Would you notice this performance drop? Maybe not, but it’s along the same lines as slightly overclocking a CPU or graphics card. Turning it off is technically faster, so you may as well.

"But I use my computer more like a server, I multi-task loads!"

It isn’t uncommon for people to think that because they are a power-user, they make far more disk access requests than a typical PC user. While this may be true, queue depths still remain within the realms of desktop access patterns. Even if you scan for viruses while defragmenting your drive, while using Photoshop while streaming HD video while gaming and so on, queue depths will remain insufficient for command queuing to provide an overall increase in performance.

Server access patterns involve many users, potentially hundreds or thousands, making requests for data at random locations on disk. Typical queue depths in servers are anywhere from double digits up to hundreds of requests, meaning that it isn’t uncommon for command queuing to produce a 30 percent performance gain when used in this context.

A way in which current single-user hard drive performance could be technically improved would be the implementation of adaptive NCQ. We already know that desktop performance is improved by turning NCQ off because queue depths are too low most of the time for it to offer an improvement, but what about the occasion where there is a queue depth that would benefit from NCQ?

Perhaps an adaptive NCQ method could be employed that simply switches on NCQ when the queue depth hits four and then off again when it drops below. It could well be the case that this switching would provide too much of an overhead to give an overall benefit to performance – this is probably the reason why it hasn’t been done already.