[lkml]   [2007]   [Apr]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Lower HD transfer rate with NCQ enabled?
Chris Snook wrote:
> Paa Paa wrote:
>> I'm using Linux I noticed that I get lower SATA hard drive
>> throughput with than with 2.6.19. The reason was that 2.6.20
>> enables NCQ by defauly (queue_depth = 31/32 instead of 0/32). Transfer
>> rate was measured using "hdparm -t":
>> With NCQ (queue_depth == 31): 50MB/s.
>> Without NCQ (queue_depth == 0): 60MB/s.
>> 20% difference is quite a lot. This is with Intel ICH8R controller and
>> Western Digital WD1600YS hard disk in AHCI mode. I also used the next
>> command to cat-copy a biggish (540MB) file and time it:
>> rm temp && sync && time sh -c 'cat quite_big_file > temp && sync'
>> Here I noticed no differences at all with and without NCQ. The times
>> (real time) were basically the same in many successive runs. Around 19s.
>> Q: What conclusion can I make on "hdparm -t" results or can I make any
>> conclusions? Do I really have lower performance with NCQ or not? If I
>> do, is this because of my HD or because of kernel?
> hdparm -t is a perfect example of a synthetic benchmark. NCQ was
> designed to optimize real-world workloads.

No, NCQ was designed to optimize *server* workloads: lots of *small*,
random I/O's.

But WD drives, in particular the Raptor series, have a firmware "feature"
that disables "drive readahead" whenever NCQ is in use.

So they will perform poorly only any medium/large sequential access
if NCQ is employed. Which is why the custom MS drivers avoid NCQ when
doing large sequential accesses. Ours don't do this, yet.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2007-04-03 18:51    [W:0.082 / U:7.652 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site