From: Roger Heflin <rogerheflin@gmail.com>
To: Matt Garman <matthew.garman@gmail.com>
Cc: Justin Piszcz <jpiszcz@lucidpixels.com>, linux-raid@vger.kernel.org
Subject: Re: southbridge/sata controller performance?
Date: Sun, 04 Jan 2009 15:02:37 -0600 [thread overview]
Message-ID: <496123ED.5050809@gmail.com> (raw)
In-Reply-To: <20090104194023.GB10174@sewage.raw-sewage.fake>
Matt Garman wrote:
>
> Are you talking about using additional SATA controllers (i.e. via
> add-on cards)? Or simply talking about the interconnect between the
> southbridge and the northbridge?
>
Don't count on it, it depends on the specific setup of the MB.
> I think you're talking about the former, i.e. the SATA controller
> integrated in the southbridge generally ought to be fine, but if you
> start adding additional controllers that hang off the south bridge,
> their could be competition for bandwidth to the northbridge...
> right? (And wouldn't the nvidia chips have an edge here, since they
> have everything combined into one chip?)
Again, it depends on how much bandwidth was allocated internally in
the chip just because it is one chip does not mean that anyone
actually allocated enough resources to the given part of the chip, or
even has enough feed to the chip to support them all. The Seagate
1.5's will stream quite a bit higher numbers than previous disks, so
if one had several of them they could overload the allocated
bandwidth. Things build-into a given MB aren't always connected at
full speed often some of them are actually pci bus parts and suffer
from slow access, I would expect there to be similar tradeoffs even in
single chip cases.
>
> Makes intuitive sense anyway; but in my case I'm really just curious
> about the SATA controller integrated into the southbridge; not
> concerned with additional SATA controllers.
>
The build-in intel ich series controllers vary from version to version
on exactly how fast that they are in this test, the newer ones are
faster than the older ones.
>
> Is the "parallel dd test" valid if I do a raw read off the device,
> e.g. "dd if=/dev/sda of=/dev/null"? All my drives are already in an
> md array, so I can't access them individually at the filesystem
> level.
>
> Thanks for the feedback and info!
>
> Matt
>
>
Yes, that is valid, so long as the md device is fairly quiet at the
time of the test. Since you already have a machine, please post the
mb type, and number/type of sata ports and the 1-disk, 2-disk,
3-disk,... numbers that you get.
I am looking at getting a new AMD solution in the next month or so and
would like also know which scales reasonably.
next prev parent reply other threads:[~2009-01-04 21:02 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-01-03 19:34 southbridge/sata controller performance? Matt Garman
2009-01-03 20:11 ` Roger Heflin
2009-01-04 9:55 ` Justin Piszcz
2009-01-04 19:40 ` Matt Garman
2009-01-04 21:02 ` Roger Heflin [this message]
2009-01-04 21:34 ` Justin Piszcz
2009-01-05 3:27 ` Matt Garman
2009-01-05 7:08 ` Keld Jørn Simonsen
2009-01-05 14:21 ` Matt Garman
2009-01-05 16:11 ` Keld J?rn Simonsen
2009-01-13 20:28 ` Matt Garman
2009-01-14 22:34 ` Bill Davidsen
2009-01-04 21:32 ` Justin Piszcz
2009-01-05 0:27 ` 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=496123ED.5050809@gmail.com \
--to=rogerheflin@gmail.com \
--cc=jpiszcz@lucidpixels.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 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).