public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Mark Lord <lkml@rtr.ca>
To: Phillip Susi <psusi@cfl.rr.com>
Cc: Chris Snook <csnook@redhat.com>, Paa Paa <paapaa125@hotmail.com>,
	linux-kernel@vger.kernel.org
Subject: Re: Lower HD transfer rate with NCQ enabled?
Date: Mon, 09 Apr 2007 23:58:55 -0400	[thread overview]
Message-ID: <461B0B7F.1030802@rtr.ca> (raw)
In-Reply-To: <461A51D0.3000708@cfl.rr.com>

Phillip Susi wrote:
> Mark Lord wrote:
>> Phillip Susi wrote:
>>> Sounds like this is a serious bug in the WD firmware.
>>
>> For personal systems, yes.  For servers, probably not a bug.
>>
>> Disabling readahead means faster execution queued commands,
>> since it doesn't have to "linger" and do unwanted read-ahead.
>> So this bug is a "feature" for random access servers.
>> And a big nuisance for everything else.
> 
> I think you misunderstand the bug.  The bug is not that the drive 
> disables internal readahead; the bug is that host supplied readahead 
> requests work so horribly.  It is a good thing that the drive allows the 
> host to control the readahead, but something is wrong if the drive's 
> readahead is WAY better than any the host can perform.

Well, in this case, it has already been determined that switching
to a different Linux I/O scheduler gives back most of the performance.

But the drive can do readahead better than the OS:  With the OS,
everything is broken up into discrete requests, whereas with the 
drive firmware, it can continuously update it's readahead projections,
even in the midst of a command.  So it does have an advantage.

But again, only the WD Raptor seems to have serious problems here.
Other drives cope well with readahead + NCQ just fine.

Cheers

  reply	other threads:[~2007-04-10  3:59 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-04-03  7:11 Lower HD transfer rate with NCQ enabled? Paa Paa
2007-04-03  9:18 ` Nick Piggin
2007-04-03 21:31   ` Paa Paa
2007-04-04  2:06     ` Nick Piggin
2007-04-06 21:33     ` Bill Davidsen
2007-04-03 16:31 ` Chris Snook
2007-04-03 16:47   ` Mark Lord
2007-04-03 19:17     ` Phillip Susi
2007-04-04 15:36       ` Mark Lord
2007-04-05 15:30         ` Phillip Susi
2007-04-05 16:11           ` Mark Lord
2007-04-05 16:45             ` Lennart Sorensen
2007-04-09 14:46             ` Phillip Susi
2007-04-10  3:58               ` Mark Lord [this message]
  -- strict thread matches above, loose matches on Subject: below --
2007-04-05 16:26 Paa Paa

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=461B0B7F.1030802@rtr.ca \
    --to=lkml@rtr.ca \
    --cc=csnook@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=paapaa125@hotmail.com \
    --cc=psusi@cfl.rr.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox