All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Keld Jørn Simonsen" <keld@dkuug.dk>
To: David Lethe <david@santools.com>
Cc: linux-raid@vger.kernel.org
Subject: Re: new bottleneck section in wiki
Date: Wed, 2 Jul 2008 20:26:27 +0200	[thread overview]
Message-ID: <20080702182627.GA12614@rap.rap.dk> (raw)
In-Reply-To: <A20315AE59B5C34585629E258D76A97CF1FDB5@34093-C3-EVS3.exchange.rackspace.com>

On Wed, Jul 02, 2008 at 01:08:04PM -0500, David Lethe wrote:
> 
> 
> And also the disk controllers, could these be bottlenecks? They typically
> operate at 300 MB/s nominally, per disk channel, and presumably they
> then have a connection to the southbridge that is capable of handling
> this speed. So for a 4-disk SATA-II controller this would be at least
> 1200 MB/s or about 10 gigabit. 
> 
> best regards
> keld
> -------------------
> It is much more complicated than just saying what the transfer rates are, especially in the world of blocking, arbitration, and unbalanced I/O.  

Yes, that is understood, but I am only listing some potential
bottlenecs, of cause there may be more.

> Everything is a potential bottleneck.  As I am under NDA with most of the controller vendors, then I can not provide specifics, but suffice to say that certain cards with certain chipsets will max out at well under published speeds.  Heck, you could attach solid-state disks with random I/O access time in the nanosecond range and still only get 150MB/sec out of certain controllers, even on a PCIe X 16 bus. 
> 
> BTW, there isn't a SATA-II controller in the planet that will deliver 1200 MB/sec with 4 disk drives. 

Yes, but I think this is normally due to that the max transfer speed per
disk is in the ballpark of 80-120 MB/s - which is less than half the
SATA-II max speed. And I think much of this slowdown comes from head movement,
track-to-track, disk latency etc. I was of the impression, that when the
transfer between the disk and the controller is going on, then the
transfer speed would be not far from the 300 MB/s max speed, eg for
90 MB/s 1 TB disks that I bougth recently, or the faster 15000 RPM
disks, which give something like 120 MB/s.

best regards
keld

  reply	other threads:[~2008-07-02 18:26 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-07-02 15:56 new bottleneck section in wiki Keld Jørn Simonsen
2008-07-02 16:43 ` Justin Piszcz
2008-07-02 17:21   ` Keld Jørn Simonsen
2008-07-02 17:04 ` David Lethe
2008-07-02 17:51   ` Keld Jørn Simonsen
2008-07-02 18:08     ` David Lethe
2008-07-02 18:26       ` Keld Jørn Simonsen [this message]
2008-07-02 21:55         ` Roger Heflin
2008-07-02 19:45       ` Matt Garman
2008-07-02 20:05         ` Keld J?rn Simonsen
2008-07-02 20:24         ` Richard Scobie
2008-07-02 19:03   ` Matt Garman
2008-07-02 19:10     ` Jon Nelson
2008-07-02 19:35       ` Keld J?rn Simonsen
2008-07-02 19:38         ` Jon Nelson
2008-07-02 22:07           ` David Lethe
2008-07-03 12:28             ` Jon Nelson
2008-07-03 14:00               ` Justin Piszcz
2008-07-02 19:17     ` Robin Hill
2008-07-02 19:39     ` Keld J?rn Simonsen
2008-07-03  5:10     ` Doug Ledford
2008-07-02 21:45   ` Roger Heflin
2008-07-02 17:33 ` Iustin Pop
2008-07-02 18:14   ` Keld Jørn Simonsen

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=20080702182627.GA12614@rap.rap.dk \
    --to=keld@dkuug.dk \
    --cc=david@santools.com \
    --cc=linux-raid@vger.kernel.org \
    /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.