[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [linux-lvm] Apparent performance degradation for each PV with striping



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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]