In tegendeel, AS SSD en CrystalDiskMark testen via het filesystem en krijgen dus alle optimalisaties en andere invloeden die echte I/O ook krijgt. HDtune is een direct I/O benchmark net als IOmeter en Rankdisk en werkt dus NIET via het filesystem; dat is dus per definitie synthetisch omdat het I/O via een andere methode doet dan je daadwerkelijke programma's die je probeert te simuleren.
Resultaten zijn
absoluut niet vergelijkbaar omdat HDtune - doordat het synthetisch is - de gehele LBA oppervlakte gebruikt voor seeks. Tevens zijn zaken als alignment en request size heel belangrijk, zoals ik nader zal uitleggen. CrystalDiskMark en AS SSD werken op filesystem-niveau, dus niet op LBA-niveau. Zij hebben geen controle waar het bestand daadwerkelijk wordt opgeslagen en dat is ook niet zo relevant. Echte programma's hebben daar ook geen controle over, dat is immers het werk van het filesystem.
2) door gebruik te maken van het filesysteem zullen de toegangstijden extreem varieren naargelang de grootte, positie en fragmentatie van het testbestand. De grootte kun je instellen maar op die andere twee parameters heb je (bijna) geen invloed.
Als je een schijf met gatenkaas gaat benchmarken kan dat je scores zeker sterk doen laten fluctueren, maar normaliter is dit geen issue omdat bij het alloceren je een groot stuk stuk pakt zoals 4GB. Zolang er voldoende ruimte vrij is op je schijf zal dit een groot stuk
contiguous data betreffen zonder fragmenten erin. Maar al zou dat zo zijn is dat nog steeds realistisch omdat een programma wat eenzelfde hoeveelheid zou claimen hetzelfde performancegedrag zal ervaren. We blijven met onze benchmarks dus bij het simuleren van echte programma's/gebruik.
3) de belangrijkste optimalisatie voor HDD's is cache en die wordt uitgeschakeld bij alle benchmarks
Over welke cache heb je het? De HDD cache blijft onveranderd aan. Enige wat wordt onderdrukt is de filesystem cache; zodat je niet het bestand wat je ZOJUIST hebt weggeschreven uit RAM gaat lezen dat defeats the whole purpose. Als je dat niet zo willen zou je tussen de benchmarks door elke keer moeten rebooten om nauwkeurige en realistische resultaten te krijgen.
4) ik weet niet exact hoe het emuleren van 512 bytes sectioren werkt bij een Advanced Format schijf maar volgens mij is het gewoon een kwestie van slechts 512 bytes naar de host sturen ipv. 4 KB. Ik kan me niet voorstellen dat dit een noemenswaardige vertraging oplevert.
Nou dat is dus absoluut wel zo, en is ook heel eenvoudig. Een schijf met 4K sectoren kan alleen maar I/O in veelvouden van 4K doen. Dus als het 512 bytes wilt lezen, moet het 4K lezen. Goed, een klein beetje extra onnodige I/O dat kan toch niet zoveel invloed hebben? Nee dat het 8 keer zoveel moet lezen (4K/512=8) is niet het punt, wel als je gaat schrijven. Een 512B write-request kan niet zomaar verwerkt worden door een 4K sector schijf. De schijf moet eerst sectoren gaan emuleren en eigenlijk het werk doen van een filesystem.
1. Voordat de hardeschijf de 4K kan opslaan moet het eerst gaan
lezen van de schijf
2. Na het inlezen van de 4K sector wordt de oude data met de nieuwe data herenigd en hebben we een 4K sector bestaande uit oude data die al op de schijf stond en de nieuwe 512B data die we willen schrijven
3. De 4K sector wordt geschreven en de write request raakt voltooid.
Dus voor de duidelijkheid: de schijf moet dus gaan
lezen voordat het kan schrijven. Dit geldt alleen als de hardeschijf kleinere sectoren moet gaan emuleren, als het filesystem zijn werk goed doet gebeurt dat nooit en krijgt de schijf uitsluitend I/O in veelvouden van 4K. Een writerequest van 512B is dus stukken trager dan een writerequest van 4K of 8K of 16K etc.
Ik heb een vergelijking gedaan om eea. toe te lichten. De toegangstijden werden gemeten op 3x verschillende Seagate 320 GB met de drie vermelde programma's.
Dit zijn de resultaten:
HDD1:
HD Tune: 13.3ms
AS SSD: 13.3ms
CrystalDiskMark: 9.2 ms
HDD2:
HD Tune:13.4ms
AS SSD: 13.4ms
CrystalDiskMark: 6.0ms
HDD3:
HD Tune:13.3ms
AS SSD:13.4ms
CrystalDiskMark: partitie1: 9.2ms, partitie 2: 5.7ms
Daarna heb ik de testgrootte van het bestand verhoogd van 50 MB naar 100 MB met als resultaat:
partitie 2: 7.2ms
en nog eens verhoogd: partitie 2: 9.3ms
De enige file benchmark geeft dus compleet waardeloze resultaten.
HDtune = raw I/O, AS SSD en CrystalDiskMark zijn benchmarks die via het filesystem lopen.
Dat het waardeloze resultaten zijn deel ik niet. Ik denk dat je vooral de resultaten verkeerd interpreteert.
Als AS SSD net als HDtune gebruik maakt van 512B seeks voor de access time - en ik weet dat AS SSD dat doet - dan is het logisch dat de access time hoger is dan wanneer CrystalDiskMark dit doet met 4K requests of requests die gelijk zijn aan de fragmentation size; een filesystem attribuut.
Als het klopt wat ik denk verklaart dat het verschil tussen de access times die CrystalDiskMark opgeeft (correct) en die AS SSD aangeeft. Die laatste is dus incorrect omdat het 512B seeks gebruikt en dat is hedendaags met frag=4K niet meer realistisch.
Verder lijk je het vreemd te vinden dat als je de partitie groter maakt of dicther bij het einde van de capaciteit komt van je hardeschijf, je access times toenemen en dus langzamer worden. Dit is echter volkomen logisch omdat je een breder bereik aan LBA gaat testen en dus ook de seekafstand toeneemt. HDTune test volledig LBA bereik en zou dus een hogere access time moeten hebben. Echter, als de schijf moet emuleren is de schijf flink trager en kunnen de verschillen in het niet vallen bij de extra tijd die emulatie kost. Ik zou dus de exacte output nodig hebben om echt zinnige uitspraken te doen over jouw performanceresultaten.
:strip_exif()/u/118818/icon2.gif?f=community)
