linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Carlo Wood <carlo@alinoe.com>
To: Justin Piszcz <jpiszcz@lucidpixels.com>
Cc: 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: Mon, 25 Jun 2007 00:07:23 +0200	[thread overview]
Message-ID: <20070624220723.GA21724@alinoe.com> (raw)
In-Reply-To: <Pine.LNX.4.64.0706241257190.12207@p34.internal.lan>

On Sun, Jun 24, 2007 at 12:59:10PM -0400, Justin Piszcz wrote:
> Concerning NCQ/no NCQ, without NCQ I get an additional 15-50MB/s in speed 
> per various bonnie++ tests.

There is more going on than a bad NCQ implementation of the drive imho.
I did a long test over night (and still only got two schedulers done,
will do the other two tomorrow), and the difference between a queue depth
of 1 and 2 is DRAMATIC.

See http://www.xs4all.nl/~carlo17/noop_queue_depth.png
and http://www.xs4all.nl/~carlo17/anticipatory_queue_depth.png

The bonnie++ tests are done in a directory on the /dev/md7 and
/dev/ssd2 partitions respectively. Each bonnie test is performed
four times.

The hdparm -t tests (that show no difference with a -tT test) are
each done five times, for /dev/sdd, /dev/md7 and /dev/sda (that is
one of the RAID5 drives used for /dev/md7).

Thus in total there are 2 * 4 + 3 * 5 = 23 data points per
queue depth value in each graph.

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 ;)

-- 
Carlo Wood <carlo@alinoe.com>

PS RAID5 (md7 = sda7 + sdb7 + sdc7): Three times a Western Digital
   Raptor 10k rpm (WDC WD740ADFD-00NLR1).
   non-RAID (sdd2): Seagate barracuda 7200 rpm (ST3320620AS).

   The reason that now I measure around 145 MB/s instead of 165 MB/s
   as reported in previous post (with hdparm -t /dev/md7) is because
   before I use hdparm -t /dev/md2, which is closer to the outside
   of the disk and therefore faster. /dev/md2 still is around 165 MB/s.


  reply	other threads:[~2007-06-24 22:07 UTC|newest]

Thread overview: 31+ 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 [this message]
2007-06-24 23:46                       ` Mark Lord
2007-06-25  0:23                       ` Patrick Mau
2007-06-24 15:48               ` Michael Tokarev
2007-07-05 22:12             ` Phillip Susi

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=20070624220723.GA21724@alinoe.com \
    --to=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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).