SSD Cache Verständnisfragen, DRAM-less, SLC Pseudo-Cache, HMB und Mischung dessen

[m.fessler]

Hallo,

ich hätte da mal einige Verständnisfragen bezüglich SSD Cache, dessen Inhalt und Funktion.

Wenn ich das richtig verstanden habe, wird im DRAM Cache, anders als oft angenommen, keine "Nutzerdaten" sondern die Mapping-Tabelle (FTL) gespeichert - Nutzerdaten werden direkt in die Flash Speicher gespeichert.

Bei SSDs komplett ohne Cache muss diese Tabelle immer wieder direkt von den Zellen gelesen und geschrieben werden, was neben der Lebensdauer vor allem mächtig auf die Schreibrate geht.

SSDs mit SLC Pseudo-Cache sprechen einen Teil des freien Speicherplatzes im SLC "Modus" an um die Daten schnell zwischenspeichern zu können um sie später in die langsameren TLC oder gar QLC Zellen zu verschieben.
Der Grund für diesen Pseudo-Cache ist aber in erster Linie die verringerte Schreibrate gerade bei QLC Zellen, weniger die allgemeine Beschleunigung im Vergleich zu einer DRAM-less SSD mit TLC Zellen - richtig?

Was ist nun aber mit der Mapping Tabelle?
Befindet sich die zumindest teilweise auch im Pseudo Cache vorgehalten?

Je nachdem wären solche SSDs dann ja nämlich nicht "nur" im typischen Anwendungsfall von großen Dateien welche den Pseudo Cache "überschreiten" sondern auch bei sehr vielen kleinen Dateien (viele Zugriffe auf die Mapping-Tabelle) deutlich langsamer.

Und wie sieht es eigentlich bei HMB (Host-Memory-Buffer) aus?
Was ist da im Speicher des Hosts?
Allzu viel Nutzerdaten werden es wohl nicht sein dürfen - schon aufgrund eines möglichen Stromausfalls - nicht?

Danke schon mal für jeden Hinweis der etwas Licht in die Sache bringt.
Gruß,
Martin

 

[Rickmer]

Der Grund für diesen Pseudo-Cache ist aber in erster Linie die verringerte Schreibrate gerade bei QLC Zellen, weniger die allgemeine Beschleunigung im Vergleich zu einer DRAM-less SSD mit TLC Zellen - richtig?

SLC-Cache kommt auch bei TLC bei den meisten üblichen SSDs zum Einsatz
Eine MLC-SSD die auf SLC-Cache zurückgreift wäre mir spontan nicht bekannt.

Was ist nun aber mit der Mapping Tabelle?
Befindet sich die zumindest teilweise auch im Pseudo Cache vorgehalten?

Ich glaube das kann dir nur ein SSD-Hersteller sagen, das wird wohl auch mit jedem Controller und der Firmware anders sein...

Und wie sieht es eigentlich bei HMB (Host-Memory-Buffer) aus?
Was ist da im Speicher des Hosts?
Allzu viel "Nutzungsdaten" werden es wohl nicht sein dürfen - schon aufgrund eines möglichen Stromausfalls - nicht?

Da ist auch die Mapping-Tabelle drin, genau wie auch beim onboard DRAM
Der HMB ist langsamer als onboard DRAM, aber schneller als die Mapping-Tabelle aus dem NAND laden.

Das muss sowieso alles auf NAND gespiegelt sein, egal ob der DRAM jetzt onboard ist oder NVMe Protokoll dem Host abgezwackt wird.

Ich würde mich wundern wenn Intel nicht HMB auf der 660p einsetzt, um die Nachteile von den unterdimensionierten 256MB DRAM auszugleichen, und dann immer nur die akutell benötigten Daten im onboard DRAM haben. Ein Ja/Nein dazu konnte ich allerdings grade nicht auf die Schnelle finden.

(Und da HMB das NVMe Protokoll nutzt wird das folglich auch nicht bei den günstigen SATA-SSDs verwendet, geht ja nicht.)

 

[Baal Netbeck]

Wenn ich das richtig verstanden habe, wird im DRAM Cache, anders als oft angenommen, keine "Nutzerdaten" sondern die Mapping-Tabelle (FTL) gespeichert - Nutzerdaten werden direkt in die Flash Speicher gespeichert.

Woher hast du diese Info?

Das würde ich stark bezweifeln....warum sollten dann 512 bis 2GB DRam cache verwendet werden, wenn da bloß ne Mapping Tabelle reingeschrieben wird?

So wie ich das immer verstanden habe ist der DRam Cache vor allem ein Datenpuffer, der erstmal die zu schreibenden Daten auffängt während sie von da aus in den Flash Speicher sortiert werden.

So sieht man ja bei den Billig SSDs, ohne DRam Cache, dass diese beim Lesen praktisch gleich schnell sind, aber beim Schreiben extrem einbrechen.

 

[Rickmer]

Woher hast du diese Info?

Eine gute Erklärung dazu und zum HMB kannst du hier nachlesen:

https://www.anandtech.com/show/12819/the-toshiba-rc100-ssd-review/2

 

[Holt]

Wenn ich das richtig verstanden habe, wird im DRAM Cache, anders als oft angenommen, keine "Nutzerdaten" sondern die Mapping-Tabelle (FTL) gespeichert - Nutzerdaten werden direkt in die Flash Speicher gespeichert.

SSD haben auch einen Schreibcache für Nutzerdaten, aber dies ist nicht der DRAM Cache oder allenfalls ein kleiner Teil von ihm.

Bei SSDs komplett ohne Cache muss diese Tabelle immer wieder direkt von den Zellen gelesen und geschrieben werden, was neben der Lebensdauer vor allem mächtig auf die Schreibrate geht.

Die Controller haben neben dem DRAM Cache auch einen internen SRAM Cache, beim Phison S11 sind es 32MB die bei einigen SSDs im Preisvergleich fälschlich als als DRAM Cache ausgegeben werden und da können sie auch einen Teil der Mappingtabelle ablegen, meist genug für einen Adressraum von 1GB, eben um in Bechmarks wie CDM oder AS-SSD die üblicherweise über einen Adressraum von einem GB benchen, gut auszusehen und hohe Werte in die Datenblätter schreiben zu können.

Der Grund für diesen Pseudo-Cache ist aber in erster Linie die verringerte Schreibrate gerade bei QLC Zellen, weniger die allgemeine Beschleunigung im Vergleich zu einer DRAM-less SSD mit TLC Zellen - richtig?

Im Prinzip hat der Pseudo-SLC Cache nichts mit dem DRAM Cache des Controllers zu tun, da der Pseudo-SLC Schreibcache eben zum Schnelleren Schreiben der Daten da ist und bei SLC sogar zum schnelleren Lesen.

Was ist nun aber mit der Mapping Tabelle?
Befindet sich die zumindest teilweise auch im Pseudo Cache vorgehalten?

Es ist anzunehmen das auch für die Mappingtabelle eine Pseudo-SLC Cache im NAND benutzt wird um diese schneller Schreiben zu können, aber mehr Berührungspunkte gibt es da nicht.

Je nachdem wären solche SSDs dann ja nämlich nicht "nur" im typischen Anwendungsfall von großen Dateien welche den Pseudo Cache "überschreiten" sondern auch bei sehr vielen kleinen Dateien (viele Zugriffe auf die Mapping-Tabelle) deutlich langsamer.

Die sind immer deutlich langsamer, wenn die Zugriffe über einen Adressraum gehen der größer ist als der für den Teil der Mappingtabelle den sie im internen SRAM halten können, wenn also wieder andere Teile der Mappingtabelle aus dem NAND nachgeladen werden müssen. Dies dauert eben viel länger als ein RAM Zugriff auf den DRAM Cache.

Und wie sieht es eigentlich bei HMB (Host-Memory-Buffer) aus?
Was ist da im Speicher des Hosts?
Allzu viel Nutzerdaten werden es wohl nicht sein dürfen - schon aufgrund eines möglichen Stromausfalls - nicht?

In dem RAM des Hosts ist nur ein Teil der Mappingtabelle, da sind keine Userdaten drin und auch der Teil der Mappingtabelle der dort steht, ist so auch schon im NAND gespeichert, so dass bei Verlust des RAM Inhalts kein Datenverlust auftritt. Der HMB ist aber auch nicht so, dass es ein Ersatz für einen DRAM Cache wäre, wie man hier im Review der BG4 bei Anandtech sieht, vergrößert er den Bereich der des Working Set (also den Adressraum für den die Mappingtabelle in RAM liegt und nicht erst aus dem NAND geladen werden muss) von 1GB auf 32GB, also ungefähr den Bereich den eine Windows Installation so belegt.

SLC-Cache kommt auch bei TLC bei den meisten üblichen SSDs zum Einsatz
Eine MLC-SSD die auf SLC-Cache zurückgreift wäre mir spontan nicht bekannt.

OCZ und Toshiba hatten dies, aber auch die Crucial MX200 (wenn auch nicht bei allen Modellen) besaß einen Pseudo-SLC Schreibmodus, einen festen Pseudo-SLC Schreibcache gab es bei denen allen aber nicht, allerdings haben die aktuellen SSD mit TLC und QLC NAND neben einem kleinen festen Bereich einen sehr viel größeren dynamischen Pseudo-SLC Cache.

Ich würde mich wundern wenn Intel nicht HMB auf der 660p einsetzt, um die Nachteile von den unterdimensionierten 256MB DRAM auszugleichen

Nein, die 660p hat keinen HMB, der wäre auch kleiner als der eigene DRAM Cache und daher sinnfrei, die 256MB DRAM Cache scheinen bei ihr aber deutlich weniger schmerzhaft für die Performance zu sein als die paar MB bei den wirklich DRAM less SSDs.

Woher hast du diese Info?

Das würde ich stark bezweifeln....warum sollten dann 512 bis 2GB DRam cache verwendet werden, wenn da bloß ne Mapping Tabelle reingeschrieben wird?

Die Information ist aber korrekt und von blos kann auch nicht die Rede sein, die Verwaltungsdaten sind ein zentrales Element für den Controller einer SSD, die muss da nämlich immer nachschauen wo die Daten im NAND liegen und ebenso wo freie NAND Pages sind in die sie schreiben kann. Die Mappingtabelle macht den größten Teil der Verwaltungsdaten aus und deren Größe ist eben proportional zur Kapazität der SSD, welches eben auch in aller Regel die Größe des DRAM Caches proportional zur Kapazität der SSD ist.

So wie ich das immer verstanden habe ist der DRam Cache vor allem ein Datenpuffer, der erstmal die zu schreibenden Daten auffängt während sie von da aus in den Flash Speicher sortiert werden.

Und aufgrund welches Information hast Du dies so verstanden? Es gibt auch einen Schreibcache für die Daten, sogar die DRAM less packen ein paar Daten in den knappen SRAM des Controllers, aber es wäre doch gefährlich und sinnlos 1GB Daten im Cache zu halten.

One notable characteristic of this old controller was that it never required a large external DRAM (16 - 64MB for the early drives). Intel was proud of the fact that it stored no user data in DRAM], which I always assumed kept the size requirements down. It turns out there was another reason.

All controllers have to map logical block addresses to physical locations in NAND. This map is stored on the NAND itself (and wear leveled so it actually moves locations), but it's cached in DRAM for fast access. Intel calls this map its indirection table.

So sieht man ja bei den Billig SSDs, ohne DRam Cache, dass diese beim Lesen praktisch gleich schnell sind, aber beim Schreiben extrem einbrechen.

Beim Lesen sind sie nur gleichschnell, solange nicht über einen Adressraum gelesen wird der außerhalb der Mappingtabelle liegt.