SATA - verschil lees/schrijfsnelheid

[MarcelG]

Ik was gisteravond even aan 't testen of eSATA (3.0) nu echt zo veel sneller is dan USB2.

Dus, een schijf geleend van een collega, aan de eSATA aansluiting gehangen, PC geherstart (was blijkbaar nodig).

De eSATA disk is de D schijf en gebruikt de JMicron controller van het moederbord.
M'n eigen data partitie is de E schijf, welke onderdeel is van een stripeset van 2 300 GB Seagate Barracuda's via SATA op de ICH9R controller.

In Altap Salamander (explorer vervanger), een kopie-actie gestart, van wat films van E naar D.
Het resultaat is redelijk vreemd.
Bij een kopieer-actie van de SATA stripe set naar de eSATA disk:


Vervolgens terugkopieëren, van eSATA naar de SATA stripe set.


De CPU load bij die laatste actie zat rond de 35% merkte ik.
Dus, daarom de volgende test ; de CPU load bij een kopieer actie van 500 MB van SATA naar eSATA ; voor de kopieer-actie ca 2% CPU usage.

En, andersom, de CPU load bij een kopieer actie van 500 MB van eSATA naar SATA:


Dus, samenvattend.
SATA -> eSATA : geen noemswaardige CPU load, >60 MB/sec.
eSATA -> SATA : 35% CPU load, <20 MB/sec.

Raar....maar, wat blijkt nog meer ; bij een kopieeractie óp de SATA disk (700 MB van folder \Films naar \Test) zie ik een snelheid van 30 a 35 MB/sec, en deze CPU load:

Nu ben ik in de war.....ligt 't aan de eSATA connectie ? Lijkt me stug, aangezien het in de laatste actie helemaal niets met een eSATA disk te maken heeft.

Dus, 't ligt aan m'n SATA RAID controller (ICH9R), of de stripeset setup of nog iets anders ?!
Iemand enig idee of en zo ja hoe dit oplosbaar is?

Oh ja, systeemspecs:
Windows Vista x64 Ultimate, Intel Core2Duo E6750, 4 GB RAM, Asus P5K-R met ICH9R southbridge.
Intern: 2x320 GB SATA Seagate Barracuda in RAID0, op ICH9R SATA controller.
Extern: 1x 60 GB SATA, via JMicron SATA controller.

[--MeAngry--]

Ik kan me eerder voorstellen dat het door die JMicron controller komt. Ik snap echt niet dat ASUS die ondingen op z'n mobo's blijft prikken . (Ik zou de kotssmiley willen gebruiken, maar ik houd me maar in.)
De performance van die dingen is echt bagger en totaal onvoorspelbaar.

Een kopieeractie op dezelfde schijf echter (je RAID array) zal inderdaad behoorlijk wat CPU vreten omdat het én software RAID is én twee acties tegelijk van en naar diezelfde array moet uitvoeren. Redelijk logisch dus.

[Verwijderd]

Ik heb hier ook een JMicron controller waar een eSATA schijf aan hangt. Moet je kijken wat de controller weet te veroorzaken:

klikbaar:


klikbaar:


Steeds op een andere plek dus duidelijk niet de schijf zelf. Effectief mag ik blij zijn als ik met 40MB/sec data kan moven.

Dus ja .. ik gok dat het een controller-issue is.

[TERW_DAN]

Met eS-ATA heb ik de JMicron nooit gebruikt, wel icm interne S-ATA disks. CPUpieken zoals jij die hebt heb ik in dat geval ook, dus ik ben het eens met bovenstaande posters dat het controller-issue is. Mijn oplossing was simpel, door de eS-ATA connector aan de ICH8R te hangen (of de ICH9R op m'n volgende bordje )

[MarcelG]

Dus, de lage 'leessnelheid' van de esata naar de SATA disk komt door de JMicron controller die blijkbaar dus gewoon brak is.
De lage schrijfsnelheid van SATA naar dezelfde SATA disk in stripe komt dus doordat het tegelijkertijd lees en schrijfacties op dezelfde controller zijn.....makes sense. Zo had ik 't nog niet bekenen. Thanks.

Ik zal eens kijken hoe ik die esata aan de ICH9R controller kan hangen....even 't boekje van 't moederbord er bij zoeken.

[ Voor 15% gewijzigd door MarcelG op 28-02-2008 13:03 ]

[Verwijderd]

Misschien kun je ook wat ATTO benches van je eSATA / SATA disks posten? Heb je write-back ingeschakeld op je RAID0 volume? Zo ja, kan dit tot hogere CPU belasting leiden.

En om welke controller gaat het? JMicron maakt er meerdere. Ik haal iig maximale transferrate op JMB363 op FreeBSD. Wellicht dat dit een driverprobleem is?

[ Voor 46% gewijzigd door Verwijderd op 28-02-2008 13:08 ]

[Verwijderd]

Als ik een file van 1 GB kopieer op mijn SATA-array dan heb ik ongeveer 10% load. Duurt ook ongeveer 10 seconden.

[MarcelG]

Verwijderd schreef op donderdag 28 februari 2008 @ 13:07:
Misschien kun je ook wat ATTO benches van je eSATA / SATA disks posten? Heb je write-back ingeschakeld op je RAID0 volume? Zo ja, kan dit tot hogere CPU belasting leiden.

Ik ga vanavond benchen, en kijken of ik writeback-cache heb aanstaan. Volgens mij staat dat uit, maar ik weet 't niet zeker.

Verwijderd schreef op donderdag 28 februari 2008 @ 13:07:En om welke controller gaat het? JMicron maakt er meerdere. Ik haal iig maximale transferrate op JMB363 op FreeBSD. Wellicht dat dit een driverprobleem is?

Ga ik ook vanavond even opzoeken...

[ Voor 21% gewijzigd door MarcelG op 28-02-2008 13:22 ]

[MarcelG]

Nou, Write Back Caching stond uit.
Aangezet ; resultaat: 70-120 MB per seconde transfersnelheid op de stripeset, en 5-15% CPU load gedurende de transfer van de E naar de C schijf.
Van C naar E, initieel 70-120 MB per seconde., daarna plots 20-40 MB per seconde.

Vervolgens heb ik de NTFS compression uitgeschakeld ; resultaat: 70-120 MB per seconde.....
Probleem lijkt hiermee dus verholpen. Boosdoener was dus geen driver, maar NTFS compressie.

[ Voor 39% gewijzigd door MarcelG op 28-02-2008 18:28 ]