Gentoo Archives: gentoo-sparc

From: Derek Pizzagoni <pizz@×××××××.net>
To: "David S. Miller" <davem@××××××.com>
Cc: gentoo-sparc@l.g.o
Subject: Re: [gentoo-sparc] IDE Performance - SPARC (Worse on UDMA66?)
Date: Thu, 01 Sep 2005 16:40:41
In Reply to: Re: [gentoo-sparc] IDE Performance - SPARC (Worse on UDMA66?) by "David S. Miller"
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@×××××××.net> >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