These: DRAM-Cache ist nicht effizient. Gegenbeispiel Direct Storage ?

[Micke]

Es gibt Laufwerke (SSD, NVME, etc. ) mit integriertem DRAM Cache. Die Größen gehen bis 4 GB.
MS Windows verwendet freien RAM (des Mainboards) automatisch als Cache. Linux bietet sicherlich ähnliche Feature. Dieser RAM ist grundsätzlich größer als der LW-integrierte. Die Mehrheit der Datenströme fließt letztendlich über diesen RAM. D.h. während ein LW-integrierter Cache nur seinen Host unterstützt, cached der MB-RAM alle Laufwerke.
Die Mehrkosten für den Cache eines Laufwerkes erscheinen mir daher nicht sinnvoll bzw. sind in MB-RAM besser angelegt. Laufwerke für einen NetzwerkSpeicher sind m.M.n. übrigens kein Sonderfall, denn auch diese werden über ein OS im Netzwerk angebunden. Das Thema Netzwerk unterstreicht eher die Vorteile eines zentralen Caches für alle Datenquellen.

Eine mögliches Gegenbeispiel stellt DirectStorage dar.
Dieses soll (mit Windows 11) das Laden von GPU Daten direkt vom Datenlaufwerk ermöglichen. Da dabei der MB-RAM umgangen wird, könnte der LW-integrierte Cache dort relevant sein. Allerdings stellt sich dadurch die Frage, ob DirectStorage selbst überhaupt ein attraktives Feature werden wird. Denn genau dessen adressierter großer Datentransfer zur GPU, wird einen großen Cache zu schätzen wissen. Z.b. sind Texturen, da sich wiederholend, sehr Cache geeignet.
Den größten Cache bietet aber der Weg über die CPU. Je größer dieser ist, umso schwerer dürfte es DirectStorage fallen sich zu behaupten ... und damit auch einem integrierten LW-Cache.

Danke für's Lesen, ist meine Herleitung richtig oder wo irre ich ?

 

[Holt]

Erstmal sind was Du NVMe nennst, auch SSDs, nur eben solche mit PCIe Interface und die das NVMe (statt des AHCI) Protokoll nutzen. Dann ist die ganze These Blödsinn, da der Sinn der DRAM Cache nicht ist als Datencache für Userdaten zu wirken, sondern da legt der Controller Verwaltungsdaten ab. Allen voran die Mappingtabelle also den Flash Translation Layer (FTL), also die Information wo die Daten im NAND stehen und wo NAND frei ist um dort schreiben zu können. Die SSDs ohne DRAM Cache halten dann immer einen kleinen Teil der Mappingtabelle im interen SRAM des Controller, genug um gut in den Benchmarks abzuschneiden die ja nur über ein oder weniger GB Adressraum benchen und daher tolle Werte ins Datenblatt schreiben zu können. Bei NVMe SSDs mit HMB ist es etwas mehr, aber der Zugriff darauf dauert auch länger und die Größe ist immer noch weit kleiner als das ideale Verhältnis von 1GB DRAM pro 1TB Kapazität. Wie man an diesem Beispiel sieht, reicht es dann für 32GB Adressraum statt nur 1GB ohne HMB:

Danach fallen die IOPS aber ebenso ab, eben weil erstmal ein langsamer NAND Zugriff nötig ist um den passenden Teil der Mappingtabelle zu laden, bevor die eigentlichen Daten aus dem NAND geladen werden können. Aber im Alltag reichen 32GB natürlich nicht, wer nutzt schon so wenig von der Kapazität seiner SSD, also muss der Controller dann ständig erstmal wieder den passenden Teil aus dem NAND nachladen, was eben viel länger als ein DRAM Zugriff dauert. Tomshardware hat mal mehrere solcher DRAM less SATA SSDs getestet und schreibt im Fazit:

It's true that the drives are faster than a hard disk drive, but when you lean on them with a slightly elevated workload, they can stall, stutter, and deliver a worse user experience than you would get with a spinning mechanical disk.

 

[Micke]

Erstmal habe ich es These genannt. Eine These ist entweder richtig oder falsch. Nichts anderes.
Ansonsten ist der LW-Cache also nicht zu groß, sondern im Gegenteil i.d.R. zu klein ... interessant, danke.

 

[Holt]

Ansonsten ist der LW-Cache also nicht zu groß, sondern im Gegenteil i.d.R. zu klein

Nein, woraus hast Du das abgelesen? Die ideale Größe scheint 1GB DRAM pro 1TB Kapazität zu sein und viele SSDs haben genau so viel DRAM Cache verbaut. Weniger DRAM Cache hat Nachteile, entweder passt nicht die ganze Mappingtabelle rein, man muss die Datenstrukturen anderes wählen was langsamere Zugriffe bedeutet oder die "Auflösung" verringern, also nicht mehr alle 4k genau finden können, was die übliche Clustergröße z.B. bei Windows NTFS ist, sondern man könnte auch z.B. 128k nehmen, dann braucht man nur noch 1/32 des RAMs, aber es müssen dann immer alle Daten in einem Adressraum von 128k an definierten Stellen "hintereinander" im NAND stehen und wenn auch nur 4k dieser 128k geändert werden, muss man trotzdem den Rest mit umkopieren, was die WA massiv erhöht und die Schreibgeschwindigkeit bei zufälligen Schreibzugriffen senkt.

 

[Micke]

Die SSDs ohne DRAM Cache halten dann immer einen kleinen Teil der Mappingtabelle im interen SRAM des Controller, genug um gut in den Benchmarks abzuschneiden die ja nur über ein oder weniger GB Adressraum benchen und daher tolle Werte ins Datenblatt schreiben zu können. Bei NVMe SSDs mit HMB ist es etwas mehr, aber der Zugriff darauf dauert auch länger und die Größe ist immer noch weit kleiner als das ideale Verhältnis von 1GB DRAM pro 1TB Kapazität

das suggerierte, daß das Verhältnis bei einigen SSDs nicht optimal ist, sprich der Cache ist unterdimensioniert.

 

[Holt]

Nein, da ging es um das interne SRAM des Controllers, jeder Controller hat auch ein SRAM, oft 32MB oder so und dazu haben die guten Controller eben noch den externen DRAM Cache, dies sind also zwei unterschiedliche RAMs und das interne SRAM ist eben immer zu klein um einen externen DRAM Cache zu ersetzen. Bei manchen wird bei Geizhals übrigens die Größe des internen SRAMs als DRAM Cache angegeben, aber die Angaben bei Geizhals sind bekanntlich voller Fehler und wenn da was von 32MB DRAM Cache steht, weißt Du jetzt das dies kein DRAM Cache ist, sondern das interne SRAM des Controllers.

 

[Micke]

Danke für die Ausführlichkeit @Holt, verstanden.