die guten SSDs haben ja eine Kombination aus DRAM und SLC Cache.
Das eine hat mit dem anderen nichts zu tun! Der DRAM Cache ist für die Verwaltungsdaten des Controllers, vor allem die Mappingtabelle. Der Pseudo-SLC Schreibcache ist für die Steigerung der Schreibrate, die eben bei TLC und erst recht QLC NAND nicht so toll ist wie vorher bei MLC NAND und den haben eben auch alle Consumer SSDs. Es gibt ja keine mehr die nicht TLC oder QLC haben und gewissermaßen könnte man sagen, die guten SSDs haben keinen Pseudo SLC Schreibcache, denn die haben entweder noch MLC, SLC oder 3D XPoint (also die Intel Optane) oder sind Enterprise SSDs.
Man sollte eher sagen, dass gute SSDs eben einen RAM Cache haben, die Optane ausgenommen, die haben keinen aber dafür ein Medium welches kaum langsamer als DRAM ist und am Besten im Verhältnis von 1GB DRAM zu 1TB Kapazität.
Du merkst aber auch definitiv einen Unterschied wenn du ne VM auf z. B auf einer SSD mit DRAM laufen lässt und die in die in den swap/virtuellen Speicher arbeiten muss.
Klar, denn dann wird über einen großen Adressbereich zugegriffen und hier macht der DRAM Cache dann den Unterschied und zwar nur hier, wenn nur über einen kleinen Adressraum zur Zeit zugegriffen wird, dann können sich die DRAM less SSDs noch gut behaupten. Meist reicht der Teil der Mappingtabelle im internen SRAM des Controllers für einen Adressraum von 1GB und der im HMB für 32GB, passieren die Zugriffe nur innerhalb dieses Adressbereichs, so braucht der Controller ja nie andere Teile der Mappingtabelle nachladen und genau das dauert eben und senkt die Performance. An dieser Stelle kann ich nur wieder den Benchmark von Anantech für die 4k IPOS über unterschiedlich große Adressbereich mit und ohne HMB von der BG4 verweisen:
Einen neueren Benchmark dieser Art kenne ich leider nicht, aber man sieht das über 1GB die Performance gleich ist, denn passt ja der nötige Teil der Mappingtabelle ins SRAM des Controllers. Bis 32GB verhält sich die SSD mit HMB ähnlich wie SSDs mit DRAM Cache, ohne HMB fällt sie hingegen schon. Warum sie von 2GB bis 16GB gleich bleibt kann ich nicht sagen, eigentlich sollte man erwarten das sie da auch schon abfällt, denn je größer der Adressraum wird über den die Zugriffe erfolgen, umso unwahrscheinlich wird es das passende Teil der Mappingtabelle zufällig gerade im SRAM oder HMB gecacht ist und dies sieht man dann auch mit HMB wenn über einen Adressraum von mehr als 32GB zugegriffen wird.
Das die Performance mit HMB bei mehr als 32GB sogar minimal schlechter als ohne HMB ist, dürfte der Cacheverwaltung geschuldet sein, denn die verzögert ja zusätzlich und je größer ein Cache ist, umso länger dauert es tendenziell rauszufinden ob die Daten im Cache stehen. Dies hängt aber von der Datenstruktur ab. Optimal ist eine flache Tabelle, wie Intel sie damals mit der 730 eingeführt hat, als sie erstmal Wert auf eine konstante Performance gelegt haben und dafür braucht man dann eben 1GB DRAM Cache pro 1TB Kapazität, während man mit anderen Datenstrukturen Platz sparen kann, aber eben Zeit bei der Suche verliert. Im SRAM dürfte nicht einmal genug Platz sein um so eine Tabelle für die Cacheinhalten zu haben, was auch logisch ist, denn wenn man 1TB oder gar 2TB Kapazität hat, wäre die Tabelle sehr groß und sehr, sehr leer, wenn man nur genug HMB Cache für 32GB hat. Wenn jeder Datenblock der Mappingtabelle genug für Daten für 1GB Adressraum hat, bräuchte man eine Tabelle für 1000 bzw. 2000 Einträge von denen nie mehr als 32 belegt sind und wäre z.B. ein b-tree besser, schon weil er viel platzsparender ist.
Aber eben anderes als der Pseudo-SLC Schreibcache hat der DRAM Cache nicht viel mit der Schreibperformance zu tun, außer dass der Controller eben schauen muss wo er freie NAND Pages zum Beschreiben hat und diese Information schlimmstenfalls bei einer DRAM less SSD auch aus dem NAND laden muss. Aber kurze zufällige Schreibzugriffe werden eben normalerweise im internen SRAM (auch bei den SSDs mit DRAM Cache) gepuffert bis genug Daten für eine NAND Page zusammengekommen sind und die werden dann im Hintergrund weggeschrieben und dann fällt es genau wie bei langen Zugriffen nicht so ins Gewicht wenn auch mal ein NAND Zugriff auf die Verwaltungsdaten erfolgen muss. Zumal auch die SSDs mit DRAM bei Schreibzugriffen regelmäßig ihre Verwaltungsdaten im NAND aktualisieren, denn die will man bei einem unerwarteten Spannungsverlust ja nicht alle verlieren. Enterprise SSDs mit Full-Power-Loss Protection können sich das sparen, keine Ahnung ob sie das auch machen.
SLC Cache ist sowieso die falsche Bezeichnung, denn es gibt kein SLC NAND bei diesen SSDs, sondern nur Pseudo-SLC, also TLC oder QLC NAND bei dem eben nur ein Bit beschrieben wird, genau wie bei SLC NAND und dies geht schneller und braucht weniger Energie als alle 3 oder 4 Bit zu beschreiben. Es ist auch immer nur ein Schreibcache, wogegen die Controller normalerweise keine Userdaten im DRAM Cache speichern, im Gegensatz zu HDDs, aber bei denen ist das DRAM in aller Regel auch das RAM des Controllers, die haben normalerweise kein internes SRAM und nutzen auch nur ein Teil des DRAM als Datencache, meist nur einen recht kleinen Teil. Dies hindert die Hersteller aber natürlich nicht daran dessen volle Kapazität als Cache anzugeben und während Hitachi früher noch angegeben hat wie viel davon wirklich als Cache genutzt wurde, sucht man diese Angabe heutzutage meist vergeblich.
