Unterstützung NVMe-Protokoll (Auch: Unterstützung HMB [Host Memory Buffer])

samagada

Profi
Thread Starter
Mitglied seit
24.10.2021
Beiträge
27
Hey,

wie kann ich überprüfen, ob ein System grundsätzlich eine NVMe (z.B. 1.3, 1.4, 2.0,..) Version unterstützt? Ist das rein von der SSD und dem Betriebssystem abhängig (wie hier [von Cygnus1 im Kommentarbereich der NVMe 1.4 Spec] suggeriert)? Ist das doch auch abhängig von Treibern (wie hier [mit dem Solidigm Synergy Toolkit] suggeriert) oder gar Firmware/UEFI?

Im Forum fand ich nur folgendes Thema anknüpfend, aber nicht klärend:

Danke und viele Grüße
 
Ist das rein von der SSD und dem Betriebssystem abhängig
Ja.

Ist das doch auch abhängig von Treibern
Das ist ja im erweiterten Sinne Teil des Betriebssystems und ganz direkt, wenn man den nimmt er beim OS dabei ist und bei NVMe hat man ja kaum Alternativen.

oder gar Firmware/UEFI?
Die UEFI muss meines Wissens nach nur das NVMe Protokoll unterstützen um von einer NVMe SSD booten zu können, danach hat es damit nichts mehr zu tun. Das UEFI muss ja auch nicht jedes Feature anderer PCIe Geräte wie z.B. der Graka unterstützen, um diese nutzen zu können.
 
Ist das rein von der SSD und dem Betriebssystem abhängig
Mehr vom jeweiligen OS aber ja, da muss die Synchronisation schon passen.

Ist das doch auch abhängig von Treibern (wie hier [mit dem Solidigm Synergy Toolkit] suggeriert) oder gar Firmware/UEFI?
Eher nein. Die Treiber stellen nur die generelle "Funktionsweise" der SSD zu Verfügung inkl. vieleicht noch marginalen Optimierungspotential, dass UEFI die Kompatibilität zb. als Bootmedium.

Im Forum fand ich nur folgendes Thema anknüpfend, aber nicht klärend:
Ja, HMB und der Äpfel mit Birnen Vergleich. :rolleyes:

Allgemein wird ja immer von bestimmter Userseite her behauptet, dass DRam_less SSD im Random 4k Access wesentlich langsamer werkeln als SSDs mit DRam Cache.
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. Denn dort war es so, dass die L2P Einträge (allgemein auch FTL (Flash Translation Layer) Mappingtabelle genannt) direkt im NanD gespeichert wurde. Das hat man dann auch bei Sata SSD sofort bemerkt, denn gerade im 4K Zugriff hatte man da u.U. Verzögerungszeiten (tR) jenseits von gut und böse, da dort immer zwei Zugriffsbefehle auf den NanD erfolgen mussten.
Ergebnis: Die meisten DRam_less Sata SSDs werkelten nach sehr kurzer Zeit auf HDD Niveau und das umso schneller, je mehr die SSD befüllt war.

Seit PCIe3.0 und M2 SSD mit NVMe Protokoll hat sich das aber mit Einführung des Host Memory Buffer (HMB) grundlegend geändert.
Schon alleine der Umstand, dass diese SSDs via PCIe über 4 paralell zugreifende Lanes angebunden sind und PCIe im allgemeinen über niedrigere Latenzen verfügt als der "träge" Sata Anschluss, sorgt schon für einen wesentlich höheren Workflow. 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. Dieser hat eine feste, unveränderliche Größe, die vom Hersteller der SSD in den Feldattributen "HMPRE" (HMB Prefered Size) und "HMMIN" (HMB Minimum Size) hinterlegt ist. Siehe Screen einer FikWot FN955 mit HMB (links) und zum Vergleich Screen einer SK_hynix Platinum P41 mit DRam Cache (rechts):
hmb.png hmb1.png
(Info am Rande: Die links gezeigte FN955 in der 4TB Variante, wie zb. auch die Lexar NM790 in der 4TB Variante, unterstützen schon das NVMe2.0 Protokoll und damit u.a. auch erweiterte Command Sets (zb. 16bit CRC wird auf 32/64bit erweitert) und man kann davon ausgehen, dass auch bezgl. HMB noch weitere Optimierungen implementiert wurden.)

Das verantwortliche OS (u.a. auch Linux und Windows) ist verpflichtet, diesen Hostspeicher zu Verfügung zu stellen und wird über den Identify Befehl des NVMe Protokoll geregelt:
Zu Beginn der Phase führt der Host eine Abfrage mit dem Befehl „Identifizieren“ durch, um die Anforderungen des Controllers zu verstehen. Auf diese Weise bewertet das jeweilige Betriebssystem seine Speichernutzung, um eine angemessene Zuweisung bereitzustellen, während das NVMe-SSD-Gerät eingeschaltet ist. (AData Industrial Whitepaper HMB Technology PCIe SSD)

Also nicht der SSD Controller, erst recht nicht die SSD FW. muss das unterstützen, da dass ein fester Bestandteil des NVMe Protokoll ist, sondern der jeweilige Host muss die Anfragen des Controllers supporten.

Vorteil: Im Gegensatz zu der gnadenlos veralteten Pseudo "HMB" Technik zu Sata SSD Zeiten, findet hier kein doppelter Zugriff mehr auf den NanD statt.
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.
 
Zuletzt bearbeitet:
...
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.
korrekt, ich habe 1x WD SN770 2TB im System und kann im praktischen Betrieb keinerlei Nachteile zu meinen restlichen 3x WD SN850X 1/2/4 TB erkennen

hatte zu Anfang auch erst bedenken - im Benchmark ist dies u.U. ersichtlich - im täglichen Betrieb irrelevant
 
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:

BG4_HMB.png


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:

BG4_HMB_vs_970EVO.png


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.
 
das mag ja alles richtig sein, aber im alltäglichen Betrieb stelle ich keine negativen Punke fest

für Bencher die täglich AS-SSD laufen lassen mag das anders sein

Das sind aber auch nur meine persönlichen Eindrücke... ich mein wenn hier in anderen Threads drüber diskutiert wird ob die NVMe im Benchmark jetzt nur 5000MB/s anstatt 7000MB/s liefert mag das mit DRAM Less relevant sein... Aber auch da behaupte ich: im täglichen Betrieb irrelevant :banana:
 
das mag ja alles richtig sein, aber im alltäglichen Betrieb stelle ich keine negativen Punke fest
Dem widerspreche ich ja gar nicht, es hängt aber eben von der Art der Nutzung ab.

für Bencher die täglich AS-SSD laufen lassen mag das anders sein
Bei jeder Anwendung bei der viele kurze Zugriffe über einen großen Adressraum erfolgen, wird man eine Unterschied merken können, wobei das Merken natürlich immer relativ ist, man braucht natürlich erstmal einen Vergleich und dann halt auch ein System welches schnell genug ist damit das Lesen der Daten überhaupt einen spürbaren Unterschied machen kann.

ich mein wenn hier in anderen Threads drüber diskutiert wird ob die NVMe im Benchmark jetzt nur 5000MB/s anstatt 7000MB/s liefert mag das mit DRAM Less relevant sein... Aber auch da behaupte ich: im täglichen Betrieb irrelevant
Meinst Du diesen Thread? Nein, wie ich da im Post #6 geschrieben hatte, liegt es an der Länge und Anzahl der parallelen Zugriffe und im Alltag kommen kaum genug lange und parallele Zugriffe vor um auch nur einen Bruchteil der maximalen Leseraten aus schnellen PCIe SSDs zu kitzeln.
 
das mag ja alles richtig sein, aber im alltäglichen Betrieb stelle ich keine negativen Punke fest
Glaub mir, von den Schwachsinn was der User da schreibt ist nichts richtig. :rolleyes:

Der kann noch nicht einmal Inhalte logisch zusammenhängend interpretieren, dass fängt schon hiermit an:

SAT SSDs können das NVMe Protokoll nicht verwenden, weil dies einen nativ PCIe angebundenen Controller verlangt. SATA SSDs nutzen das AHCI Protokoll.
vs.
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.
Mehr Wiederspruch geht eigentlich schon nicht mehr. Bestreitet selbst, dass Sata SSDs das NVMe Protokoll besitzen und unterstellt mir, ich würde was anderes behaupten. :haha:

..und so setzt sich die geistige Hirnpfurzerei von einem zum nächsten Zitat weiter fort. Da soll ich ernsthaft drauf antworten? :stupid:

..und nun setze ich auch mal meine IL zum ersten Mal ein. (y)

edit:
ob die NVMe im Benchmark jetzt nur 5000MB/s anstatt 7000MB/s liefert mag das mit DRAM Less relevant sein...
..und selbst da laufen meine DRam_less S880 und NM790 highspeed und Langstrecke beim seq. kopieren am Limit im maximum.
Diese Amenmärchen die da immer aus der verstaubten Kiste hervor gekramt werden besitzen schon sehr lange keinerlei Gültigkeit mehr.
Stattdessen werden halt die immer gleichen Grafiken und Texte zusammen gekramt, irgendwann, Anfang der 2000er irgendwo erstellt. (y)
 
Zuletzt bearbeitet:
Bestreitet selbst, dass Sata SSDs das NVMe Protokoll besitzen und unterstellt mir, ich würde was anderes behaupten.
Wo habe ich das unterstellt? Was hast du blos wieder eingeworfen, dass du mir wieder unterstellst Dinge gesagt zu haben, die ich gar nicht gesagt habe um dies dann lächerlich zu machen. Typisches Trollverhalten oder zu viel Konsum seltsamer Substanzen? Wobei "Sata SSDs die noch nicht über das NVMe Protokoll verfügen" für mache so klingen könnte, als würde es auch SATA SSDs geben (können), die schon das NVMe Protokoll unterstützen und dies ist eben nicht der Fall.

Wo du klar Blödsinn geschrieben hast, war im großen Teil des Rests deines Beitrags und den habe ich entsprechend kommentiert, da du den Richtigstellungen nicht widersprochen hast, wissen nun alle was Sache ist. Stattdessen hängst du dich an dem einzige Teil auf, wo ich dir nicht widersprochen habe, sondern nur klarstellen wollte, dass es keine SATA SSDs mit NVMe Protokoll geben kann.
 
Da ich ja kurioserweise, sobald man sich von diesen Forum temporär abmeldet, immer noch "leider" die Beiträge des eigentlich ignorierten Users lesen muss, nur eines noch.

Wie es richtig ist steht alles in meinen Post #3 beschrieben, wer möchte kann dies auch gerne auf NVMexpress.org nachlesen, in Kurzfassung erklärt das AData Whitepaper HMB PCIe auch noch einmal alles wesentliche.

Von meiner Seite aus gibt es da auch nichts zu berichtigen und erst recht lasse ich mich auf keine "mühselige" weitere Diskussion mit Usern ein, die nichts verstehen wollen oder können und nun auch auf meiner erstmalig eingesetzten IL stehen. Zumindest da bin ich konsequent.
 
Danke allen! Für mich ist die Frage glaube ich beantwortet und zumindest habe ich durch den Diskurs und auch weiterem Stöbern im Netz auch nochmal ne Ecke dazu gelernt! Ich nahm erst an, da mein System in Frage ohnehin nur PCIe Gen 3 M.2 Slots hat (d.h. etwa 3500 MB/s), dass ich hier kaum einen Unterschied zwischen einer DRAMless SSD wie der Lexar NM790 oder einer aktuellen (d.h. mind. PCIe Gen 4) mit DRAM merken werde. Das ist allerdings für mich weiter unklar, da PCIe Gen 3 eben nicht nur die Datenrate auf etwa 3500 MB/s deckelt, sondern natürlich auch HMB bremst. Ich würde mich einfach melden, sobald ich irgendwie an eine preiswerte DRAMless NVMe SSD komme und ausprobieren konnte. Wichtig war die Frage, ob die Unterstützung grundlegend gegeben ist, hier war die Antwort "Ja".

Noch spannend finde ich:
Im Bild zu sehen (mit Host Memory Buffer Preferred Size und Host Memory Buffer Minimum Size) sind sehr kleine Caches von etwa 11MB, wobei übereinstimmend zu @Holt auch im ADATA Paper zu HMB gesagt wird, HMB könnte bei 99% der Systeme maximal 64MB allokieren. Wenn nun weiter, wie @Holt argumentiert hat, 1MB pro 1GB Adressraum reicht, wären bei 99% der Systeme über das Mapping im HMB 'nur' 64GB an Daten ohne Cache-Miss adressierbar. 64MB in den RAM zu schieben dürfte aber zeitlich auch nicht ins Gewicht fallen - da verstehe ich dann noch nicht, wo dann eine Halbierung der IOPS herrührt.
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:

Anhang anzeigen 953277

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:

Anhang anzeigen 953278

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.
Edit (neben Korrekturen, Ergänzung):
in Kurzfassung erklärt das AData Whitepaper HMB PCIe auch noch einmal alles wesentliche.
Ah, genau, das Whitepaper hatte ich eben auch schon gelesen.
 
Zuletzt bearbeitet:
da verstehe ich dann noch nicht, wo dann eine Halbierung der IOPS herrührt.
In welchen Szenario?

Du musst ja auch immer anhand des Anwendungsfalls unterscheiden wo Limits DRam_cached vs. HMB_cached erreicht werden könnten. Seq. Zugriff hast du diese Limits selbst über hunderte GB an Daten schieben meist nicht, ganz im Gegenteil, da kann HMB sogar eine bessere Figur machen als DRam_cached. Anwendungsfall S880 vs. P41 Platinum: Erstere kopiert HMB_cached 700GB File seq. am Stück mit 3,0 ~ 2,0GB/s, letztere DRam_cached ca. 160GB ~3,0GB/s, fällt danach ab auf ca. ~1,6GB/s. Dabei ist die S880 sogar nur via PCIe3.0 gesockelt, die P41 Platinum PCIe4.0 gesockelt.
4k @ Random Access schauts anders aus aber da müsste man dann auch erst an das von dir genannte Limit kommen, was vorrangig dann nur die Benchmarktools schaffen wenn man es denn provoziert.
Das ist ja genau der Unterschied zwischen Theorie und Praxis, man kann anhand irgendwelcher Benchwerte zeigen, "Pass mal auf, da sind die Grenzen", im Alltag aber, wo eine SSD selbst als OS Medium dann ganz anders läuft, wirst du diese Defizite aber kaum bis gar nicht bemerken. ;)
 
Zuletzt bearbeitet:
Du ich ignoriere diesen User nun, kann daher seine "Bildchen" nicht sehen aber ich kann mir schon denken, dass es dieses immer gleiche Bildchen ist was der schon in zig anderen Threads zum besten gegeben hat.
Für alles andere verweise ich auf meinen letzten Post #12 -> Theorie und Praxis vs. Benchspielereien. Solang da keine Sata SSD, die noch kein NVMe Protokoll unterstützt, eingesetzt wird, wirst du nur schwerlich im Alltag und bei allgemein üblicher Nutzung einen Unterschied DRam_cached oder DRam_less (HMB) ausmachen können.
Ich verstehe auch nicht (soviel konnte ich noch vor drücken des Ignore Button lesen), wie man nun, was auch schon symptomatisch für die Erklärbärweise dieses Users ist, man nun ein vollkommen veraltetes NVMe Protokoll unterhalb der Revision 1.3 anführen muss. Ich schätze mal, 99,99999% aller Anwender die NVMe SSD nutzen, werden sicherlich schon Datenträger im Einsatz haben die minimum das zuvor genannte Protokoll in minimum der Rev. 1.3 (SSDs a'la Crucial P5 aus 2020 zb.) besitzen, was auch schon sehr alt ist aber halt DRam_less den HMB Mode supportet.
 
Zuletzt bearbeitet:
..der brauch das wohl öfters mal.. :haha:

Aber Schwamm drüber. Kindisch so etwas, User auf eine IL zu setzen, damit anzugeben das man auf dieser einen "Ehrenplatz" eingenommen hat und zack, einen Post später wird man dann doch wieder zitiert.
Dem User scheinen meine Beiträge inhaltlich sehr zu gefallen. Ist ja nicht schlimm. Nur alles andere drum herum ist halt "wenig erwachsen".
 
Wie es richtig ist steht alles in meinen Post #3 beschrieben, wer möchte kann dies auch gerne auf NVMexpress.org nachlesen, in Kurzfassung erklärt das AData Whitepaper HMB PCIe auch noch einmal alles wesentliche.
Und was steht da:
Diese Host Software ist der NVMe Treiber, der hat die Autorität der SSD das RAM für den HMB zuzuweisen und dies beinhaltet eben auch, dass es es auch nicht machen kann, sonst hätte er ja nicht die Autorität, sondern die Pflicht! Aber kurz darüber steht ja auch:
HMB ist ein optionales Feature und nicht Pflicht. Nur der SSD Controller hat die Pflicht in den Informationsdaten über sich selbst auch zu informieren wie viel HMB er am liebsten hätte oder zumindest minimal möchte:
Das ist ja auch klar, wie sollte der Treiber sonst wissen wie viel RAM er als HMB reservieren soll. Der Host kann es auch ablehnen, wie dort ebenfalls steht:
Man beachte das es zwei Werte gibt, HMMIN und HMPRE und der Host dazwischen selbst entscheiden kann wie viel RAM er dem HMB freigibt oder eben auch gar nichts, wenn ihm selbst HMMIN zu viel ist, es disabled wurde oder der NVMe Treiber eben noch so alt ist, dass er noch kein HMB unterstützt.

Wie kann man daraus folgendes machen:
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. Dieser hat eine feste, unveränderliche Größe, die vom Hersteller der SSD in den Feldattributen "HMPRE" (HMB Prefered Size) und "HMMIN" (HMB Minimum Size) hinterlegt ist.
...
Das verantwortliche OS (u.a. auch Linux und Windows) ist verpflichtet, diesen Hostspeicher zu Verfügung zu stellen
Da versteht wohl jemand kein englisch, wobei das Whitepaper auch Unsinn schreibt, wie hier:
Normalerweise hat man eben eine flache Tabelle, früher waren auch B-Trees üblich, aber die haben einige entscheidende Nachteile und man kann natürlich die Auflösung verringern, üblich sind 4k weil die die normale Clustergröße von z.B. NTFS ist, was dann zwar auch zu einer kleineren Mappingtabelle führt, aber eben auch Performance Nachteile hat, wenn die Zugriffe nicht auf eine dieser Adressen geht. Für eine flache Tabelle mit der üblichen Auflösung braucht man 1GB RAM pro 1TB Kapazität und AData schreibt ja selbst, dass 64MiB das Limits für die meisten Hosts ist:
Aber sie benchen dann ja mit AS-SSD auch nur über einen Adressraum von 5GB und dafür reicht ein HMB locker, es beweist aber eben nicht, dass die ganze Mappingtabelle im HMB steht.
Von meiner Seite aus gibt es da auch nichts zu berichtigen und erst recht lasse ich mich auf keine "mühselige" weitere Diskussion mit Usern ein, die nichts verstehen wollen oder können
Er nimmt mir die Worte aus dem Mund, aber ich versuchen auch nicht ihn zu überzeugen, wie sinnlos dies wäre, sollte jedem der hier liest schon klar geworden sein und ebenso, wer hier recht hat: Derjenige der seine Aussagen belegen kann oder derjenige dessen Belege was anderes sagen als er selbst.
Wenn nun weiter, wie @Holt argumentiert hat, 1MB pro 1GB Adressraum reicht, wären bei 99% der Systeme über das Mapping im HMB 'nur' 64GB an Daten ohne Cache-Miss adressierbar.
So ist es, wobei es wie gesagt eben von dem Aufbau und der Auflösung der Mappingtabelle abhängt wie groß der Adressraum ist, für den diese maximal 64MiB reichen und dann fordert ja auch nicht jede DRAM less NVMe SSD so viel HMB an.

64MB in den RAM zu schieben dürfte aber zeitlich auch nicht ins Gewicht fallen
Es dürfte ja auch nicht alles dauernd hin und her geschoben werden. Eine flache Tabelle hat ja auch den Vorteil, dass man genau weiß wo welcher Eintrag steht und der HMB besteht ja aus mehreren Teilen, der SSD Controller kann da also Teile aus unterschiedlichen Bereichen der Mappingtabelle drin cachen und so auch Zugriffe auf unterschiedlich Bereiche der SSD beschleunigen, die weiter als 64GB auseinander liegen.

da verstehe ich dann noch nicht, wo dann eine Halbierung der IOPS herrührt.
Davon das eben schlimmstenfalls zwei NAND Zugriffe nötig sind und die machen den Löwwenanteil der Wartezeit auf eine Antwort bei so kurzen 4k Zugriffen aus. Schlimmstenfalls, weil es eben meist wiederholte Zugriffe auf Bereiche gibt die in der Nähe eines anderen Zugriffs liegen. Wenn man z.B. Musik oder ein Video abspielt, dann lädt der Player ja nicht die ganze Datei, sondern er lädt sie stückweise nach und nach und beim nächsten Zugriff ist damit die Chance hoch, dass der passende Teil der Mappingtabelle eben noch vom letzten Zugriff her im HMB gecacht ist, zumindest wenn es in der Zwischenzeit eben nicht zu viele Zugriffe auf ganz andere Adressbereich gab. Dann wäre der passende Teil der Mappingtabelle nämlich wieder aus dem HMB Cache verdrängt worden. Es hängt eben von der Nutzung ab wie gut ein HMB den DRAM Cache kompensieren kann, zu 100% wird er es nie können, aber je nach Nutzung kann er es gut genug, dass man den Nachteil nicht wirklich merkt.
Ich verstehe auch nicht (soviel konnte ich noch vor drücken des Ignore Button lesen), wie man nun, was auch schon symptomatisch für die Erklärbärweise dieses Users ist, man nun ein vollkommen veraltetes NVMe Protokoll unterhalb der Revision 1.3 anführen muss. Ich schätze mal, 99,99999% aller Anwender die NVMe SSD nutzen, werden sicherlich schon Datenträger im Einsatz haben die minimum das zuvor genannte Protokoll in minimum der Rev. 1.3 (SSDs a'la Crucial P5 aus 2020 zb.) besitzen, was auch schon sehr alt ist aber halt DRam_less den HMB Mode supportet.
Welche Revision das NVMe Protokolls die SSD unterstützt nutzt für sich alleine mal gar nicht, denn wenn der NVMe Treiber eben nur NVMe 1.0 oder 1.1 unterstützt oder eben die optionalen Features der neueren Revisionen der NVMe Spezifikationen nicht unterstützt, dann gibt es kein HMB, auch wenn die SSD schon NVMe 2.0 kann. Was der NVMe Treiber von Win 10 unterstützt, steht hier.
Dem User scheinen meine Beiträge inhaltlich sehr zu gefallen.
Nein, aber alleine diese blödsinnige Unterstellung sagt viel über dich aus. Wenn ich wüsste das dich alle auf ihrer IL haben, dürfte ich den Unsinn ja unkommentiert stehen lassen, aber so möchte ich den anderen wenigstens eine Chance geben echte Informationen statt Fake News zu bekommen, Dann können sie sich ihr Bild machen und entscheiden wen von uns beiden sie auf ihre IL packen.
 
Die Größe einer Mappingtabelle die eine flache Tabelle ist, ist unabhängig davon wie voll die SSD ist und proportional zur deren Nutzkapazität. Für die ganze Mappingtabelle ist der HMB zu klein und daher wäre das parts im Satz nötig gewesen, um diese Tatsache korrekt auszudrücken. So drückt der Satz aus das die ganze Mappingtabelle da reinpasst, oder wie würdest Du diesen Satz interpretieren: Der HMB ist groß genug um die Mappingtabelle unterzubringen.
 
Bei DRAM-less sehen die Kurven bei den neuen Western Digitals aber weit flacher aus als bei der vier Jahre alten Toshiba, da kommt mir die Suggerierung, dass alle NVMe-SSDs mit HMB an Buffer-Mangel leiden etwas zu pauschal vor.
Oder wie ist denn dieser Graph von Techpowerup zu werten?

1703839295323.png
 
Bei DRAM-less sehen die Kurven bei den neuen Western Digitals aber weit flacher aus als bei der vier Jahre alten Toshiba,
Das ist aber auch erstens mit QD16 statt QD1, also 16 parallelen Zugriffen statt nur einem zur Zeit und dann Schreibend statt Lesend. Keine Ahnung wieso sie Schreibend gewählt haben, da Lesend der aufschlussreichere Test gewesen wäre, denn beim Schreiben hat der DRAM Cache viel weniger Auswirkungen, da muss der Controller der SSD nur wissen wo freie NAND Blöcke sind in die er die neuen Daten schreiben kann und danach seine Mappingtabelle aktualisieren. Die WD SSDs könnten sich einfach mehr freie NAND Pages im HMB merken, wobei dies dann aber auf Kosten der Lesezugriffe gehen würde, dann man kann eben ohne DRAM Cache mit dem bescheidenen HMB den man hat, halt nur entweder mehr Daten darüber speichern wo NAND Pages frei sind oder eben mehr Daten dazu in welchen NAND Pages welche Daten stehen, aber um mehr von beidem zu speichern, muss man auch mehr HMB bekommen. Da Schreibzugriffe meist gepuffert erfolgen, ist die Schreibperformance im Alltag meist weniger kritisch, außer man schreibt große Datenmengen am Stück, aber sind dann auch meist sequentielle Schreizugriffe und dann fällt es sowieso nicht so ins Gewicht wenn der Controller hier und da mal was aus dem NAND Lesen muss um zu wissen wo mehr freier Platz für die nächsten Daten ist.

Würde der Test über mehr als 120GB laufen, würden die Kurven der WD SSDs da auch irgendwann abfallen, die Samsung 980 hält ja bis 60GB auch noch gut mit und fällt dann ab. Ansonsten taugen die Tests dort nicht wirklich um die Schwäche von DRAM less SSD mit HMB aufzudecken, auch der Test mit den 5000 mp3s, die indexiert werden, ein mp3 ist im Schnitt laut Google 3 bis 5MB groß, geht damit bestenfalls über einen Adressraum von 25GB und bei der MySQL Database Performance wird gerade mit einer 8GB Datenbank getestet. Da reicht überall der HMB aus um solche Adressräume abzudecken und dabei gut zu performen, aber wäre es eine 80GB oder gar 800GB Datenbank, dann sähe die Sache ganz anders aus und solch große Datenbanken will man dann sicher nicht auf DRAM Less SSDs betreiben. Klar kann man dann wieder einwenden, aber wer hat schon so eine große Datenbank zuhause und dies ist sicher richtig, es hängt eben wie gesagt von der Nutzung ab, wie sehr sich das Fehlen des DRAM Caches bemerkbar macht.
 
Bei DRAM-less sehen die Kurven bei den neuen Western Digitals aber weit flacher aus als bei der vier Jahre alten Toshiba, da kommt mir die Suggerierung, dass alle NVMe-SSDs mit HMB an Buffer-Mangel leiden etwas zu pauschal vor.
Die ist auch zu "pauschal".
Schon alleine, dass man Tests einer vier Jahre alten SSD mit aktuellen SSDs bzgl. HMB Mode und deren Funktionsweise vergleichen bzw. gleich setzen möchte ist schon Mumpitz.
Wie überall werden sicherlich auch bei Storage innerhalb dieser, für Hardware doch schon enorm langen Zeit, bzgl. HMB Verbesserungen/Optimierungen stattgefunden haben.

..wie wäre es denn mal mit aussagekräftigen, aktuellen Tests aktueller SSDs HMB vs. DRam? Dieser User zweifelt doch alles an was seiner "Weltanschauung" nicht entspricht.
User hier im Forum, Herstellerseiten die natürlich auch nicht richtig liegen usw. usf. - hmm.. ..warum ist er denn dann hier überhaupt aktiv? Zu viel Tagesfreizeit? :unsure:
 
Ich hatte heut nachmittag zufällig leihweise eine Micron 2450 512GB in der Hand und konnte die kurz testen. Das ist eine nicht allzu alte, Value-orientierte PCIe-SSD mit TLC-Flash, ohne Dram, nur mit HMB, NVMe 1.3.

Der übliche CDM-Benchmark auf der leeren SSD ist völlig unauffällig und zeigt erstmal brauchbare Werte. Wie zumeist ja üblich auch für kostengünstige SSDs.

Ich hab dann nen etwas älteren Oracle DB-Benchmark (Orion) drüberlaufen lassen. Ebenso auf der leeren SSD. Der rennt pro Durchgang etwa 9-10 Minuten. Einmal lesen mit verschiedenen Blockgrößen, einmal gemischt lesen und etwas Schreiben. Also knapp 20 Minuten Action.
Solang sequentiell gelesen wird: alles ok. Mit gemischten Blockgrößen Lesen überrundet die 960er Evo sie schon.

Sobald aber gemischtes Lesen und Schreiben auftritt => geh mir weg mit dem Ding. Das Teil wird von einer 960 Evo in Grund und Boden gestampft, auch eine Sata 850 Pro oder 870Evo ist deutlich schneller.
Datenraten brechen gnadenlos ein; meiner Meinung nach ist für dieses Szenario "katastrophale Performance" als Bezeichnung angebracht, Latenzen sehr sehr schlimm, teilw. bis auf 3,2 Sec !
Ich dachte schon, das Ding hat QLC-Flash. Lt. Micron aber 176Layer 3D TLC.

Den gleichen Test gegen eine PM9A3 muss ich euch vmtl. nicht mehr schildern. Die 2450 wird da von den Performancedaten her quasi "vernichtet". Klar, die PM9A3 ist eine Datacenter-SSD die für sowas und noch mehr gebaut ist.


Natürlich ist das nicht repräsentativ, es ist ja nur ein einzelnes SSD-Modell, ein kurzer Test und auch keine Highend Dram-Less SSD. Aber mein Standardtest, durch den SSDs müssen.
Und das Resultat reicht mir ... sowas kann man in ein Office only-Laptop verbauen, wenn man i.w. Powerpointcharts malt oder im Büro wenn man seine Daten eh auf dem Firmennetzwerk hat. Dafür mag sowas durchaus reichen.
Resultat für mich jedoch: Value-SSD mit HMB => kommt mir nicht in Haus; dafür geb ich kein Geld aus.

Eine NM790 1TB oder so Noname "Günstig-SSDs" (abwertende Bezeichnungen erspar ich uns mal) mit dem gleichen Orion-Script gegenzutesten wär durchaus interessant, aber dafür bin ich nicht bereit Geld auszugeben.
 
Zuletzt bearbeitet:
Ich habe hier mehrere HMB SSDs. Schreib was du dir an Tests mit welchen Settings so vorstellst und ich teste das. Kein Thema.

Sofort verfügbar da verbaut: 4TB FikWot FN955.
Im anderen Rechner: 2x2 TB S880
Im Karton: 4TB Lexar NM790

als Referenz DRam kann ich anbieten: SK_hynix Platinum P41 | WD SN850X
Im anderen Rechner: S770

..ansonsten Rest leider schon verkauft (und gerade für die 2TB NM790 und zweite S770 hatte ich hier noch Wochen später einige Anfragen per PM bekommen. Scheinen beliebte SSDs zu sein).

ps: Aber mal davon ab, hier wird wieder mit Kanonen auf Spatzen geschossen und Szenarienblasen aufgebaut, die a.) nicht den normal üblichen Homeusergebrauch einer SSD entsprechen und b.) nur darauf abzielen, HMB Mode schlecht ausschauen zu lassen. Das HMB seine Grenzen hat wird ja nicht bestritten, auch DRam kommt an seine Grenzen, man muss nun aber nicht die exotischsten Konfigurationen durchkauen NUR um dann im Endeffekt stolz prahlend behaupten zu können: "Siehste, doch Recht gehabt!". Das ist dann mal wirklich total daneben und verunsichern anderer Mitleser par excellence.

Meine persönliche "Praxis" Erfahrung ist: HMB Mode SSDs nimmt man gerne in größere Größen als Datengrab und auch Gaming Archiv. Wo brauchts da zuvor gepostete Szenarien? :unsure:
Solange DRam_less HMB-Mode SSDs in diesen Größen/Kapazitäten teils einiges günstiger sind als DRam include SSDs entsprechender Kapazitäten wird man die nicht einfach weg diskutieren können.
Erst recht nicht mit out_of_Date Bildchen. Ganz im Gegenteil, deren Verbreitung nimmt immer mehr zu weil der Preis macht die Musik und die sind alles andere als "nicht zu gebrauchen".
 
Zuletzt bearbeitet:
ps: Aber mal davon ab, hier wird wieder mit Kanonen auf Spatzen geschossen [...]

Meine persönliche "Praxis" Erfahrung ist: HMB Mode SSDs nimmt man gerne in größere Größen als Datengrab und auch Gaming Archiv. Wo brauchts da zuvor gepostete Szenarien? :unsure:
Solange DRam_less HMB-Mode SSDs in diesen Größen/Kapazitäten teils einiges günstiger sind als DRam include SSDs entsprechender Kapazitäten wird man die nicht weg diskutieren können.
[...] Ganz im Gegenteil, deren Verbreitung nimmt immer mehr zu weil der Preis macht die Musik und die sind alles andere als "nicht zu gebrauchen".
Sicher. Die Grenzfälle zu kennen informiert doch aber nur mehr, wo man persönlich eine DRAMless SSD einsetzen will bzw. wo man persönlich ggf. doch auf eine (teurere/kleinere) DRAM SSD zurückgreift.
 
Sorry aber ich persönlich -und da schreibe ich jetzt nur für mich- bezahle keine über 100€ Aufpreis (je nach Modell und Marke) für eine zb. 4TB SSD "nur" weil diese einen eigenen DRam Cache besitzt wenn ich schon vorher weiß, dass ich die als Gaming bzw. Datenarchiv einsetzen werde. Eine 4TB SSD wird wohl auch kaum jemand als OS SSD benutzen und wenn ja, kann man ja machen wenn man möchte. :)

Sicherlich gibt es Szenarien, wo DRam_include SSDs ihre Vorteile ausspielen und wo auch ich diese jeder DRam_less SSD vorziehen würde aber das muss und sollte dann jeder für sich vor Kauf selbst entscheiden.

Nur HMB generell als untauglich zu deklassieren, alles und jeden anzuzweifeln der zu einen anderen Ergebnis aus "praktischer Erfahrung und Nutzung" kommt, dass ist mal sehr engstirnig gedacht und sorry, so jemanden kann ich dann beim besten Willen nicht mehr ernst nehmen und da wird jede weitere Diskussion meinerseits gekappt.

So, einfach mal just for Fun Anvils mit höchster Testsize 32GB und einer 4TB FikWot FN955 vs. 2TB SK_hynix Platinum P41 gebencht:

anvil.png

BITTE BEACHTEN:
- die FN955 ist zu knapp 70% befüllt und nur via PCIe3.0 gesockelt (habe auf meinen Z690 halt nur 3x PCIe4.0)
- die P41 ist etwas über 50% befüllt und via PCIe4.0 gesockelt - hat also einen gewissen Geschwindigkeitsbonus.

..nur für den Fall, dass das mal wieder von bestimmter Seite überlesen wird. Als nicht brauchbar schaut mir das nun nicht gerade aus unter den zuvor genannten Voraussetzungen.


edit: Da die FN955 ja primär eh als Gamingarchiv (Steam Bibli) genutzt wird, auch da bleibt beim downstream eigentlich nichts zu meckern:

steam.png


..und da ich auch schon einmal eine Crucial P3Plus (bitte nicht verwechseln mit der P5Plus, die ist sehr gut) mit HMB Mode als GameBibli hatte kann ich schreiben, JA, wenn die SSD mit HMB nicht richtig klar kommt (die hatte entsprechende Bugs) zieht das auch die downstream Leistung in den Keller. Spätestens beim dekomprimieren der herunter geladenen Daten auf SSD. Zeitweise hatte ich da Lags mit 0 MB/s was bestimmt nicht an meinen ISP lag. Diese SSD, obwohl ja "Marken SSD" hatte aber eh nur Probleme bereitet.
 
Zuletzt bearbeitet:
Sicherlich gibt es Szenarien, wo DRam_include SSDs ihre Vorteile ausspielen und wo auch ich diese jeder DRam_less SSD vorziehen würde
Das klingt ja schon anderes als die vorherige Aussage:
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.
Worauf ich geantwortet hatte:
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.
Keine Ahnung was für Wahnvorstellungen man haben muss um dann sowas zu schreiben:
Nur HMB generell als untauglich zu deklassieren, alles und jeden anzuzweifeln der zu einen anderen Ergebnis aus "praktischer Erfahrung und Nutzung" kommt, dass ist mal sehr engstirnig gedacht und sorry, so jemanden kann ich dann beim besten Willen nicht mehr ernst nehmen und da wird jede weitere Diskussion meinerseits gekappt.
Hat hier etwa irgendwo jemand geschrieben sie wären generell untauglich?
 
..und noch einmal ein weiterer Praxistest aktuellen Storage fernab der out_of_date Bildchen hoffnungslos veralteter Storage:

Verschieben von 2 Gameordnern 755GB (Epic | UPlay) mit 10547 Dateien in 426 Ordnern von 2TB SK_hynix Platinum P41 (M2_2 @ PCIe4.0) nach 4TB FikWot SN955 (M2_3 @ PCIe3.0):

setup.png
write.png

..und wieder zurück:

read.png

..ja, die schrottigen dram_less HMB SSDs, taugen in der Praxis ja mal absolut nichts, gelle. (y)
 
Zuletzt bearbeitet:
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh