From: Mark Lord <lkml@rtr.ca>
To: Carlo Wood <carlo@alinoe.com>,
Justin Piszcz <jpiszcz@lucidpixels.com>,
Michael Tokarev <mjt@tls.msk.ru>,
"Dr. David Alan Gilbert" <linux@treblig.org>,
Jeff Garzik <jeff@garzik.org>, Tejun Heo <htejun@gmail.com>,
Manoj Kasichainula <manoj@io.com>,
linux-kernel@vger.kernel.org,
IDE/ATA development list <linux-ide@vger.kernel.org>
Subject: Re: SATA RAID5 speed drop of 100 MB/s
Date: Sun, 24 Jun 2007 19:46:58 -0400 [thread overview]
Message-ID: <467F0272.9070903@rtr.ca> (raw)
In-Reply-To: <20070624220723.GA21724@alinoe.com>
Carlo Wood wrote:
>
> The following can be observed:
>
> 1) There is hardly any difference between the two schedulers (noop
> is a little faster for the bonny test).
> 2) An NCQ depth of 1 is WAY faster on RAID5 (bonnie; around 125 MB/s),
> the NCQ depth of 2 is by far the slowest for the RAID5 (bonnie;
> around 40 MB/s). NCQ depths of 3 and higher show no difference,
> but are also slow (bonnie; around 75 MB/s).
> 3) There is no significant influence of the NCQ depth for non-RAID,
> either the /dev/sda (hdparm -t) or /dev/sdd disk (hdparm -t and
> bonnie).
> 4) With a NCQ depth > 1, the hdparm -t measurement of /dev/md7 is
> VERY unstable. Sometimes it gives the maximum (around 150 MB/s),
> and sometimes as low as 30 MB/s, seemingly independent of the
> NCQ depth. Note that those measurement were done on an otherwise
> unloaded machine in single user mode; and the measurements were
> all done one after an other. The strong fluctuation of the hdparm
> results for the RAID device (while the underlaying devices do not
> show this behaviour) are unexplainable.
>
>>From the above I conclude that something must be wrong with the
> software RAID implementation - and not just with the harddisks, imho.
> At least, that's what it looks like to me. I am not an expert though ;)
I'm late tuning in here, but:
(1) hdparm issues only a single read at a time, so NCQ won't help it.
(2) WD Raptor drives automatically turn off "read-ahead" when using NCQ,
which totally kills any throughput measurements. They do this to speed
up random access seeks; dunno if it pays off or not. Under Windows,
the disk drivers don't use NCQ when performing large I/O operations,
which avoids the performance loss.
(3) Other drives from other brands may have similar issues,
but I have not run into it on them yet.
Cheers
next prev parent reply other threads:[~2007-06-24 23:47 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-06-20 22:48 SATA Harddisk speed drop of 100 MB/s Carlo Wood
2007-06-20 23:06 ` Jeff Garzik
2007-06-21 3:36 ` Arjan van de Ven
2007-06-22 16:21 ` Carlo Wood
2007-06-22 21:17 ` Henrique de Moraes Holschuh
2007-06-22 21:27 ` Carlo Wood
2007-06-23 1:31 ` Henrique de Moraes Holschuh
2007-06-23 2:59 ` Carlo Wood
2007-06-23 17:29 ` Andrew Morton
2007-06-23 22:21 ` Jeff Garzik
2007-06-25 15:18 ` Lennart Sorensen
2007-06-25 16:04 ` Carlo Wood
2007-06-22 21:44 ` SATA RAID5 " Carlo Wood
2007-06-23 3:54 ` Carlo Wood
2007-06-23 6:22 ` Tejun Heo
2007-06-22 21:48 ` Carlo Wood
2007-06-23 7:03 ` Jeff Garzik
2007-06-23 7:54 ` Tejun Heo
2007-06-23 12:53 ` Carlo Wood
2007-06-23 17:30 ` Bartlomiej Zolnierkiewicz
2007-06-23 22:43 ` Jeff Garzik
2007-06-24 11:58 ` Michael Tokarev
2007-06-24 12:59 ` Dr. David Alan Gilbert
2007-06-24 14:21 ` Justin Piszcz
2007-06-24 15:52 ` Michael Tokarev
2007-06-24 16:59 ` Justin Piszcz
2007-06-24 22:07 ` Carlo Wood
2007-06-24 23:46 ` Mark Lord [this message]
2007-06-25 0:23 ` Patrick Mau
2007-06-24 15:48 ` Michael Tokarev
2007-07-05 22:12 ` Phillip Susi
2007-06-24 0:54 ` Eyal Lebedinsky
-- strict thread matches above, loose matches on Subject: below --
2007-06-24 9:01 Mikael Pettersson
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=467F0272.9070903@rtr.ca \
--to=lkml@rtr.ca \
--cc=carlo@alinoe.com \
--cc=htejun@gmail.com \
--cc=jeff@garzik.org \
--cc=jpiszcz@lucidpixels.com \
--cc=linux-ide@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@treblig.org \
--cc=manoj@io.com \
--cc=mjt@tls.msk.ru \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.