From: "Ragnar Kjørstad" <lvm@ragnark.vestdata.no>
To: linux-lvm@sistina.com
Cc: Steven Lembark <lembark@wrkhors.com>
Subject: Re: [linux-lvm] Apparent performance degradation for each PV with striping
Date: Thu, 22 Mar 2001 10:53:44 +0100 [thread overview]
Message-ID: <20010322105344.C11762@vestdata.no> (raw)
In-Reply-To: <0103220954110L.00851@lyta>; from Russell Coker on Thu, Mar 22, 2001 at 09:54:11AM +0100
On Thu, Mar 22, 2001 at 09:54:11AM +0100, Russell Coker wrote:
> On Monday 19 March 2001 14:44, Steven Lembark wrote:
> > Escalade is a nice idea, but still runs afoul of the interrupt
> > & bus design of PC's. for high-i/o applications "PC" hardware
> > doesn't work all that well. main problem here is delivering the
> > raw datat to an Esc. controller through the existing PC. the
> > add'l cpu load in this case comes from the bottom-half of drivers
> > on heavily loaded cards that spend too much time waiting for
> > access to the shared card.
> >
> > these are a distinct improvement over stock IDE or software RAID
> > but don't expect them to suddenly turn your PC into a SparcServer
> > or K400.
>
> What is a K400?
>
> Every test that I run shows SPARC machines running slower than desktop
> machines with IA32 CPUs. My Athlon-800 machine has more memory bandwidth
> than an E450 according to the industry standard "streams" benchmark and
> according to a little memory benchmark I wrote. Also a single IBM 46G ATA
> drive in my Athlon outperforms A1000 arrays in E450 class hardware.
I second this.
Every test we've run show that x86 linux boxes kick sparc but. :-)
x86 with scsi-scsi RAID controllers we se performance 5-6 times that of
E450s with A1000 RAID. Linux has a reputation for not matching other
systems on NFS performance, but our tests show x86 linux beeing faster than
both x86 freeBSD and SPARC Solaris (both client and server-side)
However: the escalade RAID-controller doesn't have any write-back cache,
does it? So performance actually be worse than on single disk systems
(in some situations - see thread on reiserfs-list), and won't even
compare to a real scsi-scsi or fc-scsi RAID-system.
Anyway - we're getting off-topic awfully fast here; please send
followups directly pr mail and remove lvm-list.
--
Ragnar Kj�rstad
Big Storage
next prev parent reply other threads:[~2001-03-22 9:53 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-03-19 13:34 [linux-lvm] Apparent performance degradation for each PV with striping S. Michael Denton
2001-03-19 13:44 ` Steven Lembark
2001-03-22 8:54 ` Russell Coker
2001-03-22 9:53 ` Ragnar Kjørstad [this message]
2001-03-22 12:19 ` zoo1
2001-03-22 8:58 ` Russell Coker
-- strict thread matches above, loose matches on Subject: below --
2001-03-19 5:11 Donald Thompson
2001-03-19 5:20 ` Eric M. Hopper
2001-03-22 8:55 ` Russell Coker
2001-03-19 6:03 ` lvm
2001-03-19 7:05 ` Donald Thompson
2001-03-19 9:15 ` Joe Thornber
2001-03-19 7:06 ` Jason Walker
2001-03-19 8:48 ` Oleg Volkov
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=20010322105344.C11762@vestdata.no \
--to=lvm@ragnark.vestdata.no \
--cc=lembark@wrkhors.com \
--cc=linux-lvm@sistina.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.