Dat is inderdaad de grootste zwakte van benchmarks.
Je kunt grofweg twee soorten benchmarks onderscheiden: zij die één soort performance testen (low-level performance) zoals random 4K read/write, en zij die proberen een realistische situatie na te bootsen. Dat eerste is makkelijk te doen, dat tweede is vele malen lastiger en ook misleidender. Omdat je de suggestie wekt dat dit type benchmark representatief is voor praktisch gebruik, terwijl dat niet zo hoeft te zijn omdat in de praktijk nog meer factoren meespelen dan welke getest zijn.
Als ik naar de IOmeter benchmark 4k random write io operations kijk die Cipher aanhaalt, wat kan ik daar dan mee ?
Daarmee kun je stellen dat de JMicron controller zeer zwakke performance laat zien qua
sustained random write; een low level spec die vaak aangehaald wordt en waar SSDs over het algemeen flink sneller zijn dan hardeschijven. De JMicron/Toshiba controller zit echter op het niveau van hardeschijven en soms zelfs onder dit niveau, wat op zich een zeer zwakke prestatie is.
Maar zoals gezegd, dit gaat over sustained random write. De SSD is stukken sneller met sporadische random writes wat voor een doorsnee gebruiker veel belangrijker is.
Hoger is beter dus de C300 is zeshonderdtachtig keer beter? Als ik dus een hele grote file heb met fonts (allemaal kleine bestanden dus) en de C300 doet daar 12 sekonden over om weg te schrijven, dan zal de Kingston daar 2 uur en 16 minuten over doen?
Als je over het gehele bereik 4K bestanden of data schrijft, dan zou je inderdaad de IOmeter test nabootsen en dezelfde performance moeten zien. Maar dit is geen praktijk situatie, namelijk:
1) desktops leunen niet zo heel zwaar op random write; juist eerder sequential read + random read. Schrijven is eigenlijk helemaal niet zo belangrijk voor desktops; als je een SSD puur als systeemdisk gebruikt dan heb je alleen een paar 4K writes bij dagelijks gebruik en 90%+ reads.
2) 4K writes zijn erg optimisch en veroorzaken geen fragmentatie. In de praktijk krijg je 3.5K en 5.5K writes welke op termijn fragmentatie en dus lagere performance veroorzaken.
3) 4K writes op een klein LBA bereik (een specifieke plek) zijn minder belastend dan 4K writes over de hele LBA range (willekeurig op elke zichtbare plek op een SSD).
4) Weinig workloads bestaan uit volledig writes of reads; het is altijd een mix van de twee. Een mix van sequential read, sequential write, random read en random write.
5) Variërende queue depth maakt het nog ingewikkelder, met name voor random reads. In de praktijk kom je veel qd=1 reads tegen en vaker hogere queue depth writes die met bursts eruit gaan.
6) Merk ook op dat een bestand wegschrijven niet alleen betekent dat je SSD dat bestand moet schrijven, maar ook dat filesystem metadata en journal worden bijgewerkt, dat levert extra writes op.
7) Simpelweg het aantal IOps tellen of MB/s is niet échte performance. Echte performance is de latency waarop de rest van het systeem moet wachten totdat de I/O-actie voltooid is. Gedurende die tijd kunnen bijvoorbeeld programma's niets doen en wacht het hele systeem totdat de HDD/SSD klaar is met de I/O. Dit is echter niet altijd het geval. Voor background I/O (voornamelijk writes) geldt dat je hier niets van hoeft te merken als dit twee keer zo langzaam gaat.
I/O performance is een van de moeilijkste om te benchmarken en is om die reden ook het meest omstreden. Ik zelf geef veel om synthetische benchmarks omdat je hiermee een prima inschatting kunt maken van real-life prestaties, welke een gevolg zijn van de low-level prestaties. Het is echter vaak de interpretatie van de benchmarks die fout gaat; niet de benchmarks zelf.