All of lore.kernel.org
 help / color / mirror / Atom feed
From: Learner Study <learner.study@gmail.com>
To: MRK <mrk@shiftmail.org>
Cc: Richard Scobie <richard@sauce.co.nz>,
	Mark Knecht <markknecht@gmail.com>,
	linux-raid@vger.kernel.org, keld@dkuug.dk,
	learner.study@gmail.com
Subject: Re: Linux Raid performance
Date: Sun, 4 Apr 2010 11:26:44 -0700	[thread overview]
Message-ID: <w2j7efa8a7d1004041126id2b84d47k7bd275606712d0e3@mail.gmail.com> (raw)
In-Reply-To: <4BB8A979.3020502@shiftmail.org>

Happy Easter!!!

So, 550-600MB/s is the best we have seen with Linux raid using 16-24 SAS drives.

Not sure if its appropriate to ask on this list - has someone seen
better numbers with non-linux raid stack? Perhaps freebsd/lustre..

Thanks for your time!

On Sun, Apr 4, 2010 at 8:00 AM, MRK <mrk@shiftmail.org> wrote:
> Richard Scobie wrote:
>>
>> MRK wrote:
>>
>>> I spent some time trying to optimize it but that was the best I could
>>> get. Anyway both my benchmark and Richard's one imply a very significant
>>> bottleneck somehwere.
>>
>> This bottleneck is the SAS controller, at least in my case. I did the same
>> math regarding streaming performance of one drive times number of drive and
>> wondered where the shortfall was, after tests showed I could only streaming
>> read at 850MB/s on the same array.
>>
>> A query to an LSI engineer got the following response, which basically
>> boils down to "you get what you pay for" - SAS vs SATA drives.
>>
>> "Yes, you're at the "practical" limit.
>>
>> With that setup and SAS disks, you will exceed 1200 MB/s.  Could go
>> higher than 1,400 MB/s given the right server chipset.
>>
>> However with SATA disks, and the way they break up data transfers, 815
>> to 850 MB/s is the best you can do.
>>
>> Under SATA, there are multiple connections per I/O request.
>>  * Command Initiator -> HDD
>>  * DMA Setup  Initiator -> HDD
>>  * DMA Activate  HDD -> Initiator
>>  * Data   HDD -> Initiator
>>  * Status    HDD -> Initiator
>> And there is little ability with typical SATA disks to combine traffic
>> from different I/Os on the same connection.  So you get lots of
>> individual connections being made, used, & broken.
>>
>> Contrast that with SAS which has typically 2 connections per I/O, and
>> will combine traffic from more than 1 I/O per connection.  It uses the
>> SAS links much more efficiently."
>
> Firstly: Happy Easter!  :-)
>
> Secondly:
>
> If this is true then one won't achieve higher speeds even on RAID-0. If
> anybody can test this... I cannot right now
>
> I am a bit surprised though. The SATA "link" is one per drive, so if 1 drive
> is able to do 90MB/sec, N drives on N cables should do Nx90MB/sec.
> If this is not so, then the chipset of the controller must be the
> bottleneck.
> If this is so, the newer LSI controllers at 6.0gbit/sec could be able to do
> better (they supposedly have a faster chip). Also maybe one could buy more
> controller cards and divide drives among those. These two workarounds would
> still be cheaper than SAS drives.
>
>
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

  reply	other threads:[~2010-04-04 18:26 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-03-31 19:42 Linux Raid performance Learner Study
2010-03-31 20:15 ` Keld Simonsen
2010-04-02  3:07   ` Learner Study
2010-04-02  9:58     ` Nicolae Mihalache
2010-04-02 17:58       ` Learner Study
2010-04-02 11:05     ` Keld Simonsen
2010-04-02 11:18       ` Keld Simonsen
2010-04-02 17:55       ` Learner Study
2010-04-02 21:14         ` Keld Simonsen
2010-04-02 21:37           ` Learner Study
2010-04-03 11:20             ` Keld Simonsen
2010-04-03 15:56               ` Learner Study
2010-04-04  1:58                 ` Keld Simonsen
2010-04-03  0:10           ` Learner Study
2010-04-03  0:39         ` Mark Knecht
2010-04-03  1:00           ` John Robinson
2010-04-03  1:14           ` Richard Scobie
2010-04-03  1:32             ` Mark Knecht
2010-04-03  1:37               ` Richard Scobie
2010-04-03  3:06                 ` Learner Study
2010-04-03  3:00             ` Learner Study
2010-04-03 19:27               ` Richard Scobie
2010-04-03 18:14             ` MRK
2010-04-03 19:56               ` Richard Scobie
2010-04-04 15:00                 ` MRK
2010-04-04 18:26                   ` Learner Study [this message]
2010-04-04 18:46                     ` Mark Knecht
2010-04-04 21:28                       ` Jools Wills
2010-04-04 22:38                         ` Mark Knecht
2010-04-05 10:07                           ` Learner Study
2010-04-05 16:35                             ` John Robinson
2010-04-04 22:24                       ` Guy Watkins
2010-04-05 13:49                         ` Drew
2010-04-04 23:24                   ` Richard Scobie
2010-04-05 11:20                     ` MRK
2010-04-05 19:49                       ` Richard Scobie
2010-04-05 21:03                         ` Drew
2010-04-05 22:20                           ` Richard Scobie
2010-04-05 23:49                           ` Roger Heflin
2010-04-14 20:50             ` Bill Davidsen

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=w2j7efa8a7d1004041126id2b84d47k7bd275606712d0e3@mail.gmail.com \
    --to=learner.study@gmail.com \
    --cc=keld@dkuug.dk \
    --cc=linux-raid@vger.kernel.org \
    --cc=markknecht@gmail.com \
    --cc=mrk@shiftmail.org \
    --cc=richard@sauce.co.nz \
    /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.