From: Keld J?rn Simonsen <keld@dkuug.dk>
To: Matt Garman <matthew.garman@gmail.com>
Cc: David Lethe <david@santools.com>, linux-raid@vger.kernel.org
Subject: Re: new bottleneck section in wiki
Date: Wed, 2 Jul 2008 22:05:33 +0200 [thread overview]
Message-ID: <20080702200533.GA13464@rap.rap.dk> (raw)
In-Reply-To: <20080702194546.GB2311@sewage.raw-sewage.fake>
On Wed, Jul 02, 2008 at 02:45:46PM -0500, Matt Garman wrote:
> On Wed, Jul 02, 2008 at 01:08:04PM -0500, David Lethe wrote:
> > 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.
>
> Short of signing an NDA, how would one go about determining which
> chipsets are least likely to be a bottleneck? I'm interested in
> building an NFS server with a Linux software RAID-5 data store. To
> me, that means my I/O subsystem should be as fast and capable as
> possible.
>
> For example, looking at the block diagram [1] of Intel's P45/ICH10
> chipset [2], it appears that the link between the north and south
> bridges is only 2 GB/s. I would think that any raid level that
> requires the CPU (e.g. parity calculations) would clog that link
> fairly quickly, at least if large block transfers are taking place.
> And then I wonder what impact that has on the performance of the
> NIC(s) (I don't know how much a NIC has to talk to the CPU).
2 GB/s seems adequate. Not many raids are in this class. Theoretically
you would need something like more than 20 disks to get this bandwidth,
and normally you only have 4 to 8 disks attachable to IO controllers on
the mobo.
Parity calculations are done by the cpu on the ram, and should not touch
the northbridge - southbridge internal bus in vanilla motherboards.
best regards
keld
next prev parent reply other threads:[~2008-07-02 20:05 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
2008-07-02 21:55 ` Roger Heflin
2008-07-02 19:45 ` Matt Garman
2008-07-02 20:05 ` Keld J?rn Simonsen [this message]
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=20080702200533.GA13464@rap.rap.dk \
--to=keld@dkuug.dk \
--cc=david@santools.com \
--cc=linux-raid@vger.kernel.org \
--cc=matthew.garman@gmail.com \
/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.