Native NVMe Treiber für Win 11 nun erhältlich

[ssj3rd]

Da es hier keine News dazu gibt und die im CB Forum ordentlich dabei sind den Treiber zu testen, auch mal hier die News:

News - Nativer NVMe-Support: Für Risikofreudige gibt es den neuen Treiber auch unter Windows 11

Microsoft hat kürzlich für Windows Server 2025 einen nativen NVMe-Treiber vorgestellt, der die SSD-Leistung deutlich steigern soll. Aktivieren lässt er sich per Registry-Key und das klappt auch unter Windows 11, ⁣ wieUser herausfanden. Allerdings wird dadurch so einiges verändert, weshalb...

www.computerbase.de

 

[Erklärbär]

Test nicht bestanden -> Treiber wieder gecancelt (was so auch nur über einen Wiederherstellungspunkt geht, ansonsten viel Spaß mit Freeze und BS):



ps: Einziger Unterschied, Storages die dieses Treiber"modding" (Registry Hack) besitzen, sind nicht mehr bypassIO Kompatibel und "können" Auslesebugs mit Drittanbietersoftware generieren (einfach mal den Deskmodder Thread komplett lesen).
Von der Leistung her -> Steigerung +/- 0,00%.



..kann sich ja jeder drauf packen wenn er möchte, nur nicht nachher "jammern" wenn es dann wo bugt und man den Murks nicht mehr so einfach los wird oder das geliebte Magician plötzlich nicht mehr weiß, dass die Samsung mal eine Samsung war. Meine, dass WD Dashboard hat da nun auch Probleme mit wenn man den Hack drauf macht.

edit: Stimmt ja, Dashboard dupliziert ja nun Storage und hat mir aus zwei SN850X mal ebend 4 gezaubert mit "Treiber-Hack".
Geräteerkennung dauert nun auch wesentlich länger (über 20sek.). Wußte gar nicht, dass in der Kiste schon 10 Gen4 M.2 SSDs werkeln. ..ist denn schon Weihnachten?

 

[ssj3rd]

Gibt da wirklich extrem unterschiedliche Meinungen bisher und wenn ich mir den CB Thread so angucke haben wirklich sehr sehr viele definitiv höhere Zahlen beim benchen.

Soo negativ sehe ich das nicht und bisher ist wohl tatsächlich der einzige Bug das manche Hersteller Software nun paar Anzeige Fehler hat. Nunja, gibt schlimmeres.

Aber ja, sollte trotzdem jeder auf eigene Gefahr machen 🤘

 

[Techlogi]

 

[Erklärbär]

ist wohl tatsächlich der einzige Bug das manche Hersteller Software nun paar Anzeige Fehler hat.

Nein, da gibt es noch einige weitere (bin da am austesten welche), wie z.b. das hier:



..und verschwinden wieder, wenn man (über Umwege) auf die bisherigen MS Storagetreiber umstellt:



Du hast auch keinen Zugriff auf diesen "Anhang". In der Datenträgerverwaltung kannst du weder diesen Bereich einer bestehenden Partition anhängen (vergrößern) noch via AOMEI PA den Bereich auslöschen (Vorsicht: löscht die komplette SSD wenn man versucht nur diesen "Ghost"-Bereich auszulöschen!!) und auch nirgendwo einer bestehenden Partition hinzufügen.
Auch Partition/SSD löschen und wieder neu anlegen nutzt nix, dieser unformatierte Bereich wird immer wieder angehangen.
Und was das benchen betrifft: 5x benchen = 5x unterschiedliche Ergebnisse = 2x marginal besser + 3x eher marginal schlechter. Sagt rein gar nüscht aus irgendwie da nur "Spielzeug".
Keine Ahnung, warum sich da einige User nun so darauf fixieren und diesen Benchkram nun plötzlich so toll finden und über alles andere heben.

 

[Stunrise]

Ich habe es direkt getestet und tatsächlich messbar mehr Leistung.

Mein daily Backup über Veeam Endpoint Agent hat auch kein neues Fullsize Backup erfordert.

WD Dashboard erkennt die SSD weiterhin einwandfrei - nun allerdings doppelt.

Das Notebook meiner Frau funktioniert nach der Umstellung ebenfalls normal - inklusive messbar besserer SSD Leistung.

 

[Holt]

Sunrise, schau lieber mit Drive Controller Info welcher Treiber verwendet wird. Das Tools ist zwar schon alt und die Erkennung ob TRIM aktiv ist, funktioniert seit Win 10 nicht mehr korrekt, aber es zeigt den wirklich verwendeten Treiber ab.

 

[Stunrise]

@Holt

 

[Erklärbär]

Das Tool ist nicht hilfreich da total veraltet. Der Treiber bleibt ja der gleiche (bei dir .6725), es wird nur intern die disk.sys durch nvme.sys abgelöst, kannst du unter Treiberdetails einsehen:



Zweites Indiz ist halt das geänderte Storagesymbol (ein IC Chip oder was das sein soll, orange markiert).

ps: Warum W11 bei dir allerdings nach aufspielen der nvme.sys deren Dateiversion auch als Treiberversion deklariert - keine Ahnung.
Könnte eventuell damit zusammen hängen, dass du ja die Pro Edition hast und damit, im Gegensatz zu meiner Enterprise Edition, keine einwandfrei funktionierende Storagepool Integration möglich ist.

 

[Holt]

Das Tool ist nicht hilfreich da total veraltet.

Das es veraltet ist, weiß ich und haben ich geschrieben, aber es zweigt immer noch den Treiber und dessen Version korrekt an.

 

[Luxxiator]

Hier steht auch was dazu; vllt ganz hilfreich, um das Ganze bissel einzuordnen...

 

[Erklärbär]

Ich hatte gestern mal das MS Tool Diskspd mit Parametern durchlaufen lassen (200GB auf 20 Threads) die optimiert sind auf den neuen nvme.sys Treiber.
Also sehr hohe I/O Operationen per Thread (bei CDM geht ja max. nur 512 - das sind knapp 1% dessen was modernes Gen5 Storage "packt") und R/W Ratio 70/30 mit Blocksize 8KiB.
Der einzig positive Effekt war halt, dass die CPU Last wirklich extrem (teils bis zu 60%) abgenommen hat.
Die Latenzen aber, gerade in den wichtigsten 25. Perzentil (Intervalluntergrenze) und 75. Perzentil (Intervallobergrenze) bei 50. Perzentil arithmetisches Mittel (Median) war aber fast gleichauf zu den MS-Storage disk.sys Treiber. Also nur marginal besser. Auffällig war aber der Worstcase Bereich 99th Perzentil und x-Nines (99,xx Nachkommaberechnung) darüber, hier hatte der NVMe Treiber derbst Probleme und hat anstehende Operationen erst mit Latenzen von über 7000ms abgearbeitet. Das ist bis zu 8x höher als mit den MS-Storage Treiber.
Auch kann der NVMe Treiber wohl in den I/O Operationen (random) nicht so gut mit hardware-/softwareseitiges Caching umgehen und werkelt dort teils unter Niveau des alten Treibers.
Ist das Caching aus (Writethrough on), dann gehen die Operationen per Thread aber schon bischen was schneller durch als mit den alten Treiber.

..das sind natürlich alles Werte, die zeigt dir ein anwender_geschöntes CDM-Tool & Co. nicht an, da zählt nur ein hoher Scrore für die Hall-of-Fame und wer den Längsten hat.
Praxisnäher sind dann da aber schon eher die Befehlzeilen orientierten Anwendungen - nur halt nicht so "hübsch" und erfordern halt ein wenig Hintergrundwissen in der richtigen Bedienung.

 

[Luxxiator]

Ich würde trotzdem abwarten, bis das offiziell freigegeben wird. Wenn es gut läuft, dauert es vllt gar nicht mehr soo lange. Weniger als 15 Jahre wohl allemal...

 

[Erklärbär]

Man kann den Treiber unter den W11 Heimanwender Editionen (Pro, Home usw.) ja durchaus schon mit gewissen Defiziten (siehe Post zuvor) einsetzen und teils zeigt er ja auch positive Effekte.
Ich vermute aber mal, dass die Storage Packages der Enterprise Editionen (da ja unternehmsorientierte BS) schon Teile dieser NVMe Unterstützung enthalten, siehe Post #9.
Erkennt man u.a. auch daran, dass ja nur die Enterprise und WS die MS Storagepool Funktion aktiv unterstützen und bei W11 Heimanwender-Editionen nur ein sinnfreies Gimmick ist.
Da könnte z.b. @Holzmann mal nachschauen, wenn er noch einen aktiven Pool einsetzt, ob dort im MassStorage Treiber unter den Treiberdetails eine nvme.sys mit aufgelistet wird.
Wohl mit ein Grund dafür, dass bei mir der NVMe Treiber nur marginale bis gar keine Verbesserungen (außer halt niedrigere CPU Last, I/O random Modus no_Caching) zum bisherigen Treiber mit sich bringt.

edit: Ich hatte mir die Werte CPU Lasten via MS Diskspd doch im Editor notiert:

Testszenario: 200GB Testfile | Testdauer 5min.
Testmethode 1: I/O Zugriff: Random | Hard- und Softwarecache deaktiviert (hw_cache disabled / writethrough on)
Testmethode 2: I/O Zugriff: Random | Hard- und Softwarecache aktiviert (hw_cache enabled / writethrough off)
Testparameter: Threads: 20 | Anfragen je Thread: 2048 | Blockgröße je Anfrage: 32kb | Verhältnis I/O Operationen: 70/30 | mit Latenzmessung | WarmUp: 5sek. | CoolDown: 0sek.

Syntax: diskspd -d300 -t20 -o2048 -b32K -w30 -r -Sh -L -c200G F:\testData.dat > Result_noCaching.txt

Ergebnis I/O total:

• CPU Last avg. ohne Caching: 43,24% (disk.sys) | 8,29% (nvme.sys)
• CPU Last avg. mit Caching: 80,55% (disk.sys) | 74,53% (nvme.sys)

..also mit gecachten Operationen kann der NVMe Treiber kaum besser umgehen als der MS-Storage Treiber.
Ohne Caching sind die CPU Lasten per Thread aber schon sehr gering und das bei immerhin 2048 Anfragen per Thread (CDM macht max. 512).

 

[Delgado]

Das es veraltet ist, weiß ich und haben ich geschrieben, aber es zweigt immer noch den Treiber und dessen Version korrekt an.

Abgesehen davon: kann es sein, dass die Downloads alle nicht mehr funktionieren? Ich kann es jedenfalls nirgendwo laden.

 

[Luxxiator]

@Erklärbär Hm, also könnte man mit der Enterprise durchaus schon mal einen Versuch wagen, oder?

 

[Stunrise]

@Erklärbär
Ich interpretiere die Ergebnisse deiner Messung so, dass bei einer massiven Überlastung der Storage-Performance (20 Threads, 200GB) der neue Treiber in seltenen Fällen (<.1Percentile) individuelle Abfragen langsamer verarbeitet. Ich habe die Dokumentation von Microsoft zum Thema durchgelesen und während das alte Model ISCSI Befehle emuliert und dabei nur eine Queue mit bis zu 32 Commands unterstützt, sind es im neuen Treiber 64k Queues mit jeweils 64k Commands. Dadurch ist zu erwarten, dass der alte Treiber die Commands der einen Queue halbwegs (NCQ) hintereinander abarbeitet, während der neue Treiber aufgrund der massiv breiten Auslegung dazu führen kann, dass Commands, die später abgesetzt wurden, trotzdem früher fertiggestellt werden. Obendrein ist bei Singlequeue immer leichte Unterauslastung zu erwarten, womit individuelle Commands schneller fertig werden, die Summe aller Abfragen aber länger dauert. Ich interpretiere das nicht als Bug, sondern als Eigenheit, die mit einem so breiten Model einhergeht.

Rein von den Fakten - also der Erklärung vom Microsoft Storageteam und der Erkenntnis, dass Linux bereits seit 10 Jahren nativ NVMe Treiber verwendet - erkenne ich keinen Grund, nicht den neuen NVMe Treiber zu verwenden - sofern es keine Softwareinkompatibilität im individuellen System gibt. Der Storagetreiber ist viel breiter ausgelegt und ermöglicht deutlich mehr Multithreading - erkennbar in deutlich(!) mehr Leistung im CDM auf beiden von mir getesteten Systemen (AMD Desktop, Intel Notebook) im Bereich Q32 4K.

Für einen bestehenden und produktiven Server würde ich das nie im Leben rückwirkend ausrollen - ich persönlich würde das auch nicht bei einem neuen Server mit Opt-in einschalten, wenn es nicht explizit einen guten Grund dafür gibt. Als IT-Admin ist man verantwortlich für alle Nachteile, während die Vorteile niemanden interessieren. Für ein privates Endgerät mit Backup dagegen sehe ich kein Problem

@Luxxiator
Es ist jetzt offiziell freigegeben - nur es wird "default" nicht aktiviert. Microsoft geht üblicherweise so vor, dass zunächst als Opt-In solche Funktionen bereitgestellt werden und nach einigen Jahren Neuinstallationen automatisch den neuen Treiber bekommen - da reden wir dann in 5 Jahren nochmal drüber.

 

[Luxxiator]

Offiziell schon, aber eben nur für Server-Betriebssysteme, oder? Deswegen tue ich mich da bissel schwer mit meinem Daily Driver; einzig der Ivy Bridge wäre vllt was, weil das quasi der Ersatz-PC ist und schon mit Enterprise bestückt ist. Ich habe den nachher eh auf dem Schoß...

 

[Erklärbär]

Ich interpretiere die Ergebnisse deiner Messung so, dass bei einer massiven Überlastung der Storage-Performance (20 Threads, 200GB) der neue Treiber in seltenen Fällen (<.1Percentile) individuelle Abfragen langsamer verarbeitet.

Genau! Das aber auch nur im Worstcase Bereich 99th, also Bruchteil der oberen 25% Anfragen gefolgt 75. Perzentil (inkl. x-Nines), was max. 1 Perzentile entspricht - also eher weniger relevant aber halt vorhanden und das auch nur im gecachten Modus. Ohne Caching hast du nicht diese Ausreißer ggü. den MS-Storage Treiber (disk.sys).

Ich habe die Dokumentation von Microsoft zum Thema durchgelesen und während das alte Model ISCSI Befehle emuliert und dabei nur eine Queue mit bis zu 32 Commands unterstützt, sind es im neuen Treiber 64k Queues mit jeweils 64k Commands. Dadurch ist zu erwarten, dass der alte Treiber die Commands der einen Queue halbwegs (NCQ) hintereinander abarbeitet, während der neue Treiber aufgrund der massiv breiten Auslegung dazu führen kann, dass Commands, die später abgesetzt wurden, trotzdem früher fertiggestellt werden. Obendrein ist bei Singlequeue immer leichte Unterauslastung zu erwarten, womit individuelle Commands schneller fertig werden, die Summe aller Abfragen aber länger dauert. Ich interpretiere das nicht als Bug, sondern als Eigenheit, die mit einem so breiten Model einhergeht.

Genau! Meinen Informationsstand nach sind mit Gen5 Storages auch Anfragen bis zu 126,5k möglich.

Rein von den Fakten - also der Erklärung vom Microsoft Storageteam und der Erkenntnis, dass Linux bereits seit 10 Jahren nativ NVMe Treiber verwendet - erkenne ich keinen Grund, nicht den neuen NVMe Treiber zu verwenden - sofern es keine Softwareinkompatibilität im individuellen System gibt. Der Storagetreiber ist viel breiter ausgelegt und ermöglicht deutlich mehr Multithreading - erkennbar in deutlich(!) mehr Leistung im CDM auf beiden von mir getesteten Systemen (AMD Desktop, Intel Notebook) im Bereich Q32 4K.

CDM ist dafür aber eher ein ungeeignetes "Tool" was modernes Storage anfragenseitig gar nicht auslastet.
Ich denke mal, wenn die MS Entwickler da noch ein paar Defizite bereinigen kann der durchaus in Masse auch eingesetzt werden.
Jetzt kann man den zwar auch anwenden aber halt mit Defiziten die dir diese 08/15 Tools gar nicht interpretieren können.
Was CDM da z.b. als "NVMe optimiert" in den Settings wahlweise optional einstellbar anbietet, ist sorry -> Kinderkacke!

Offiziell schon, aber eben nur für Server-Betriebssysteme, oder?

Genau! ..und ich meine auch gelesen zu haben, dass anfangs auch die unternehmensorientierten Enterprise Editionen (IoT LTSC) dazu gehören sollten.

 

[Luxxiator]

Enterprise auch? Dann weiß ich ja, was ich demnächst mache; der Ivy kann jede Form der Entlastung gebrauchen...

 

[Erklärbär]

Das ist alter Kenntnisstand, den ich mal vor geraumer Zeit bei MS zu den Servergeschichten gelesen hatte. Ob das aktuell auch so umgesetzt ist, keine Ahnung.
Mich wundert halt, dass @Stunrise z.b. mit seiner W11 Pro einen komplett älteren Treiber unter nvme.sys implementiert hat als bei meiner Enterprise, der diese Treiberversion schon vor Umstellung auf nvme.sys auf MS-Storage Treiber Basis include hatte und nach Umstellung auf nvme.sys halt auf .7309 Version (was den letzten Qualitäts-KB für 24H2 entspricht). Könnte also ein Indiz dafür sein, dass Enterprise da mit WS treiberseitig synchron läuft, sonst müsste es ja die .4484 sein, wie bei den meisten W11 Pro Anwendern der Fall. Dazu die teils mageren Performancevorteile via Diskspd I/O @ random bei nvme.sys.

 

[Luxxiator]

Ich meine, das dieses zusätzliche Geraffel im Oktober mit dem Patchday implementiert wurde....

 

[Benjamin1990]

Hallo

Ich hätte da auch mal eine frage bzw Problem mit dem neuen NVME Treiber

Gestern habe ich frisch IoT Enterprise installiert und auch den besagten NVME Treiber aktiviert und habe dann meine TB4 Gehäuse angeschlossen (Und den Cache aktiviert) mit einer SN71000 und 980Pro und habe meine backups gemacht soweit so gut aber sobald ich die Verbindung trenne zum PC bleiben die Festplatten weiter sichtbar in Arbeitsplatz und man kann weder Neustarten noch Herunterfahren (Nach 5min habe ich die Reset taste gedrückt weil der Neustart Bildschirm sich nicht verändert hat)

ist das aktuell noch ein Bug oder brauch man ein Workaround oder sonstiges?

 

[Erklärbär]

Dann versuch das gleiche doch noch einmal mit den alten MS-Storage Treiber. Bugt es danach nicht mehr, dann weißt du ja woran es lag.

und man kann weder Neustarten noch Herunterfahren (Nach 5min habe ich die Reset taste gedrückt weil der Neustart Bildschirm sich nicht verändert hat)

..das hatte ich, als ich on_top via Hardwaresteuerung den nvme.sys Treiber wieder zurück spielen wollte. Es half nur Hardreset via Gehäusetaste.
Kann helfen, wenn du die Registryeinträge bezgl. des neuen Treiber löschst, dann sollte Windows bei Neustart die alten Treiber initialisieren (sind ja noch im System).
Allerdings ohne Gewähr - hatte das im Deskmodder Forum nachgelesen. Ich gehe da eher auf Nummer Sicher und nehme einen Wiederherstellungspunkt (soweit eingerichtet).

 

[Benjamin1990]

Das Kuriose ist nur mit den TB4 Gehäusen tritt das auf sonst funktioniert der NVME Treiber Top in Windows

 

[Erklärbär]

Die TB4 Console/Treiber hast du aber inkl. UEFI Settings usw. installiert?
Könnten Treibertroubles sein, weil ja noch nicht offziell frei gegeben. Wer weiß das schon.
..daher schreibe ich ja (schon öfters hier) man sollte vorsichtig mit den Treiber sein und entsprechend für eine Rückspielmöglichkeit sorgen.

 

[Benjamin1990]

Ja habe den aktuellen Intel Treiber inkl Kontrollcenter installiert

 

[Erklärbär]

Dann würde ich wirklich mal die nvme.sys wieder entfernen und mit der alten disk.sys testen. Klappt es dann wird es da noch Troubles diesbezgl. mit den Treiber geben.
Ist halt eine Konfig. die nicht so üblich ist, da TB4 zertifiziertes Equipment schon ein paar Talers "intensiver" ist als dieses mainstream USB4 Gedümpel.

ps: Die total Latency Distribution (Perzentil) ohne und mit Hard-/SoftwareCaching hatte ich gestern auch mal getestet, hier das Ergebnis:

Ergebnis:

• I/O Accesstime 25th total ohne Caching: 13,859ms (disk.sys) | 10,953ms (nvme.sys) -> untere Intervallgrenze Operationen (darunter ca. 25% Zugriff)
• I/O Accesstime 50th total ohne Caching: 25,784ms (disk.sys) | 28,255ms (nvme.sys) -> arithmetisches Mittel (Median) der Zugriffhäufigkeit 50%
• I/O Accesstime 75th total ohne Caching: 32,002ms (disk.sys) | 35,233ms (nvme.sys) -> obere Intervallgrenze Operationen (darüber ca. 25% Zugriff)
• I/O Accesstime 25th total mit Caching: 0,364ms (disk.sys) | 0,290ms (nvme.sys) -> untere Intervallgrenze Operationen (darunter ca. 25% Zugriff)
• I/O Accesstime 50th total mit Caching: 1,471ms (disk.sys) | 0,827ms (nvme.sys) -> arithmetisches Mittel (Median) der Zugriffhäufigkeit 50%
• I/O Accesstime 75th total mit Caching: 34,347ms (disk.sys) | 28,175ms (nvme.sys) -> obere Intervallgrenze Operationen (darüber ca. 25% Zugriff)

..nur zur Info.

 

[Benjamin1990]

Besteht den nicht die Möglichkeit nur für die TB4 Gehäuse den NVME Treiber zu entfernen aber für meine fest eingebauten NVME ihn zu lassen?

 

[Erklärbär]

Nein, wenn der aktiv ist dann für das komplette Storage.