Re: u3+ isos for testing

On Mon, 25 Oct 2004, Pasi Pirhonen wrote:

> Hi,
>
>
> On Mon, Oct 25, 2004 at 09:56:50AM -0400, David L. Parsley wrote:
>> On Mon, 2004-10-25 at 04:55, Pasi Pirhonen wrote:
>>> Hi,
>>>
>>
>> Ok, I didn't realize the 3w-xxxx driver wasn't what he needed.  I'm not
>> really opposed to adding new drivers that don't muck with core kernel
>> code.  If Pasi's patch applies cleanly for i386, I might add it.  Here's
>> the problem, tho: RH doesn't support this driver/hardware, so Pasi will
>> need to continue maintaining this patch untill RH (hopefully) adds it to
>> their kernel.
>
> I've actually received a 'gift' from 'happy customer' and i do have
> extra 9500S-8 to be able to maintain testing future updates for the
> support, so yes, i am committed to that.
>
> There is 'limit for command/LUN' and 'clustering patch' with the kernel
> included on my U3-images, but later on i've learnt that those aren't
> really needed. RedHat had somehow/for some reason made
> 'ENABLE_CLUSTERING' 0, so maybe the clustering patch should be there.
>
> Initially i thought it to be good for limiting the driver allocations
> etc. for queue with tampering the .h, but that is not actually making
> any good. The TCQ lenght (254) is too deep anyway, so using something
> like
>
> options 3w-9xxx cmds_per_lun=64
>
> in /etc/modules.conf would be in place. Actually my findings being that
> best for performance vs. responsivenes would be that included in patch
>
> options 3w-9xxx cmds_per_lun=8
>
> The ext3 problems i am seeing are not the drivers fault and i am pretty
> sure that it's those nasty lock_kernel() and it's other locking friends
> that are actually causing the random performance drop. It's still under
> investigation/debugging.

Interesting!! I kept on thinking about the performance problem and this 
morning I thought about this e-mail you wrote. If I understand correctly 
the performance problem is not really filesystem type related.

When I was buying my raptors I looked on several sites for comments about 
it. I remember seeing a comment somewhere that the Raptors *only support 
9 or 10 (don't know exactly) queued commands per drive.

Could this be the root of the problem? If the 3Ware fails to detect how 
many TCQ's a drive can handle and just assumes it's 25 or 64 for example 
when in reality the drive supports only 10 I can imagine that weird stuff 
happens when occasionally a lot of drive commands are queued.

Real scsi drives can handle much more queued commands maybe 3Ware did not 
anticipate for drives only supporting a limited number.

That would make it a driver problem after all.

Just a n00b's thought and thanks for your great analysis, very usefull.


If you look at the test on storagereview, their results confirm dropping 
performance when the number of outstanding IO's increases:
http://www.storagereview.com/articles/200406/20040625TCQ_2.html

This document on the WD website states that the drive should support up to 
32 commands:
http://www.wdc.com/en/library/sata/2579-001076.pdf

On the other hand from the 3Ware website (I hope this is only true for 
the 8000 series controllers):
Q11476 - Software Configuration: Do 3ware SATA controllers support command 
queuing?  Modified: 05.May.04
Yes.  3ware SATA RAID controllers can queue up to 255 commands.  The 
command queuing takes place in the 3ware RAID controller.  3ware SATA RAID 
controllers do not support native command queuing, where the queuing takes 
place on the drives.


Maybe we should try some testing with TCQ disabled completely. Performance 
may not be top notch but it would be interesting to see if the performance 
drops disappears.



>
> I am anyway decided to go with my XFS patch for my NFS-server as the
> ext3 just can't compete with XFS.
>
> XFS being out of the David spcification as it's tapmering with the
> general code paths - even tho it's nothing major.
>
> There would be another patch too for those people using new shiny
> SATA+everything motherboards. sk98lin driver beig unsupported by
> redhat, it doesn't support Marvel/3c940 GBe either. I have patch to
> make that as 'sk98lin_707' and placed to drivers/addon. I just realized
> that enabling the NAPI caused my problems here, so i need at least
> update the kernel after we get the U3 out.
>
> Then there would be the forcedeth support (NForce3 integrated
> ethernet). which isn't tampering the general code patch either. Given
> that i only have NFforce3 150, i have only been able to test the
> 10/100Mbit/s version, but that patch should contain support for GBe. It
> has vorked flawesly for me.
>
>
>>
>> Pasi, have you tested your patch on ia32?
>>
>
> Yeap. I've tested that much more under ia32 than x86-64. Actually the
> card i'll use near future for my new home NFS-server, will be ia32. I
> have suitable box for it (== don't want to tie by x86-64 resources).
> dual-PIII with 3x66Mhz/64bit PCI will just hold the 3ware and GBe
> (which is pretty much what my NFS-box needs). There isn't much extra
> gain for using faster box as this is writing that 100MB/s with XFS. The
> very same i get for dual-opteron with all the fancy new dual-channel
> DDR and multiple PCI-X. The PIII cannot go for over 200MB/s for reads,
> but i am willing to loose 'that much' :P
>
>
> But you need the anaconda mods and hwdata too, if you're making thise
> 'just happens to load automagically thile installing' .....
>
>
>
>
>
>> David
>>
>>>  I then tho
>>> cannot speak for David, but the enhancements i've mentioned, are
>>> exclusive for x86-64, ia64, s390 and s390x (AFAIK) unless mentioned
>>> other way.
>>>
>>> I really don't know about the below mentined as i have not tested that
>>> myself. I run my own fork at home which does have all the mods and is
>>> my prototype release for future enhancements (which might or might not
>>> get merged to Tao Linux later on).
>>>
>>> My private fork is par for all arches (i386, x86-64, ia64, s390 and
>>> s390x), but i really cannot make any mods to the official Tao Linux/i386.
>>>
>>> The symptoms that 'loader tries to load 3w-xxxx for 3ware 9500-seris
>>> controller' is expected result. The hwdata does have it's PCIid
>>> mapped for 3w-xxxx (the 8x00-series and older controllers).
>>>
>>>
>>>
>>>>
>>>> Thanks!
>>>>
>>>> On Thu, 21 Oct 2004, David L. Parsley wrote:
>>>>
>>>>> Hi all,
>>>>>
>>>>> Ok, I've respun i386 isos, and put them in:
>>>>> ftp://dist.taolinux.org/pub/parsley-incoming/u3-isos
>>>>>
>>>>> Notes:
>>>>> - These include all updates through yesterday's updates
>>>>> - GFS is _NOT_ integrated, as it doesn't integrate smoothly w/o extra
>>>>> hacking
>>>>> - You can still 'yum install GFS GFS-modules[-smp]' to get GFS
>>>>>
>>>>> I've tried test installs, and all looks fine; when I have the time I'll
>>>>> move 'em to the mirrored location & update the website.  Untill then, any
>>>>> extra testing/feedback is welcome.
>>>>>
>>>>>
>>>> _______________________________________________
>>>> Tao-discuss mailing list
>>>> [email protected]
>>>> http://mailman.taolinux.org/mailman/listinfo/tao-discuss
>
>
>
>> _______________________________________________
>> Tao-discuss mailing list
>> [email protected]
>> http://mailman.taolinux.org/mailman/listinfo/tao-discuss
>
> --
> Pasi Pirhonen - [email protected] - http://iki.fi/upi/
> _______________________________________________
> Tao-discuss mailing list
> [email protected]
> http://mailman.taolinux.org/mailman/listinfo/tao-discuss
>