Native Command Queuing 

A simple way to explain how a hard disk works is: hard disks receive read/write requests from the chipsets I/O controller which are then buffered on the hard disks memory controller. The buffered requests are then carried out by the hard disk's on board controller. The hard disk's heads then move to the correct part of the disk (platter) to perform the read or write.

The problem with this method is that the hard disk performs the requests in the order that it gets them. If the first request is at the start of the disk, the second at the end of the disk and the third at the start of the disk, the hard disk would have to move all the way across to the end of the disk and back again. This process would naturally take longer than having to read three files at the start of the disk. This is why hard disks manufacturers recommend you defrag your hard drive frequently.

Native Command Queuing allows the hard disk to dynamically change the order in which the read/write requests are done. For the example above the hard disk would reorder the requests so that the first and third requests are done before second. This would save the whole disk head moving across the platter and back again, theoretically halving the time taken to perform the task.

Another way to present NCQ is to compare it to the "Travelling Salesman Problem". NCQ is very similar to the TSP. Essentially, the TSP is a logistics problem requiring a travelling salesman who has to visit a variety of different locations to optimise the route he takes to cover all customers with the minimum amount of travelling. It is discussed a lot in logistics courses and there are vast corporate resources devoted to managing internal versions of this problem - whether relating to delivery trucks' routes or field service engineers' work plans - as companies can save a lot of money by working out the optimum route their vehicles travel. The TSP is a particularly good example to explain NCQ as it bears this similarity to it: the larger the number of locations that need to be covered, and the further away they are, the more there is to be gained from optimising the route.

Here are two examples of a hard disk travelling to read data at four different physical locations on a platter. The red line shows the route the reading head takes. It is obvious from the images that the second one uses NCQ to minimise the distance the head travels.

Typically, the time taken to access a file is the normal seek time the hard disk displays added to the rotational latency (time taken for all the spinning). Reducing the latency sufficiently can halve the access time.

For general hard disk usage such as application and game loading NCQ doesn't add much benefit. When an application or game is installed on the hard disk all its contents are located around the same area. So, when an application or game is loaded the amount of hard disk head movement is naturally low. Further, the fact that most applications and games load sequentially causes NCQ to not make a big difference in disk access times.

Running two different applications simultaneously is where NCQ should start to shine. Two applications at two different locations on a hard disk fighting for access will benefit from NCQ. With the increase of multi threaded applications and the use of Hyper Threading technology, NCQ will gain in popularity.

A technical paper on NCQ (PDF, 670 KB)

The bad news is that there are a very few motherboards that support NCQ. Our test setup hardware >>