All of lore.kernel.org
 help / color / mirror / Atom feed
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


  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 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.