Prestaties van budget-ssd's in raid onderzocht

Ten onrechte hebben flash-ssd's de reputatie altijd superieure prestaties te leveren. Die reputatie komt voort uit de specsheets van de fabrikanten: deze  vermelden bijzonder hoge lees- en schrijftransferrates, en toegangstijden die bijna verwaarloosbaar laag zijn vergeleken met de waarden die voor hdd's karakteristiek zijn. Waar de fabrikanten van goedkope ssd's echter niet over reppen zijn de dikwijls tragisch hoge schrijfresponstijden van hun producten.

Die hoge schrijfresponstijden worden veroorzaakt door een combinatie van twee eigenschappen van flashgeheugen: de relatieve hoge schrijflatencies, en het feit dat flashgeheugen geen mogelijkheid biedt voor zogeheten in-place-updates van gegevens. De kleinste eenheid waarin flashgeheugen geprogrammeerd kan worden is de page. Een aantal pages samen vormen een blok. Bij het programmeren van een page worden bits omgezet van de standaardwaarde die ze aannemen nadat de bit is gewist. Het wissen van flashgeheugen vindt echter plaats op blokniveau. Een bit kan alleen teruggezet worden naar zijn standaardwaarde door het complete blok waarin deze zich bevindt te wissen. Het gevolg is een enorme overhead die optreedt bij het aanbrengen van kleine wijzigingen in bestaande gegevens. Bijvoorbeeld, om 512 bytes aan gegevens in het bestandssysteem te wijzigen moet er in het flashgeheugen 512kB aan gegevens ingelezen en beschreven worden: ruim het duizendvoudige. De verhouding tussen de door het bestandssysteem gevraagde wijzigingen en de  hoeveelheid fysieke wijzigingen in het flashgeheugen wordt de write amplification factor genoemd.

Het wissen van een blok vergt bij Intels huidige generatie flashgeheugen ongeveer twee milliseconde. De lees- en programmeerprestaties zijn afhankelijk van het type flashgeheugen. Single level cell-geheugen, waarbij één bit per geheugencel wordt opgeslagen, is aanzienlijker sneller dan multi level cell-flash. Voor een willekeurige leesactie heeft slc-geheugen 25 microseconde per page van 4kB nodig en mlc-geheugen 50 microseconde. Programmeren kost respectievelijk 250 en 900 microseconde per page. Voor het inlezen, wissen en programmeren van een blok van 512kB is zodoende 37,2ms nodig bij slc-geheugen en 123,6ms bij mlc-geheugen. Dit is vele malen hoger dan de toegangstijd van een gemiddelde harde schijf, die pakweg 12ms bedraagt.

Natuurlijk is de hoge write amplification factor die zich voordoet als er een vaste relatie zou bestaan tussen de locatie van gegevens in het bestandssysteem en de fysieke locatie in het flashgeheugen, volstrekt ongewenst. Niet alleen hebben de prestaties er zeer ernstig onder te lijden, ook treedt er onnodig veel slijtage aan de geheugencellen op. De inspanningen van de fabrikanten die hoge prestaties willen halen met hun ssd-controllers, zijn er daarom op gericht om gedeeltelijke wijzigingen in geheugenblokken zoveel mogelijk te voorkomen en latencies voor de gebruiker te verbergen. Dit is mogelijk door middel van caching en door wijzigingen zoveel mogelijk naar lege pages te schrijven, die zonder overhead geprogrammeerd kunnen worden.

Het is dit gebied waar zich het verschil aftekent tussen slimme, goed presterende ssd's en trage ssd's met een ondermaatse controller. Toen vorig jaar de eerste drives met de JMicron JMF602-controller op de markt kwamen, volgden er vele reacties van gebruikers die grote vertragingen in het gebruik van hun ssd ondervonden. Nader onderzoek van AnandTech bracht aan het licht dat ssd's met de JMicron JMF602 bij willekeurige schrijfacties een enorm hoge responstijd vertoonden, in de orde van 200ms en hoger. Neem een stuk of tien willekeurige schrijfacties achter elkaar en de wachttijd loopt op tot enkele seconden. In de praktijk zorgde zelfs het gebruik van lichte applicaties, zoals een instant messenger die een log naar de ssd schrijft, al voor het bevriezen van het systeem.

Eind vorige maand gaf JMicron in een interview met DailyTech toe dat de eerste versie van de JMF602 inderdaad met hoge schrijflatencies kampte. Het probleem zou verholpen moeten zijn in de B-revisie, die in juni 2008 werd uitgeleverd en sindsdien door ssd-fabrikanten wordt gebruikt. De twee Memorycorp-ssd's die wij in handen kregen, waren voorzien van de B-revisie van de JMF602. De A-Data Series 300 hebben we met rust gelaten omdat het de eigendommen van een gebruiker betrof.

Helaas zijn de resultaten van de low-level-benchmarks meer dan teleurstellend. De schrijfresponstijden van de JMF602B zijn nog steeds uiterst hoog: de A-Data Series 300 en de Memorycorp MF4 hebben voor een willekeurige schrijfactie gemiddeld respectievelijk 211 en 219 milliseconde nodig. Een stuk sneller is de Memorycorp SF4 met slc-geheugen, hoewel 84ms nog steeds ronduit waardeloos is vergeleken met de prestaties van andere ssd's en harde schijven.

De JMicron JMF602 is niet de enige ssd-controller die slechte schrijflatencies laat zien. Een vergelijkbaar probleem openbaarde zich bij de Photofast CR-9000, een doe-het-zelf-ssd waar zes sdhc-kaartjes in geplaatst kunnen worden. Opmerkelijk is dat deze ssd slechter ging presteren naarmate er meer geheugenkaartjes werden toegevoegd. Tevens noemenswaardig is dat Tweakers.net eind 2006 al eens een vroege ssd van PQI heeft getest. Die leverde toen, door zijn lage sequentiële transferrate van nog geen 23MBps, geen geweldige prestaties, maar de schrijfresponstijd was lang niet zo hoog als die van ssd's met een JMicron-controller anno 2008. Mogelijk maakte de PQI-ssd gebruik van slc-geheugen met een kleine blokgrootte.