List Archive: gentoo-sparc
Note: Due to technical difficulties, the Archives are currently not up to date.
provides an alternative service for most mailing lists.c.f. bug 424647
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
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
firstname.lastname@example.org mailing list