SaschaHa schrieb:
Bei QLC müssen gegenüber TLC doppelt so viele Ladungsniveaus unterschieden werden. Da der Spielraum dort ohnehin schon sehr gering ist und auch Ladungen mit der Zeit abnehmen bzw. sich ändern, werden die Schwellwerte dort deutlich schneller erreicht.
Du beschreibst die Hintergründe des technischen Problems, aber die Schlussfolgerung, dass die Haltbarkeit (nicht im Sinne von wie-oft-überschreiben, sondern im Sinne der Ladungslevel zwischen den Unterscheidungsgrenzen) deswegen im Lebensraum des Produktes nicht gehalten werden kann, ist falsch. Denn du müsstest eigentlich betrachten, um
wieviel ändert sich das Ladungsniveau
in welchem Zeitraum und
was der Controller dagegen macht, also z.B. in welchen Intervallen auffrischt.
Daher zu behaupten, dass eine QLC-SSD in ihrem Lebenszyklus plötzlich falsche Ladungslevel in den Zellen hat, ohne dass dies vom Laufwerk korrigiert werden kann, ist schlichtweg falsch. Keiner der Systemausrüster oder Storageanbieter würde in einem solchen Fall diese Technik verwenden. Also müsstest du dir eigentlich überlegen, ist das Problem denn wirklich so stark, dass es zu dem führt, was du vermutest?
Über deine anderen beiden Irrtümer hat bensen ja schon geschrieben. Stichwort Lesegeschwindigkeit: da hast du die Geschwindigkeit von dir bekannten Endprodukten abgeleitet, die im normalen Markt bei QLC eher preissensitiv und daher nicht unbedingt mit den leistungsfähigsten Controllern ausgestattet sind. Daraus auf QLC abzuleiten war ein Fehlschluss.
Möglicherweise steckt zwar noch mehr Potenzial bei der Lesegeschwindigkeit von QLC-SSDs, da man dort keine High-End-Controller verbaut, aber warum sollte man davon ausgehen, wenn nichts darauf hindeutet und es physikalisch schwieriger sein dürfte, 16 anstatt 8 Spannungszuständen zu unterschieden?
Offenbar denkst du, dass
all das was das Schreiben langsamer macht, auch beim Lesen der Fall ist. So ist es aber nicht. Beim Lesen misst du das Ladungslevel. Klar, dass Messfenster ist kleiner geworden. Aber beim Schreiben musst du vorher die Zelle löschen und dann beim Schreiben das richtige Ladungslevel treffen. Bitte lies hier mal die letzten 7 Absätze ab "When you program a cell"...
https://www.anandtech.com/show/5067/understanding-tlc-nand/2
Ist zwar aus der TLC-Ära, aber es wird für Laien relativ gut beschrieben, was beim Löschen einer Zelle und beim Schreiben im Vergleich zum Lesen anders ist. Denn der Controller kennt ja den wear out einer Trennschicht nicht oder wieviel Restladung in der Trennschicht ist. Diese Faktoren führen zu einer Abweichung von dem, was der Controller eigentlich an Ladungslevel in die Zelle bringen will. Und dass muss korrigiert und kompensiert werden, und zwar umso genauer, je mehr Bit pro Zelle unterschieden werden sollen. Das macht Löschen und Schreiben langsamer. Ja, auch beim Lesen steigt die benötigte Zeit etwas, aber nicht soviel wie beim Schreiben. Für
möglichst große Lesebeschleuniger ist schneller Controller plus QLC eine gute Kombination, aber halt nicht auf dem Endkundenmarkt, sondern eher für die Ausrüster.
Dann hattest du mit viel Worten beschreiben, dass TBW sich auf beschriebene Zellen beziehen würde. Nein, es bleiben nicht nur noch 88 statt 400 am Laufwerk eingereichte TBW übrig. TBW berücksichtigt die von dir beschriebene Mehrfachnutzung (erst komplette Schreibmenge im SLC-Modus geschrieben und später in anderen Zellen im QLC-Modus nochmal programmiert). Warum? Weil dir sonst der OEM den Arsch wegklagt. Es ist wie mit dem Mehrverbrauch durch die Write Amplification. Wenn dir als SSD-Hersteller der NAND-Hersteller 1000 P/E-Cycles pro Zelle zusichert, dann sicherst du nicht als SSD-Hersteller 1000*Anzahl der Zellen*4(bei QLC) in der TBW-Angabe zu, sondern ziehst massiv Marge für Write Amplification und SLC-Cache Transfers ab. (Was auch bei deinen Beispiel SSDs gemacht wurde.)
Was auch immer das heißen soll.
(auf bensons Aussage hin, dass Write Amplification bereit berücksichtigt ist)
Write Amplification sind zusätzliche Schreibvorgänge, die z.B. dann entstehen, wenn Pages zwischen Blöcken umorganisiert werden müssen. In einem Block befinden sich mehrere Pages. Du kannst jede Page einzeln lesen und programmieren (schreiben). Beschreiben aber nur, wenn die Page leer ist, also noch nie beschrieben wurde oder gelöscht wurde. Löschen kannst du aber nur Blockweise. Wenn also in einem Block Pages mit noch benötigten Daten sind und andere Pages mit gelöschten Daten (wenn von z.B. via TRIM als frei gemeldet), muss der ganze Block gelöscht werden, damit die nicht mehr benötigten Pages neu beschrieben werden könnten. Die pages mit noch aktuellen Daten werden daher in einen freien Block umkopiert und der alte Block dann gelöscht. Auch Garbage Collection gehört mit in dieses Thema rein und all diese zusätzlichen write-programmierungen, welche nichts mit User Schreibvorgängen oder SLC-Cache zu TLC-Cache-Transfers zu tun haben, fallen unter write amplification, die es schon gab, bevor man SLC-Caches wegen Multi-Bit-Zellen benötigt hat. Der Ausmaß der Write Amplification ist um ein vielfaches schwerer vorherzusagen, weil es davon abhängt, wie hoch der Anteil der Random Writes beim Nutzerverhalten ist. TBW deckt das alles dennoch mit ab und ist sehr konservativ berechnet. Man erinnere sich an die Tests von diversen Seiten, die gemessen haben, nach wie vielen TBW die Test-Laufwerke aufgegeben haben und die beworbenen Werte um ein Vielfaches übererfüllt wurden.
