Mailing List Archive

IDE Performance - SPARC (Worse on UDMA66?)
I've been trying to up the performance of the disks in my Ultra10, and
I'm running across something I can't quite figure out...

I have 2 identical 120GB IDE drives. One is installed on the primary
IDE interface of the motherboard. The other is installed on the primary
IDE interface of a Promise Ultra66 PCI/IDE card (just recently flashed
to the most-recent bios). The only other drives in the box are the stock
CDROM (which is on the secondary IDE interface of the motherboard
[hdc]), and a SCSI tape backup (which is plugged into a PCI/SCSI card).

Here are the details:

sun ~ # hdparm -i /dev/hda

/dev/hda:

Model=WDC WD1200JB-00GVA0, FwRev=08.02D08, SerialNo=WD-WCALA2043613
Config={ HardSect NotMFM HdSw>15uSec SpinMotCtl Fixed DTR>5Mbs FmtGapReq }
RawCHS=16383/16/63, TrkSize=57600, SectSize=600, ECCbytes=74
BuffType=DualPortCache, BuffSize=8192kB, MaxMultSect=16, MultSect=16
CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=234441648
IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
PIO modes: pio0 pio1 pio2 pio3 pio4
DMA modes: mdma0 mdma1 *mdma2
UDMA modes: udma0 udma1 udma2 udma3 udma4 udma5
AdvancedPM=no WriteCache=enabled
Drive conforms to: device does not report version:

* signifies the current active mode

sun ~ # hdparm -i /dev/hde

/dev/hde:

Model=WDC WD1200JB-00GVA0, FwRev=08.02D08, SerialNo=WD-WCALK1317943
Config={ HardSect NotMFM HdSw>15uSec SpinMotCtl Fixed DTR>5Mbs FmtGapReq }
RawCHS=16383/16/63, TrkSize=57600, SectSize=600, ECCbytes=74
BuffType=DualPortCache, BuffSize=8192kB, MaxMultSect=16, MultSect=16
CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=234441648
IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
PIO modes: pio0 pio1 pio2 pio3 pio4
DMA modes: mdma0 mdma1 mdma2
UDMA modes: udma0 udma1 udma2 udma3 *udma4 udma5
AdvancedPM=no WriteCache=enabled
Drive conforms to: device does not report version:

* signifies the current active mode

sun log # hdparm /dev/hda

/dev/hda:
multcount = 16 (on)
IO_support = 0 (default 16-bit)
unmaskirq = 0 (off)
using_dma = 1 (on)
keepsettings = 0 (off)
readonly = 0 (off)
readahead = 8 (on)
geometry = 14593/255/63, sectors = 120034123776, start = 0

sun log # hdparm /dev/hde

/dev/hde:
multcount = 16 (on)
IO_support = 0 (default 16-bit)
unmaskirq = 0 (off)
using_dma = 1 (on)
keepsettings = 0 (off)
readonly = 0 (off)
readahead = 8 (on)
geometry = 14593/255/63, sectors = 120034123776, start = 0

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?). What doesn't make sense is this:

sun ~ # hdparm -Tt /dev/hda

/dev/hda:
Timing O_DIRECT cached reads: 564 MB in 2.01 seconds = 280.60 MB/sec
Timing O_DIRECT disk reads: 46 MB in 3.04 seconds = 15.13 MB/sec

sun ~ # hdparm -Tt /dev/hde

/dev/hde:
Timing O_DIRECT cached reads: 576 MB in 2.00 seconds = 288.00 MB/sec
Timing O_DIRECT disk reads: 30 MB in 3.13 seconds = 9.58 MB/sec

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.

Thanks in advance...

--
gentoo-sparc@gentoo.org mailing list
Re: IDE Performance - SPARC (Worse on UDMA66?) [ In reply to ]
From: Derek Pizzagoni <pizz@pacbell.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@gentoo.org mailing list
Re: IDE Performance - SPARC (Worse on UDMA66?) [ In reply to ]
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@pacbell.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@gentoo.org mailing list