SSD Showdown: 36 256GB en 512GB SSD's review

Lastige klus

… en dat heeft er alles mee te maken dat het werk van de SSD-controller, het aansturen van de flashgeheugenchips, alles behalve eenvoudig is. Er zijn diverse zaken die de controller op een zo slim en goed mogelijke manier moet doen om goede prestaties en een hoge betrouwbaarheid voor elkaar te krijgen. Allereerst wear leveling. Zoals bekend kunnen alle geheugencellen binnen flashchips slechts een beperkt aantal keren opnieuw beschreven worden. Bij standaard MLC-chips waarbij 2 bits per cel worden opgeslagen is dat in de regel 3000 à 5000 keer. Bij TLC-chips, zoals we die tegenkomen bij de Samsung 840 Evo, ligt de grens officieel op 1000 keer, al hebben we inmiddels met een test aangetoond dat het in de praktijk hoger ligt, in ieder geval bij Samsungs 840 Evo reeks (zie kopje TLC hieronder). Iedere keer wanneer de chipfabrikanten overstappen naar een kleiner productieprocedé – 19nm is nu state-of-the-art – wordt de hoeveelheid beschikbare cycli kleiner. Het is dus zaak voor de controller om schrijfopdrachten zo goed mogelijk evenredig te verdelen over alle cellen. De wear leveling is één van de redenen dat data op een SSD fysiek op andere plekken wordt opgeslagen dan waar het besturingssysteem via de adressering naar verwijst. Een andere reden is een andere vervelende eigenschap van flashgeheugen…

We hebben meermaals geschreven dat data op een SSD per zogenaamde 'pagina', hoeveelheden van meestal 4, 8 of 16 kB, weggeschreven en uitgelezen kan worden. Om data te kunnen wegschrijven, moeten datacellen echter eerst gewist worden: dát kan alleen per blok. Zo'n blok bestaat uit 128, 256 of 512 pagina's. Dit gegeven zorgt ervoor dat SSD-controllers slimme trucjes moeten uithalen. Wanneer een aantal pagina's aan data verwijderd moet worden, moet eerst de rest van de data uit het blok gekopieerd worden naar een ander blok, waarna het gehele blok geleegd kan worden.

In de praktijk betekent het dat SSD-controllers schrijfacties zoveel mogelijk opzamelen, deze vervolgens tegelijk naar nieuwe, vers geleegde blokken uitvoeren en tegelijkertijd verwijderacties pas op gezette tijden uitvoeren. Op die momenten, wanneer de SSD niets te doen heeft, schakelt de in de controller ingebakken garbage collector in, die verwijderacties daadwerkelijk doorvoert op chipniveau en overbleven data zoveel mogelijk combineert in volle blokken, om op die manier zoveel mogelijk blokken volledig leeg te kunnen maken.

De meeste controllers doen aan dergelijke background garbage collection, ofwel het combineren van data in volle blokken op momenten waarop de SSD niet gebruikt wordt, om op die manier zoveel mogelijk volledig lege blokken te creëren. Wanneer de SSD echter lange tijd volcontinu, dus zonder een seconde rust, gebruikt wordt, kan de garbage collector niet tussendoor aan de slag. Op een gegeven moment zijn er dan geen lege blokken meer over en zal de SSD tussen het uitvoeren van commando's door aan garbage collection moeten gaan doen.  Forground garbage collection heet het dan in jargon, en het prestatieniveau kan in zo’n situatie flink inzakken tot wat men noemt de steady state prestaties. Ook hiervoor hebben we een test.

De manier waarop de garbage collection en het hergroeperen van data gebeurt is misschien wel het belangrijkste aspect waarop algoritmes van verschillende SSD-controllers zich van elkaar onderscheiden. Er is namelijk een intrinsiek dilemma; aan de ene kant wil je zo snel mogelijk oude data echt verwijderen en valide data combineren om op die manier zo veel mogelijk lege blokken te creëren om daarmee zo lang mogelijk hoge prestaties te kunnen bieden. Maar… wanneer data te vaak en te snel intern wordt verplaatst neemt het aantal interne schrijfopdrachten flink toe. De zogenaamde write amplification factor, de verhouding tussen het aantal intern uitgevoerde schrijfopdrachten en het aantal schrijfopdrachten vanuit het besturingssysteem, gaat dan door het dak. Vergeet niet dat de levensduur van flashchips afhankelijk is van het aantal schrijfopdrachten! Vanuit dat oogpunt wil je het intern verplaatsen van data dus pas doen als het écht nodig is. Slimme algoritmes die voorspellen wat op ieder moment de beste keuze is, zijn dus van groot belang.

De anatomie van een SSD. Data lezen en schrijven op een SSD gaat per pagina. Maar om nieuwe data te schrijven, moeten de flashcellen eerst geleegd worden. Dat gaat weer enkel per blok.

TLC

Alle geteste SSD’s maken gebruik van MLC-geheugen, behalve de Samsung 840 Evo’s waarin we TLC vinden. Doordat bij TLC drie bits per geheugencel opgeslagen kunnen worden, is maar twee-derde van het chipoppervlak nodig om dezelfde capaciteit te bieden. Het is deze reden dat Samsung de 840 Evo’s zeer goedkoop in de markt kan zetten. TLC heeft echter twee nadelen: het biedt veel minder zogenaamde write cycles (lees: kan dus minder vaak overschreven worden) en is veel langzamer bij schrijfopdrachten.

Over dat eerste hoef je je bij normaal consumentengebruik geen zorgen te maken. Dat hebben we tijdens een uitvoerige test van ruim drie maanden begin 2013 al bewezen. Voor de lagere snelheid heeft Samsung een trucje bedacht: TurboWrite. Een gedeelte van het flashgeheugen wordt aangestuurd als zijnde SLC, dus met slechts één bit per cel. Dan kunnen schrijfopdrachten razendsnel verwerkt worden. Als de SSD idle is wordt data van de virtuele SLC-cache doorgezet naar normale, langzamere TLC-cellen. Het maakt wel dat de 840 Evo alleen maar snel is zolang de SLC-cache niet vol is. Bij normale consumententoepassingen komt dat zelden tot nooit voor. Wie de SSD zeer intensief belast kan daar wel tegenaan lopen, zoals ook onze 4k random write continutest aantoont. Meer info over TurboWrite vind je in onze oorspronkelijke Samsung 840 Evo test.

In Samsung 840 Evo SSD's vinden we TLC geheugenchips.