News Silicon Power: Neue PCIe-SSD P34A60 setzt auf HMB statt DRAM

[HaZweiOh]

Da nimmt man einfach eine Corsair MP510 und gut ist. Für billigen Schrott ist mir mein Rechner zu schade, und fehlenden Cache (so wie diese Geheimniskrämerei um den Controller) zähle ich dazu.

 

[Mega-Bryte]

@Wattwanderer

In der "Intelligenz" des Controllers vermute ich den Ansatz der Entlastung des restlichen Systems von der Koordination auch noch dieser Arbeiten. zumindest bei einem i3 oder anderen entsprechend "sparsamen" Prozessoren ist die Intelligenz durchaus wünschenswert, um für die restlichen Aufgaben / Prozesse ausreichend "Intelligenz" übrig zu haben.

Bei einem Octacore oder einem Server mit zwei Mutlicore-Xeons (6 oder mehr Kerne je CPU) erscheint aber auch mir hin und wieder die Rechenarbeit deutlich besser beim System aufgehoben. Ähnlich wird es ja bei Win-GDI-Druckern und SoftRAID gemacht.

 

[andi_sco]

nein ist hmb.. les den artikel..

find es trotzdem doof, da hätte ich angst um meine daten..

Vor was genau hast du Angst?

Ergänzung (16. Oktober 2019)

Was hat das mit meinem Post zu tun?

Weiß er selber nicht.

Ergänzung (16. Oktober 2019)

Die Frage ist doch: wie schnell ist der Puffer im Vergleich zu einem dedizierten DRAM, wenn:

a) alles in dem DRAM ausgeführt werden kann oder
b) die SSD erst beim Host um Ausführung in dessen Speicher anfragen muß?

...

Der Cache dient nicht als Zwischenspeicher für Daten! Der Cache dient als Inhaltsverzeichnis.

 

[bensen]

Du hast HBM statt HMB geschrieben, was etwas ganz anderes ist und nicht nur ein Zahlendreher. Normalerweise dürfte es auch DRAM sein, dies ist richtig, aber bei den neusten System könnte es auch 3D XPoint sein.

Ne. Ich hab gar nichts verwechselt. Einfach mal richtig lesen und nicht immer alles und jeden belehren wollen.

 

[Mega-Bryte]

Der Cache dient nicht als Zwischenspeicher für Daten! Der Cache dient als Inhaltsverzeichnis.

Und ich habe immer gelernt, dass im Cahce Daten abgelegt werden, wenn bspw. eine Triple Level Cell um einen Block befüllt wird. Dann wird nämlich der vorhandene Inhalt in den Cache gelesen, um den zusätzlichen Inhalt ergänzt und dann wieder Geschrieben.

Außerdem ist der Cache für das Wear Leveling durchaus interessant, egal, wo er sich befindet, im RAM des Systems oder im dedizierten RAM des SSD-Controllers.

 

[Mr.Baba]

Vor was genau hast du Angst?
...

Die Daten sind ne gewisse Zeit im Arbeitsspeicher und nicht auf der Festplatte. Zumindest versteh ich das so.

 

[andi_sco]

Und ich habe immer gelernt, dass im Cahce Daten abgelegt werden, wenn bspw. eine Triple Level Cell um einen Block befüllt wird. Dann wird nämlich der vorhandene Inhalt in den Cache gelesen
...

Ok
Du meinst aber geschrieben?

 

[Holt]

Der Cache dient nicht als Zwischenspeicher für Daten! Der Cache dient als Inhaltsverzeichnis.

Eben, deshalb braucht man da auch keine große Bandbreite, denn es wird ja dort nur gelesen oder geschrieben wo die Daten für eine bestimmte externe Adresse (LBA) im NAND stehen, mehr nicht. Wären dort viele Userdaten drin, würde man gewaltige Kondensatoren brauchen um diese bei einem unerwarteten Spannungsabfall nicht zu verlieren.

Und ich habe immer gelernt, dass im Cahce Daten abgelegt werden

Auch die Verwaltungsdaten wie die Mappingtabelle sind doch Daten, wenn auch keine Userdaten.

wenn bspw. eine Triple Level Cell um einen Block befüllt wird. Dann wird nämlich der vorhandene Inhalt in den Cache gelesen, um den zusätzlichen Inhalt ergänzt und dann wieder Geschrieben.

Nein, so funktioniert NAND nicht, keine Ahnung wer Dir diesen Mist erzählt hat. NAND wird blockweise gelöscht, aber pageweise (eine Page ist so z.B. 16k groß) gelesen und beschrieben und wenn eine Page beschrieben wurde, kann man deren Inhalt nicht mehr ändern, sondern muss erst den ganzen Block löschen zu dem die Page gehört und ein Block hat z.B. so 512 oder 1024 Pages.

Was Du da beschreibst erinnert an das Verhalten einer HDD mit Advanced Format, also physikalischen 4k Sektoren und emulierten 512 Byte Sektoren, bei der nicht alle 8 logischen Sektoren eines physikalischen Sektors überschrieben werden.

Außerdem ist der Cache für das Wear Leveling durchaus interessant, egal, wo er sich befindet, im RAM des Systems oder im dedizierten RAM des SSD-Controllers.

Nein, wie denn? Das Wear Leveling ist letztlich die Folge / Funktion des Algorithmus der auswählt wo Daten geschrieben werden und welche Blöcke als nächstes gelöscht werden sollen, denn bevor sie gelöscht werden, müssen ja alle noch gültigen Daten in leere Pages aus anderen Blöcken kopiert werden.

 

[Mega-Bryte]

aus dewr Speicherzelle wird erst mal gelesen und das kommt in den Cache … man könnte auch schreiben dazu sagen, aber man sagt ja auch: Das kommt in die Tüte und nicht das wird in die Tüte geschrieben! ^^

 

[Denniss]

Nochmal, bei einer SSD sind im Cache keine Nutzdaten, also Daten die im Dateisystem gespeichert wurden, sonder nur Adreßdaten welcher Datenblock in welcher Flashzelle vorhanden ist.

 

[Holt]

aus dewr Speicherzelle wird erst mal gelesen und das kommt in den Cache

Natürlich landen die Daten erstmal im Controller und dort i.d.R. in seinem SRAM welches jeder Controller hat (auch die ohne DRAM Cache), denn der Controller muss ja die ECC ausführen, also prüfen ob die Daten korrekt gelesen wurden, bevor er sie an den Host weitergibt. Da die Pages üblicherweise heutzutag so 16k groß sind und die ECC üblicherweise pro Page ist, werden auch bei Zugriffen über nur 4k dann 12k weitere Daten gelesen oder vielleicht auch mehr, was dann wie ein Read ahead Cache ist und vielleicht macht der Controller auch noch mehr Read ahead um in Benchmarks gut auszusehen und nutzt dann vielleicht auch einen Teil des DRAMs dafür, aber der primäre Zweck des DRAM Caches ist es die Verwaltungsdaten zu halten, vor allem die Mappingtabelle damit der Controller schnell feststellen kann wo die angeforderten Daten im NAND stehen und beim Schreiben, wo freie Pages sind in die er die Daten schrieben kann. Deshalb ist die Größe des DRAM Caches in aller Regel auch proportional zur Kapazität der SSD, da die Größe der Mappingtabelle eben auch proportional zur Kapazität der SSD ist.

 

[Mega-Bryte]

@Denniss
und wo legt das WearLeveling die Daten ab, die es umschichtet?

jetzt antworte bitte nicht mit "in einem anderen Cache", erklär es uns doch mal für Dummies, da du ja Bescheid zu wissen scheinst, wo wir alle versagen!

Selbst bei ner CPU gibt es Daten im Cache!

 

[Holt]

und wo legt das WearLeveling die Daten ab, die es umschichtet?

Die Frage zeigt, wie wenig Ahnung Du von SSDs hast. Das Wearleveling schicht doch nicht ständig Daten im NAND hin und her, es ist vielmehr das Ergebnis des Algorithmus der FW der Auswählt wo Daten geschrieben und welche Blöcke als nächstes gelöscht werden. Allenfalls das Refresh der Daten schreibt alte Daten mal neu in andere Pages, damit dies immer noch ordentlich und bei TLC NAND schnell gelesen werden können. Die Daten landen dann wieder im NAND und werden natürlich vorher in den internen Cache des Controller geladen und vielleicht auch DRAM Cache, aber wir reden da von dem Inhalt einer Page, also vielleicht 16k und nicht GB an Daten.

Selbst bei ner CPU gibt es Daten im Cache!

Den haben die Controller ja auch und da landen die Daten natürlich immer drin, wenn sie von gelesen wurden und bevor sie ins NAND geschrieben werden, aber wie wenig dort drin landen, sieht man schon daran das auch die DRAM less mit vielleicht 32MB internem Cache neben diesen Daten noch einen Teil der Mappingtabelle dort drin halten.

 

[Holt]

Anandtech hat die neuen Toshiba BG4 reviewt die auch DRAM less ist und dafür HMB verwendet und Effekt des HMB auf den working set size ermittelt, also den Adressraum über den zugegriffen wird:

Wie man sieht reicht der interne SRAM nur um so viel von der Mappingtabelle aufzunehmen, dass man damit über einen Adressraum von einem GB zugreifen kann, eben gerade so viel wie bei AS-SSD oder CrystalDiskMark in der Standardeinstellung verwendet wird. Mit HMB erhöht sich der Wert auf 32GB, denn schon wenn die Zugriffe über 48MB gehen, bringt er keinen Vorteil mehr und bei Zugriffen über 64GB bremst HMB sogar, eben weil es noch einen extra Overhead gibt um den HMB zu verwalten. Wenn man schaut wie groß eine vollständige Windows Installation ist, dann bringt es also gerade genug um bei Benchmarks mit der SSD als Systemlaufwerk mit frisch installiertem Windows zu helfen, aber wenn nach den Installation einiger Programme und einigen Windows Updaten die Zugriffe dann dauernd über einen Adressraum von mehr als 32GB erfolgen, dann bremst HMB eher als zu helfen und man hat im Alltag doch nur eine DRAM less SSD vor sich.

 

[Reflexion]

Ich persönlich finde derzeit die "Gigabyte NVMe SSD M.2 2280 1TB, M.2 (GP-GSM2NE3100TNTD)" am interessantesten vor allem weil 1,6TBW ne Hausnummer sind und dazu unabhängig von den 5J Garantie natürlich SLC frei..was auch logisch sein dürfte dass aber der Host Memory Buffer (HMB) keinen Mehrwert darstellt, finde ich eigenartig, gerade wenn man sich die hohen Durchsatz und IOPS ansieht, wenn der RAM (kommt vlt auch auf den RAM selbst an) das Nadelöhr ist, wie kann dann der Durchsatz gehalten werden, bzw wie lange ist der überhaupt geboten (?) Viele werden ja insgesamt nicht mehr als 16GB gesamt an RAM zur Verfügung haben. Vorteil wäre aber dass hier nichts kaputtgeschrubbt wird an Zellen.

 

[Holt]

Die TBW sind doch egal, wer schreibt schon innerhalb der Garantiedauer so viel auf seine SSD? Nach Ende der Garantie sind die TBW dann total egal, wenn sie kaputtgeht bevor die TBW erreicht wurden, schaut man sowieso in die Röhre. Die TBW sind nämlich nicht unabhängig von der Garantie, sondern nur ein zusätzliches Limit für die Garantie, die Garantie endet wenn die Zeit abgelaufen ist oder die TBW erreicht sind, je nachdem was zuerst eintritt.

Bei HMB (Host Memory Buffer) wird das RAM des Rechner genutzt um einen weiteren Teil der Mappingtabelle dort abzulegen, der Zugriff darauf ist immer noch schneller als wenn die aus dem NAND geladen werden muss. Allerding wird nur recht wenig RAM des Rechners genutzt und damit erreicht wie man im Post #54 zu sehen, dann eben das der Adressraum auf den recht schnell zugegriffen wird, etwas größer wird. Aber selbst die 32GB bis zu denen dies damit geht, sind halt für eine SSD mit 1TB nicht wirklich viel und eine Windows Installation kann schnell zu Zugriffen über einen viel größere Adressraum führen, dann nutzt das HMB auch nicht mehr wirklich was.