# NCQ vs. Linux kernel IO schedulers

## tnt

is it better to rely on sometimes questionable hdd NCQ implementation or turn off NCQ and let Linux kernel do the queuing via its' own IO schedulers?

theoretically, Linux kernel schedulers could:

- use a lot more memory (RAM) for storing and deffering writes (further prioritizing reads thus lovering user-experianced latencies)

- be process-aware

- be fine tuned through different parameters in /sys/block

any info/comment/benchmarks on this topic?    :Confused: 

----------

## linuxtuxhellsinki

Isn't the "Native Command Queuing" supposed to do just what it says.

It's internally ordering drive's read/write commands in optimal way that the drive head doesn't have to move so much, resulting in increased performance in high workload (long queue) and less movement (aka. wearing) of drive.

----------

## tnt

yes, but...

(note: LBA is used just to illustrate NCQ's work, I know that NCQ doesn't make decisions based on LBA but on track/head/sector information)

let's say that during the time, following IO requests are generated:

read1(LBA005) - write1(LBA015) - write2(LBA0010) - write3(LBA0020) - read2(LBA0025)

1. we have NCQ turned on, kernel sends up to 31 requests to drive not waiting for them to be done. so, kernel sends 

read1 - write1 - write2 - write3 - read2

and drive organizes them to 

read1 - write2 - write1 - write3 - read2

not bad, but we wait for 3 write operations to get data we need in read2

2. we turned off NCQ (queue_depth is 1), kernel sends requests 1 by 1. so, if kernel scheduler is read-priority-aware, LBA-based-request-reordering-capable and there is enough space in write buffers, kernel sends

read1 - read2 - write2 - write1 - write3

meaning, we get data from read2 as soon as we can and writes can be done latter, when user/application doesn't wait for some data.

I understand need for less head movements, but then again, I think that nowdays is much more important to serve someone waiting for data as soon as possible. 

this is even more true for SSDs because there's no head-movement argument for NCQ.

----------

## linuxtuxhellsinki

Yes, I can understand your point and it could be better in some "strange" situations (desktop usage ?) where you might need better responsive time, but still NCQ is working at "lower" level with where hard-drive's internal tracks/blocks are situated and Kernel doesn't have any clue of that and cannot do the same thing.

But you can always use some "write-caching" options, so it doesn't slower the reading from disk (so much).

It might be better off with SSD-drives (does it even have NCQ)  :Question: 

Edit: Yes it does http://en.wikipedia.org/wiki/NCQ

 *Quote:*   

> NCQ is also used in newer solid-state drives where the drive encounters latency on the host, rather than the other way around. For example, Intel's X25-E Extreme solid-state drive uses NCQ to ensure that the drive has commands to process while the host system is busy processing CPU tasks

 

----------

