Re: 3Ware 9x00 controllers

Hi,


On Thu, Oct 28, 2004 at 10:41:16AM +0200, Remco Barendse wrote:
> On Thu, 28 Oct 2004, Pasi Pirhonen wrote:
> 
> >
> >As i said, it's reverseable (thank god) by just booting the previous
> >version of the driver. That just flashes the previous version of
> >firmware back in while loading.
> 
> OK :)  Hopefully the 3w-9xxx driver will still be included in u3, guess it 
> will be the old version then?

Which U3 you're talking about? i386 or others? I've said that U3 for
i386 is out of my reach and i don't make any decicions about what is in
that or what is not in that.

The x86-64, ia64 (not tested the ia64 tho) does have this 902-bundle
level driver included on the kernel in ISO-images.

I made a new kernel (and tested that under x86-86) with the new driver
included as addon/3w-9xxx_9151. The new driver supposed to include
support for BBU (Battery Backup Unit). I don't have this (i don't think
many people have it as it's just becoming available). IF you choose to
use the new driver, you NEED the updated tw_cli too to be able to make
queries. The new tw_cli works for the old driver too. I don't currenly
use the 3dm myself, so i don't know about that.


I made a local kernel repo same time. This is located at 

http://core.upi.iki.fi/out/kernel/

and is yum enabled. It's behind my ADSL, so it does have only 50kB/s
bandwith. There are i386 and x86-64 kernel for 

kernel-2.4.21-20.3.EC.src.rpm (my U3-level)
kernel-2.4.21-20.4.EC.src.rpm (includes the 3w-9xxx_9151.o)

So if someone just updates, the old driver is used automatically.
One needs to put something like

alias scsi_hostadapter3 3w-9xxx_9151

to /etc/modules.conf and re-run mkinird to use the new driver.

Another things is that i used to limit the cmds_per_lun by driver
patch. The latest  version doesn't have the limit anymore, so if one
wants to reduce the enormous TCQ, one put something like

options 3w-9xxx cmds_per_lun=8

to /etc/modules.conf and re-run the mkinitd (again :).

Other mods are that the 2.4.21-20.4.EC does have the quota and realtime
extensions for XFS enabled. I am pretty sure (have been testing the
basic XFS _a lot) that the XFS itself is alright. If there are
problems, it's due the quota or realtime (one piece at time).

Another thing is that the NAPI for sk98lin_707 is disabled. At lest for
me (Athlon64) it caused anormous amounts of unneeded IRQs, so i
disabled it for now.

Othe goodies, like forcedeth+gigabit, GFS and few other small kernel
fixes (one of them is already included in upcoming U4-beta kernel) are
there as before.



> 
> 
> 
> I have an old PATA 3Ware 7850 with 5 drives attached to it (the card is in 
> a 32 bit 33 mhz pci slot) which gets to the max of the pci bus (just over 
> 100 mb/sec). I am using hardware raid 5 on it. Recently performance 
> dropped dramatically though, I suspect this is caused by adding a large 
> number of small files to the array or a faulty drive.

So you get mere millibits/sec? You better keep the MB/s as MB/s or i
might really misunderstans something some day.

I do get prox. 100MB/s for ia32 with 8 disks. This setups is x86-64 and
5 disks. 

but in the end all is about latencies and how much CPU you use to get
that 100MB/s. I haven't paid much attention to these numbers yet.


> 
> 
> >>
> >>If the box boots after install I'll post some benchmarks of my array with
> >>4 raptors.
> >>
> >
> >that should not make the sequential writes any faster as the fabric
> >itself seems to be saturating at about 100MB/s (i think that is
> >supposed to be the write speed for 9500-seris).
> >
> >Raptors being 10k drives maybe affect for random access patterns tho.
> >

And how did that go?


-- 
Pasi Pirhonen - [email protected] - http://iki.fi/upi/