Re: Lower HD transfer rate with NCQ enabled?

[Mark Lord]

Chris Snook wrote:
> Paa Paa wrote:
> > I'm using Linux 2.6.20.4. I noticed that I get lower SATA hard drive 
> > throughput with 2.6.20.4 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.

-ml
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/