I've tried re-routing, and even switching out the cable with a
braided/shielded one.  No effect.  I've also tried switching the drive's
mode to mdma2 (via hdparm), but that locks up my system.

Maybe the driver-optimization is the key.  I don't have a different
manufacturers card to try at the moment (only a few promise ultra66s).
It's kind of coincidental though...  I tried the same thing with a
couple of different SCSI drives (plugged into an Adaptec 2940), and
received similar throughput (9M).  Maybe the Adaptec driver isn't
optimized either?



David S. Miller wrote:

>From: Derek Pizzagoni <pizz@...>
>Date: Wed, 31 Aug 2005 16:09:49 -0700
>
>
>
>>As you can see, the drives are identical.  The first one comes up in
>>mdma2 mode, and the second one comes up in udma4 mode.  This makes
>>sense, since the motherboard doesn't support the faster interface (only
>>up to 33, right?).
>>
>>
>
>The limit is mdma2 mode for the onboard IDE controller.
>
>
>
>>I've run them multiple times, and it always comes out similar to above.
>>This is on a relatively dormant system.  Can anyone tell me why a drive
>>plugged into the motherboard's IDE interface (running in mdma2 mode)
>>would outperform the same drive plugged into an Ultra66 card (running in
>>udma4 mode)?  With these results, I'd be better off putting the second
>>drive back on the chain with the CDROM.
>>
>>
>
>If there is any noise on the cable, UDMA performance can suffer
>dramatically, because commands will be retried when parity errors
>are detected on the bus.
>
>It's nice that UDMA handles parity errors nearly transparently
>like this, but it can be a silent performance killer.
>
>Another possibility is that the promise driver isn't optimized
>for sparc64 so well.  This kind of thing has been discovered
>before.
>
>

-- 
gentoo-sparc@g.o mailing list