ATTO 50MB/sec tranfer, 8KB blocks, dat kan technisch niet.

[Verwijderd]

als ik in het topic "post hier je raid0 benchies" kijk en dan met name naar de ATTO grafiekjes. waar bijvoorbeeld een 50MB/sec tranfer rate wordt gehaald voor een gemiddelde schijf wanneer er 8KB blocken gebruikt worden om te testen denk ik dat dit technisch niet mogelijk is.

Kan iemand mij op mijn denk/reken fout wijzen als ik als volgt redeneer:

50MB/sec = 50 * 1024 = 51200 KB/sec

bij 8KB blocks is dit dus 51200KB/8KB=6400 IOs/sec

echter als ik naar bijvoorbeeld een super snelle ATLAS II 15000RPM kijk dan heeft deze bij een sequentieel data access karakter een access time van 3,4 ms.

dat zijn dus maximaal 1000ms/3,4ms=294 IOs/sec

wanneer ik dan weer die 8KB blocks neem kom ik op maximaal 294 * 8KB= 2352KB/sec = 2352KB/1024 =2,39 MB/sec transfer rate.

Aangezien dit een stuk lager is dan ALLE resultaten die ik in het bovengenoemde draadje zie moet ik toch ergens een denkfout maken. Of is het iets met cache?

ik hoor graag wat ik net verprutst heb.

[FragileM64]

Verwijderd schreef op zaterdag 05 november 2005 @ 13:24:
als ik in het topic "post hier je raid0 benchies" kijk en dan met name naar de ATTO grafiekjes. waar bijvoorbeeld een 50MB/sec tranfer rate wordt gehaald voor een gemiddelde schijf wanneer er 8KB blocken gebruikt worden om te testen denk ik dat dit technisch niet mogelijk is.

Kan iemand mij op mijn denk/reken fout wijzen als ik als volgt redeneer:

50MB/sec = 50 * 1024 = 51200 KB/sec

bij 8KB blocks is dit dus 51200KB/8KB=6400 IOs/sec

Tot daar kan ik je volgen, de rest is gewoon BS...

http://www.storagereview..../perf/spec/posAccess.html

Als je achtereenvolgende blocks van 8 Kb gaat lezen , dan kost dit niet telkens opnieuw 3,4ms
Als je enkel uit de cache zou gaan lezen denk ik dat je zelfs nog hoger dan 50mb/sec doet. Men gewone ide schijf doet al meer dan 27mb/sec.

[ Voor 17% gewijzigd door FragileM64 op 05-11-2005 13:38 ]

[Pannenkoekkie]

Verwijderd schreef op zaterdag 05 november 2005 @ 13:24:
als ik in het topic "post hier je raid0 benchies" kijk en dan met name naar de ATTO grafiekjes. waar bijvoorbeeld een 50MB/sec tranfer rate wordt gehaald voor een gemiddelde schijf wanneer er 8KB blocken gebruikt worden om te testen denk ik dat dit technisch niet mogelijk is.

Plus dat je het hebt over Raid 0, waarbij de dit (foute) resultaat dus eigenlijk ook nog maal 2 moet doen, plus reactie hier boven...

[ Voor 3% gewijzigd door Pannenkoekkie op 05-11-2005 13:42 ]

[The__Virus]

Maar die reactietijd is er eigenlijk helemaal niet. Die wordt met Atto gemeten, door de hardeschijf de opdracht te geven willekeurig bitjes uit te lezen op de schijf, terwijl bij het schrijven dit allemaal achter elkaar ligt en de kop dus niet iedere keer hoeft te verplaatsen.

[Verwijderd]

FragileM64 schreef op zaterdag 05 november 2005 @ 13:34:
[...]

Tot daar kan ik je volgen, de rest is gewoon BS...

http://www.storagereview..../perf/spec/posAccess.html

Als je achtereenvolgende blocks van 8 Kb gaat lezen , dan kost dit niet telkens opnieuw 3,4ms
Als je enkel uit de cache zou gaan lezen denk ik dat je zelfs nog hoger dan 50mb/sec doet. Men gewone ide schijf doet al meer dan 27mb/sec.

Bedankt voor de link, zeer verhelderend. Maar een ding is mij nog niet helemaal duidelijk. Dit heeft misschien meer te maken met de werking van ATTO zelf.

Als ik het goed begrijp bepaal je met Total Length de totale hoeveelheid data die in iedere test wordt gebruikt. en met Tranfer Size in welke blocksizes je die totale hoeveelheid wilt laten lezen en schrijven.

Als dit bovenstaande klopt en ik jouw antwoord goed begrijp -dat alle 8kb blocken achter elkaar zitten en daarom in een keer gelezen worden-, dan snap ik niet waarom er verschil zit in de 4, 8, 16, 32, 64 etc. testen, immers er staat 32MB sequentieel achter elkaar op de disk, en welke blocksize ATTO ook gebruikt de hele 32MB wordt in een keer gelezen of geschreven.


Het feit dat er bij verschillende blocksizes verschillende resultaten zijn doet mij vermoeden dat er ook verschillende hoeveelheden IOs worden gestuurd/ontvangen. 4KB blocks ->> 32MB * 1024 =3072KB --> 3072/4 =768 apparte IOs en bij 8KB blocks is het dus 3073/8=384 IOs.

er moet dus wel een IO gerelateerde latency zijn wil je kunnen uitleggen dat de 4KB block test een lagere tranfer rate haalt dan de 8KB test. Echter hoe bereken je juidst die latency?

begrijp me niet verkeerd, dat mijn eerste theorie niet klopt is mij volkomen helder. 28 pagina's testresultaten in het eerste draadje bevestigen dat namelijk al. 3,4 ms access time is echt veels te veel maar hoe bereken ik de juiste?

[Verwijderd]

Pannenkoekkie schreef op zaterdag 05 november 2005 @ 13:41:
[...]


Plus dat je het hebt over Raid 0, waarbij de dit (foute) resultaat dus eigenlijk ook nog maal 2 moet doen, plus reactie hier boven...

Had ik misschien duidelijker over moeten zijn maar ik nam als voorbeeld 1 enkele disk in plaats van 2 in RAID 0. Het was alleen zo dat ik toevallig in het RAID0 draadje al die metingen tegen kwam.

[Olaf van der Spek]

Verwijderd schreef op zaterdag 05 november 2005 @ 23:32:
Het feit dat er bij verschillende blocksizes verschillende resultaten zijn doet mij vermoeden dat er ook verschillende hoeveelheden IOs worden gestuurd/ontvangen. 4KB blocks ->> 32MB * 1024 =3072KB --> 3072/4 =768 apparte IOs en bij 8KB blocks is het dus 3073/8=384 IOs.

Het kan natuurlijk ook zo zijn dat de benchmark gewoon niet deugt.

Maar je hebt gelijk, als de applicatie een sequential read uitvoert mag de request size niet uitmaken.

[Verwijderd]

ge verwart MBIT en Mbyte met elkaar heb ik de indruk

[Verwijderd]

Verwijderd schreef op maandag 07 november 2005 @ 15:48:
ge verwart MBIT en Mbyte met elkaar heb ik de indruk

zou je kunnen uitleggen waar ik dat doe?