public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andre Tomt <andre@tomt.net>
To: "Matt M. Valites" <mval@axium.net>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Poor  I/O Performance with MegaRaid SATA 150-4; bug or feature?
Date: Sun, 17 Apr 2005 00:57:32 +0200	[thread overview]
Message-ID: <4261985C.5030008@tomt.net> (raw)
In-Reply-To: <42614CAF.50606@axium.net>

Matt M. Valites wrote:
> Hail List,
> 
> I've been banging my head against this for a few days, and I wanted to
> see if anyone here could lend a hand.
> 
> I have the following configuration:
> P4 3.x Ghz
> 2GB Ram;
> 2 x 36GB WD Raptors; in a RAID1 (sda)
> 2 x 74GB WD Raptor (those 10K RPM SATA drives) in a RAID1(sdb)
> Two free PCI-X slots, one of which occupied by a LSI MegaRaid SATA 150-4.
> 
> The problem is I/O on either one of these RAID devices seems to
> be less than half what I'm expecting.   The file system used in my testing is
> XFS, and I'm running kernel 2.6.11.6.
> 
> The test I'm doing is a simple:
> # time dd if=/dev/zero of=./crap.file bs=1024 count=209715
> Which results in a runtime of about ~53s, in the best case, with all the
> scary write cache enabled.    I've tried with deadline, and
> anticipatory.  I've also tried several kernels, namely a recent 2.4, so
> I could test megaraid and megaraid2, similar results.
> 
> On my desktop box, with one of these drives connected via SATA, i get
> ~25s, also XFS.  (2.6.11-gentoo-r6 x86_64).
> 
> Is this an expected result?  I'm seeing much higher numbers posted around the
> 'Net.  Most of those results are from Windows boxes.
> 
> I've uploaded my kernel config, lspci -v, and two opreports of a bonnie++ run
> to: http://www.muixa.com/lkml/

I also have one of those cards, at home. I've come to the conclusion 
that they're just too old. No NCQ and such other fancy features (for 
gods sake, the controllers on the card are sil 3112's!). It's probably 
not even PCI-X native.

The only thing that can bring its performance reseanably up to speed is 
using write-back instead of write-through on the array. Also try 
enabling the write-cache on the drives (all doable in the cards bios 
config, not sure if this is what you meant with "with all the scary 
write cache enabled"). Doing this is on the other hand not very good for 
your data integrity, not good at all.

If only NCQ/TCQ was in, it would have a chance of having decent 
performance using write-through. A cool experiment would be setting up 
the drives as invidual drives on the card, and use md software raid over it.

Next time I'll probably just use md software raid over a 3ware 9xxx 
(JBOD-mode) or AHCI controller. I'm feeling quite uneasy about vendor 
lock in nowadays. Groan.

-- 
Cheers,
André Tomt

  reply	other threads:[~2005-04-16 22:57 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-04-16 17:34 Poor I/O Performance with MegaRaid SATA 150-4; bug or feature? Matt M. Valites
2005-04-16 22:57 ` Andre Tomt [this message]
2005-04-17 15:53   ` Matt M. Valites

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=4261985C.5030008@tomt.net \
    --to=andre@tomt.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mval@axium.net \
    /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