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 <[EMAIL PROTECTED]>
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.
--
[email protected] mailing list
