[Linux] SATA vs PATA performance

[Verwijderd]

Ik verbaasde me er echt over dat m'n (geleende) Gigabyte + XP1800 systeempje met 250G Maxtor harddisk (PATA) zoveel sneller was wat betreft disk I/O dan m'n Asus Pundit-R met Pentium 4 2.8GHz en 160G Seagate SATA schijf.

Na wat gepruts met bonnie++ kwamen er wel leuke resultaten uit die ik nu eigenlijk probeer te verklaren (en nee, de grootte heeft geen significante invloed in prestatieverschil...). Voor de duidelijkheid: pluto is het XP1800 systeem, en dilithium de 2.8GHz P4. Bonnie++ draaide op beide machines op Fedora Core 4 met alle updates tot vandaag geïnstalleerd.

Ik heb wat gegevens verzameld over de systemen met hdparm om er zeker van te zijn dat de instellingen hetzelfde waren:

pluto (PATA):

/dev/hda:
multcount = 16 (on)
IO_support = 1 (32-bit)
unmaskirq = 1 (on)
using_dma = 1 (on)
keepsettings = 0 (off)
readonly = 0 (off)
readahead = 256 (on)
geometry = 30401/255/63, sectors = 250059350016, start = 0

dilithium (SATA):

/dev/hdc:
multcount = 16 (on)
IO_support = 1 (32-bit)
unmaskirq = 1 (on)
using_dma = 1 (on)
keepsettings = 0 (off)
readonly = 0 (off)
readahead = 256 (on)
geometry = 19457/255/63, sectors = 160041885696, start = 0

Bij het SATA systeem moest ik unmaskirq aanzetten en IO_support op 32 bit zetten. Bij het hdparm -i commando was iets vreemd. het SATA systeem kon alleen in UDMA2 werken en niet zoals het PATA systeem in UDMA5, ik weet niet of dit een wezenlijk verschil is?

pluto (PATA):

/dev/hda:

Model=WDC WD2500JB-00GVA0, FwRev=08.02D08, SerialNo=WD-WCAL75299379
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=4047/16/255, CurSects=16511760, LBA=yes, LBAsects=268435455
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

dilithium (SATA):

/dev/hdc:

Model=ST3160023AS, FwRev=3.18, SerialNo=3JS3J6HX
Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs RotSpdTol>.5% }
RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=4
BuffType=unknown, BuffSize=8192kB, MaxMultSect=16, MultSect=16
CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=268435455
IORDY=on/off, tPIO={min:240,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
AdvancedPM=no WriteCache=enabled
Drive conforms to: ATA/ATAPI-6 T13 1410D revision 2:

* signifies the current active mode

Ter afsluiting nog de dmesg uitvoer van zowel pluto als dilithium.

Ik hoop dat er iets te regelen valt waardoor de harddisk eindelijk op normale snelheid kan gaan werken, want het is een beetje jammer dat een oud systeem sneller is dan de nieuwe(re) P4.

[raoulduke]

Niet indicatief, maar kan je ook een hdparm met -tT draaien op beide schijven, het liefst onder zeer lage (lees: geen) load?

[Verwijderd]

Dat heb ik al gedaan ja, alleen niet weergegeven omdat hdparm (als ik sommigen mag geloven) eigenlijk niks nuttigs te melden heeft, op die machine met die PATA schijf ligt het rond de 55MByte/s, op die met SATA rond de 15MByte/s...

SATA:

/dev/hdc:
Timing cached reads: 1396 MB in 2.00 seconds = 697.76 MB/sec
Timing buffered disk reads: 44 MB in 3.00 seconds = 14.66 MB/sec

PATA:

/dev/hda:
Timing cached reads: 1376 MB in 2.01 seconds = 686.05 MB/sec
Timing buffered disk reads: 174 MB in 3.03 seconds = 57.36 MB/sec

Deze zijn in multiuser mode uitgevoerd, de tests uit m'n eerste post in single user mode (met daarna een killall5)

[ Voor 51% gewijzigd door Verwijderd op 15-09-2005 20:41 ]

[raoulduke]

Waarom zit je SATA schrijf op een IDE controller in /dev/hdc, of is dit een fout in je dmesg uitvoer voor je tweede machine?

[edit]
Het lijkt dus uit dmesg alsof je SATA schijf als UDMA33 IDE wordt aangestuurd, heb je in je BIOS misschien een soort SATA -> PATA conversie ingeschakeld? Op je eerste machine werkt de schijf op UDMA100.

[ Voor 47% gewijzigd door raoulduke op 15-09-2005 20:44 ]

[sphere]

Ugh. Tijd voor koffie.

[ Voor 85% gewijzigd door sphere op 15-09-2005 20:54 ]

[cool_zero]

Is het dezelfde sata controller als uit dit topic: [rml][ Silicon Image&Seagate] ontzettend traag[/rml] ?

[raoulduke]

sphere schreef op donderdag 15 september 2005 @ 20:49:
Gebruik je wel een 80-aderige kabel in dilithium?

Het is een Serial ATA schijf, dus waarschijnlijk heeft hij minder dan 10 aders

[raoulduke]

cool_zero schreef op donderdag 15 september 2005 @ 20:51:
Is het dezelfde sata controller als uit dit topic: [rml][ Silicon Image&Seagate] ontzettend traag[/rml] ?

Daar lijkt het wel op, kwam net op Google tegen dat de ATIIXP chipset weer gebruik maakt van die Silicon Image controller. Misschien zoeken naar de sata_sil kernel module?

http://www.google.nl/sear...n+image&btnG=Zoeken&meta=

[ Voor 18% gewijzigd door raoulduke op 15-09-2005 20:54 ]

[Verwijderd]

He, wat jammer nou weer...ik had in de BIOS wel een optie gevonden om 32 bit I/O aan te zetten, dat deed ik, maar toen bleef m'n bak op een willekeurig moment hangen, maar weer snel uitgezet...tijdens de tests uit TS was het zeker toeval dat 't niet misging in single user mode.

Ik ga me er nog eens verder in verdiepen, ik zal m'n machine wel eens openschroeven om te kijken wat voor chip erinzit, ik kan niks vinden met lspci wat op SI spul duidt...

Linkjes:
- http://home-tj.org/m15w/
- http://kerneltrap.org/node/3813

[ Voor 13% gewijzigd door Verwijderd op 15-09-2005 22:02 ]

[robbert]

cool_zero schreef op donderdag 15 september 2005 @ 20:51:
Is het dezelfde sata controller als uit dit topic: [rml][ Silicon Image&Seagate] ontzettend traag[/rml] ?

Hehe, mijn oude topic
Ik heb het overigens opgelost door een goedkoop promise controllertje te kopen. Toen draaide de sata schijven wel op normale snelheid en werd mijn filesystem niet elke keer corrupt (wat wel met de SI controller gebeurde).

Ik zou zeggen probeer het eens met een andere sata controller (als je die temminste ergens vandaan kan halen).

[ Voor 11% gewijzigd door robbert op 16-09-2005 10:23 ]

[FatalError]

Volgens mij draait die SATA computer in 'compatibility mode' waarbij het hele gebeuren op een PATA schijf+controller lijkt (vandaar die /dev/hdX).
Mijn SATA laptop kan ik ook in 'native mode' zetten. Hierbij moet ik de SATA drivers in de kernel gebakken hebben en wordt de schijf gezien als /dec/sdX.

[Wirehead]

je gebruikt m.a.w. nog de "old-style" sata driver (deprecated) en moet de sata driver via SCSI gebruiken. Even je kernel herbakken dus

[Verwijderd]

robbertkrebbers schreef op vrijdag 16 september 2005 @ 10:22:
[...]

Hehe, mijn oude topic
Ik heb het overigens opgelost door een goedkoop promise controllertje te kopen. Toen draaide de sata schijven wel op normale snelheid en werd mijn filesystem niet elke keer corrupt (wat wel met de SI controller gebeurde).

Ik zou zeggen probeer het eens met een andere sata controller (als je die temminste ergens vandaan kan halen).

In de pricewatch staan ze voor 40 euro (Promise TX2 sata) veel goedkoper is niet mogelijk (dus ik vind 't nog best duur...), de kaartjes van Sweex, Sitecom enzo zijn ook SIL chips...

[robbert]

Verwijderd schreef op vrijdag 16 september 2005 @ 12:55:
[...]


In de pricewatch staan ze voor 40 euro (Promise TX2 sata) veel goedkoper is niet mogelijk (dus ik vind 't nog best duur...), de kaartjes van Sweex, Sitecom enzo zijn ook SIL chips...

Voor mij was er destijds weinig keuze. Echt een oplossing was er niet (of het er nu is weet ik niet), Seagate en SIL en Linux ging (destijds) schijnbaar niet echt samen. De schijven vervangen zou nog een stuk duurder worden.

[Verwijderd]

Even nog een (kleine) update. Ik heb nog eens verder gezocht en ben tot de conclusie gekomen dat er helemaal geen SATA controller in die Pundit-R zit, alleen een PATA -> SATA bridge van Marvell, de Marvell 88i8030-TBC. Dat zou dus geen reden moeten zijn voor de langzame schijf. Ik denk dat ik het op ga lossen met een andere harddisk (Samsung SpinRite ofzo) en een *echte* SATA controller, bijvoorbeeld die van Q-Tec (Silicon Image 311x) of van Conceptronics (VIA).

[ Voor 3% gewijzigd door Verwijderd op 25-09-2005 22:52 ]