Eigentlich will ich ja Leuten auf meiner IL nicht antworten, aber den Mist kann man so nicht stehen lassen, sonst glaubt das noch jemand!
Das stimmt sogar, bis zu einem gewissen Punkt und hat eigentlich so nur Gültigkeit bei Sata SSDs die noch nicht über das NVMe Protokoll verfügen.
SAT SSDs können das NVMe Protokoll nicht verwenden, weil dies einen nativ PCIe angebundenen Controller verlangt. SATA SSDs nutzen das AHCI Protokoll.
Denn dort war es so, dass die L2P Einträge (allgemein auch FTL (Flash Translation Layer) Mappingtabelle genannt) direkt im NanD gespeichert wurde.
Die Mappingtabelle steht bei jeder SSD im NAND, die wird bei denen mit DRAM Cache ja auch nur in diesem DRAM Cache gecacht und Veränderungen werden zeitnah ins NAND geschrieben. Auch der HMB ist nur ein Cache, aber eben nur ein recht kleiner Cache in dem der Controller einen Teil der Mappingtabelle ablegen kann.
Dazu kommt, dass HMB fester Bestandteil des NVMe Protokolls ist, auch bei DRam_cached M2 NVMe SSD vorhanden ist und den Controller anweist, einen dedizierten Speicherbereich des Host ausschließlich für den Memory Buffer zu Verfügung zu stellen.
Aber wie man im Bild sieht, nutzen Controller keinen HMB, wenn sie einen vollen DRAM Cache haben. Wozu sollten sie das auch, der Zugriffs auf eigene DRAM dürfte immer noch schneller sein als über den Umweg von PCIe zur CPU zum RAM des Hosts und wieder zurück über die CPU und PCIe zum SSD Controller zu gehen. Das ist zwar immer noch schneller als ein NAND Zugriff, aber eben langsamer als ein Zugriffs auf den eigenen DRAM Cache.
Also nicht der SSD Controller, erst recht nicht die SSD FW. muss das unterstützen
Doch, die müssen das natürlich auch unterstützen, aber das machen die DRAM Less NVMe Controller alle.
Im Gegensatz zu der gnadenlos veralteten Pseudo "HMB" Technik zu Sata SSD Zeiten
Es gibt für SATA keine Pseudo HMB Technik, sondern da steht nur ein kleiner Teil der Mappingtabelle, meist gerade genug für einen Adressraum von 1GB, im internen SRAM des Controllers und genauso ist es auch NVMe SSDs, denn ich bezweifele das sie in einem USB Gehäuse von dessen Bridgechip auch einen HMB zur Verfügung gestellt bekommen. Das muss der Host nämlich nicht machen, auch wenn du das so meinst, auch wenn StoreNVMe von Windows dies bei Win 10 natürlich unterstützt.
Bei den DRAM less SATA SSDs kommt oft noch erschwerend hinzu, dass die DRM Less Controller so abgemagerte Sparversionen sind, dass sie teils nur 2 NAND Channels haben und wenn die dann mit einem anderen Zugriff belegt sind, wird es noch lahmer, erst recht wenn der andere Zugriff dann auch noch auf das gleiche NAND Die erfolgt wo auch der nötige Teil der Mappingtabelle steht, was umso wahrscheinlicher wird je kleiner die Kapazität der SSD und je größer die Diesize des NAND sind. Daher geht es noch halbwegs solange nur ein Zugriff zur Zeit erfolgt, aber je mehr parallele Zugriffe es gibt, umso lahmer werden sie, sofern die Zugriffe eben über einen größeren Adressraum erfolgen und größer heißt da eben schon mehr als 1GB. Bei DRAM less NVMe SSDs ist es im Prinzip genauso, aber mit HMB kann der Adressraum eben größer seien, dazu haben die Controller meist wenigstens 4 NAND Channels, die SSDs mehr Kapazität und die aktuellen NANDs haben heute meist eine geringere Latenz, schon weil sie schnellere Interfaces besitzen.
da dass ein fester Bestandteil des NVMe Protokoll ist, sondern der jeweilige Host muss die Anfragen des Controllers supporten.
Nein, denn HMB erst mit der NVMe Revision 1.2 eingeführt und alle Systeme (also z.B. NVMe Treiber) die noch eine ältere Revision unterstützen, können es damit sowieso nicht. Wäre es Pflicht, gäbe es keine Abwärtskompatibilität.
Im Grunde ist HMB schon fast einer DRam_Cache SSD ebenbürdig bzw. sind die Nachteile mittlerweile so marginal, dass man in der Praxis schon fast gar keinen Unterschied mehr bemerkt.
Ebenbürtig sind sie SSDs mit vollem DRAM Cache sicher nicht, aber es kann schon, je nach Nutzung, sein, dass man den Nachteil im Alltag kaum merkt. Die NAND Zugriffe sind halt langsamer als Zugriffe auf den eigenen DRAM Cache oder den HMB, der aber meist auch nicht größer als 64MB ist, je nach Modell und zuweilen ist er auch kleiner. Je nach Architektur der Mappingtabelle reicht das meist für 1GB Adressraum pro 1MB, wie man auch hier am Beispiel der GB4 im Review bei Anandtech sieht, wo es für 32GB Adressraum reicht:
Sobald die Zugriffe über einen größeren Adressraum verteilt erfolgen, fällt die Performance eben ab, weil dann immer wieder erst der passende Teil der Mappingtabelle aus dem NAND nachgeladen werden muss und die je größer der Adressraum wird, umso geringer wird die Hitrate des internen SRAM oder HMB Caches und daher fällt die Performance umso weiter ab. Zum Vergleich die 970 EVO Plus mit vollem DRAM Cache:
Hier hat man eine gerade Linie, da die Zugriffszeit immer gleich ist, egal auf welche Adresse zugriffen sind, da die ganze Mappingtabelle im DRAM gecacht ist.
Klar macht das bei kurzen Zugriffen wie hier im Test von je 4k viel mehr aus als bei langen Zugriffen, weshalb das im Alltag oft nicht so bemerkbar ist, aber es gibt eben einen Unterschied.
www.hardwareluxx.de
