From: Jens Axboe <axboe@suse.de>
To: Greg Stark <gsstark@mit.edu>
Cc: "Eric D. Mudama" <edmudama@gmail.com>,
Matthias Andree <matthias.andree@gmx.de>,
linux-kernel@vger.kernel.org, jgarzik@pobox.com
Subject: Re: [PATCH] SATA NCQ support
Date: Mon, 30 May 2005 16:51:51 +0200 [thread overview]
Message-ID: <20050530145151.GU7054@suse.de> (raw)
In-Reply-To: <20050530123706.GR7054@suse.de>
On Mon, May 30 2005, Jens Axboe wrote:
> On Mon, May 30 2005, Jens Axboe wrote:
> > On Mon, May 30 2005, Jens Axboe wrote:
> > > > People actually tend to report that IDE drives are *faster*. Until
> > > > they're told they have to disable write-caching on their IDE drives to
> > > > get a fair comparison, then the performance is absolutely abysmal. The
> > > > interesting thing is that SCSI drives don't seem to take much of a
> > > > performance hit from having write-caching disabled while IDE drives
> > > > do.
> > >
> > > NCQ will surely lessen the impact of disabling write caching, how much
> > > still remains to be seen. You could test, if you have the hardware :)
> > > Real life testing is more interesting than benchmarks.
> >
> > With a few simple tests, I'm unable to show any write performance
> > improvement with write back caching off and NCQ (NCQ with queueing depth
> > of 1 and 16 tested). I get a steady 0.55-0.57MiB/sec with 8 threads
> > random writes, a little over 5MiB/sec with sequential writes.
> >
> > Reads are _much_ nicer. Sequential read with 8 threads are 23% faster
> > with a queueing depth of 16 than 1, random reads are 85% (!!) faster at
> > depth 16 than 1.
> >
> > Testing was done with the noop io scheduler this time, to only show NCQ
> > benefits outside of what the io scheduler can do for reordering.
> >
> > This is with a Maxtor 7B300S0 drive. I would have posted results for a
> > Seagate ST3120827AS as well, but that drive happily ignores any attempt
> > to turn off write back caching. To top things off, it even accepts FUA
> > writes but ignores that as well (they still go to cache).
>
> Actually, I partly take that back. The Seagate _does_ honor drive write
> back caching disable and it does show a nice improvement with NCQ for
> that case. Results are as follows:
>
> 8 thread io case, 4kb block size, noop io scheduler, ST3120827AS.
>
> Write cache off:
>
> Depth 1 Depth 30 Diff
> Seq read: 18.94 21.51 + 14%
> Ran read: 0.86 1.24 + 44%
> Seq write: 6.58 19.30 + 193%
> Ran write: 1.00 1.27 + 27%
>
> Write cache on:
>
> Depth 1 Depth 30 Diff
> Seq read: 18.78 21.58 + 15%
> Ran read: 0.84 1.20 + 43%
> Seq write: 24.49 23.26 - 5%
> Ran write: 1.55 1.63 + 5%
>
> Huge benefit on writes with NCQ when write back caching is off, with it
> on I think the deviation is within standard jitter of this benchmark.
The Maxtor drive shipped with write back caching off, I actually knew
and forgot that... So that of course changes the picture, same test as
the Seagate above run on the Maxtor:
Write cache off:
Depth 1 Depth 30 Diff
Seq read: 19.83 22.46 + 13%
Ran read: 0.73 1.33 + 82%
Seq write: 10.51 5.65 - 47%
Ran write: 0.55 0.56 + 1%
Write cache on:
Depth 1 Depth 30 Diff
Seq read: 19.83 34.35 + 73%
Ran read: 0.86 1.54 + 79%
Seq write: 25.82 35.21 + 36%
Ran write: 3.12 3.27 + 5%
Still something fishy going on. Eric, this is with both B0 and BM
firmware on these drives, any known bugs there?
--
Jens Axboe
next prev parent reply other threads:[~2005-05-30 14:53 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-05-27 7:03 [PATCH] SATA NCQ support Jens Axboe
2005-05-27 7:22 ` Jeff Garzik
2005-05-27 7:30 ` Jens Axboe
2005-05-27 7:37 ` Jeff Garzik
2005-05-27 7:47 ` Jens Axboe
2005-05-27 7:56 ` Jens Axboe
2005-05-27 8:24 ` Jeff Garzik
2005-05-27 8:27 ` Jeff Garzik
2005-05-27 8:28 ` Jeff Garzik
2005-05-27 8:35 ` Jens Axboe
2005-05-27 8:38 ` Jeff Garzik
2005-05-27 8:42 ` Jens Axboe
2005-05-27 23:47 ` Jeff Garzik
2005-05-27 13:18 ` Matthias Andree
2005-05-27 13:53 ` Jens Axboe
2005-05-27 14:46 ` Matthias Andree
2005-05-27 14:58 ` Jens Axboe
2005-05-29 13:16 ` Matthias Andree
2005-05-29 16:36 ` Jeff Garzik
2005-05-30 2:35 ` Eric D. Mudama
2005-05-30 3:41 ` Greg Stark
2005-05-30 4:04 ` Eric D. Mudama
2005-05-30 6:21 ` Greg Stark
2005-05-30 6:33 ` Jens Axboe
2005-05-30 12:16 ` Jens Axboe
2005-05-30 12:37 ` Jens Axboe
2005-05-30 14:51 ` Jens Axboe [this message]
2005-05-27 16:00 ` Jeff Garzik
[not found] <48Hix-88s-7@gated-at.bofh.it>
[not found] ` <48N4N-4B5-25@gated-at.bofh.it>
[not found] ` <48Pzt-6Kb-5@gated-at.bofh.it>
2005-05-31 0:00 ` Robert Hancock
2005-05-31 1:21 ` Jeff Garzik
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=20050530145151.GU7054@suse.de \
--to=axboe@suse.de \
--cc=edmudama@gmail.com \
--cc=gsstark@mit.edu \
--cc=jgarzik@pobox.com \
--cc=linux-kernel@vger.kernel.org \
--cc=matthias.andree@gmx.de \
/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