| 1 |
From: Derek Pizzagoni <pizz@×××××××.net> |
| 2 |
Date: Wed, 31 Aug 2005 16:09:49 -0700 |
| 3 |
|
| 4 |
> As you can see, the drives are identical. The first one comes up in |
| 5 |
> mdma2 mode, and the second one comes up in udma4 mode. This makes |
| 6 |
> sense, since the motherboard doesn't support the faster interface (only |
| 7 |
> up to 33, right?). |
| 8 |
|
| 9 |
The limit is mdma2 mode for the onboard IDE controller. |
| 10 |
|
| 11 |
> I've run them multiple times, and it always comes out similar to above. |
| 12 |
> This is on a relatively dormant system. Can anyone tell me why a drive |
| 13 |
> plugged into the motherboard's IDE interface (running in mdma2 mode) |
| 14 |
> would outperform the same drive plugged into an Ultra66 card (running in |
| 15 |
> udma4 mode)? With these results, I'd be better off putting the second |
| 16 |
> drive back on the chain with the CDROM. |
| 17 |
|
| 18 |
If there is any noise on the cable, UDMA performance can suffer |
| 19 |
dramatically, because commands will be retried when parity errors |
| 20 |
are detected on the bus. |
| 21 |
|
| 22 |
It's nice that UDMA handles parity errors nearly transparently |
| 23 |
like this, but it can be a silent performance killer. |
| 24 |
|
| 25 |
Another possibility is that the promise driver isn't optimized |
| 26 |
for sparc64 so well. This kind of thing has been discovered |
| 27 |
before. |
| 28 |
|
| 29 |
-- |
| 30 |
gentoo-sparc@g.o mailing list |
Archives