Samsung 980 Pro Treiber Frage ( PM9A1 Firmware OEM, Write Performance Fix)

Kullberg

Computer Schach Freak
Thread Starter
Mitglied seit
18.02.2005
Beiträge
5.893
Ich hab mir eine Samsung 980 Pro für mein neues X570 Mobo gegönnt. Die funktioniert soweit auch einwandfrei. Nur wenn ich versuche, den NVMe Treiber von Samsung zu installieren, kommt die Meldung, es sei keine entsprechende SSD vorhanden. Hab die neueste Version 3.3 auch versucht.
Was läuft da falsch?
 
Lösung
Wird wahrscheinlich kein Unterschied machen da der x570 im Grunde der gleiche Chip ist wie in der cpu.
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Einfach ausprobieren, wenn auch wenn es das gleiche Die ist, müssen die Energiespareinstellungen nicht identisch sein. Als I/O Die steckt der in einem Gehäuse mit den CPU Chiplets unter einem fetten CPU Kühler, als X570 Chipsatz sitzt er alleine in seinem Package und auch wenn fast alle X570 Board einen Lüfter über dem Kühler haben, sollte der nicht unbedingt ständig laufen, da die viele User nervt. Wieso probierst Du es also nicht aus, statt alles immer abzubügeln?
 
Ich hab leider nicht die Zeit dafür meinen Rechner jetzt auseinanderpflücken. Wäre bei mir nicht in 5 Minuten getan. Würde im gleichen Moment auch noch Leseleistung verlieren, die mir atm wichtiger ist.

Wir drehen uns eh alle im Kreis.

Du sagst der pseudo slc cache wird im idle geleert wird?

Der Powerstate 3 sagt doch schon aus, dass die SSD im idle sein muss. PS4 wird wahrscheinlich im Ruhemodus sein.

PS1 und PS2 hab ich atm auch nie gesehen. Da er unter Last auf PS0 springt.

@SimonX200 gibt es eine Möglichkeit PS1/PS2, wenn es die überhaupt gibt, zu aktivieren?
 
Zuletzt bearbeitet:
Nur weil ich noch keine Probleme habe, heißt es ja nicht, dass es bei Intel mit PCIe 4.0 und der SSD auch keine Probleme geben wird.
Vielleicht kommt es bei mir noch irgendwann? Meine hat keine 4TB writes bisher. Wie sieht das bei denen mit Problemen aus?
 
@King Bill
Mit dem StorNVME kann ich die SSD auf P0 halten.
P1/P2 habe ich noch nicht gesehen.
Wenn ich die Latency Tolerance zu hoch setzte, dann geht die System SSD gleich in P3 und die andere in P4.

@Uni
Bei mir ist es das erste mal bei so 15T am 2.2, dann 27T am 24.2, dann bei 36T am 24.3 auf der Systemplatte.
Die Writes auf der Systemplatte hatte ich identifiziert und reduziert. (Diagnostic Execution Service, Microsoft Update Health Service, SysMain, Windows Font Cache Service)
Auf der anderen Platte war es letzten das erste mal bei so 25T soweit.
 
So. Anscheinend hat sich gerade meine SSD gedacht, dass nicht mehr gebootet wird.

Sowas hab ich noch nicht erlebt 😓

Geil. Muss die SSD komplett neu formatieren...

Vll war der Intel NVME Treiber doch eher kontraproduktiv
 
Zuletzt bearbeitet:
Bananenware von Samsung braucht nun mal seine Zeit zum reifen...
Sollte aber eigentlich inzwischen ja jedem PC Hobbyschrauber klar sein, welches Risiko er mit dessen Kauf zum Martstart eingeht.

;)
 
Würde im gleichen Moment auch noch Leseleistung verlieren, die mir atm wichtiger ist.
Wieso sollte das Leseleistung kosten? Hängt sie dann nun an den Lanes der CPU oder denen des Chipsatzes? Es hängt offenbar vom Mainboard und wahrscheinlich auch dessen (Energiespar?)Einstellungen ab wie groß der Unterschied ist, aber im Review des ASUS ROG Crosshair VIII Dark Hero ist die Leseleistung bei 4k QD1 an den Lanes der CPU nur minimal besser, dafür ist der maximale Durchsatz am X570 minimal besser:

An der CPU:
ASUS_ROG_Crosshair_VIII_Dark_Hero_CDM_an_CPU.jpg


Am X570:
ASUS_ROG_Crosshair_VIII_Dark_Hero_CDM_an_X570.jpg


Insgesamt sind dies aber eher kleine Unterschiede die man fast noch als Messtoleranz abtun kann, merken wie die im Alltag keiner. Beim ASRock X570 Taichi Razer Edition war es im Review jedoch die Latenz beim Lesen an dern Lanes der CPU viel schlechter und auch die maximalen Leseraten unterscheiden sich deutlich:

An der CPU:
ASRock_X570_Taichi_Razer_Edition_CDM_CPU.jpg


Am X570:
ASRock_X570_Taichi_Razer_Edition_CDM_X570.jpg


Es sind ja die gleiche CPU und die gleiche SSD mit der die Reviews gemacht werden, PCIe 4.0 ist eindeutig auch aktiv, also sind hier gar offenbar agressivere Energiespareinstellungen aktiv, denn die Werte die besonders gelitten haben sie RND4K Q1T1 und SEQ1M Q1T1, also jeweils die mit QD1 wo es immer eine kleine Lücke in der Auslastung gibt, weil die CPU die nächste Anfrage ja erst stellt wenn die vorherige abgearbeitet worden ist und wenn dann jeweils der Energiesparzustand der SSD gewechselt hat, dann gibt es solche Einbrüche bei den Werten.

Du sagst der pseudo slc cache wird im idle geleert wird?
Ja, aber natürlich nur, wenn sie nicht in einem zu tiefen Ruhezustand ist. Denn wenn Zugriffe stattfinden, soll sie diese ja schnell abarbeiten und nicht durch das Leeren des Pseudo-SLC Caches im Hintergrund ausbremsen und wenn sie in den entsprechenden (keine Ahnung welches es für die SSD ist) Ruhezustand gebracht wird, soll sie Energie sparen.

Der Powerstate 3 sagt doch schon aus, dass die SSD im idle sein muss. PS4 wird wahrscheinlich im Ruhemodus sein.

PS1 und PS2 hab ich atm auch nie gesehen. Da er unter Last auf PS0 springt.
Keine Ahnung ab welchem Modus genau sie dann den Pseudo-SLC Schreibcache nicht mehr leert weil Energiesparen wichtiger ist, aber offenbar ist es bei PS3 ja schon der Fall, da die Schreibrate sich ja kaum wieder auf den Wert mit Pseudo-SLC Schreibcache steigt. Wie schnell springt sie nach einer Last wieder in den PS3 zurück? Da liegt könnte der Fehler liegen, nämlich dass sie im PS3 die Schreibcache nicht leert, aber nach einer Last statt im PS0 zu bleiben, zu früh in den PS3 geschickt wird.
Beitrag automatisch zusammengeführt:

Bananenware von Samsung braucht nun mal seine Zeit zum reifen...
So ein Quatsch, wenn es auf Intel Rocket Lake keine Probleme gibt, dann liegt es nicht an der SSD, ich vermute es liegt an den Energiespareinstellung durch das Mainboard und Samsung kann dies dann nur fixen, indem sie bestimmte Energiesparzustände einfach nicht mehr unterstützen oder indem sie dann trotz des gewählten Energiesparzustandes in dem eigentlich das Energiesparen verlangt gewesen wären, den Pseudo-SLC Schreibcache leeren und damit viel mehr Energie verbrauchen als für den Zustand vorgesehen wäre. Alternative könnte man den Usern auch sagen, sie sollte die BIOS Einstellung korrekt machen, was aber wohl einen Shitstorm gegen Samsung statt gegen die Meinboardhersteller / Windows Programmierer auslösen würde, also ist es besser wenn sie einen Workaround für die Fehler anderer einbauen.
 
Zuletzt bearbeitet:
Im CB-Forum gibt es jemanden, der das Problem auch auf dem neuen Intel Chipsatz hat.
Außerdem ist es nicht nur ein Samsung-Problem, sondern auch Corsair (MP510/MP600) ist z.B. betroffen. Siehe deren offizielles Forum...
 
sonny2, auch einzelne Meldung würde ich nicht zu viel geben, es kann auch sein das der Pseudo-SLC Schreibcache nicht geleert wird, weil die SSD einfach nicht Idle ist und das die Phison E12 mit der Zeit teils gewaltig und dauerhaft an Performance verlieren, ist lange bekannt. Der E16 ist auch nur ein auf PCIe 4.0 aufgebohrter E12, wenn dessen Performance ebenfalls mit der Zeit dauerhaft nachlässt, ist dies also alles andere als überraschend.
 
Fakt ist aber, dass nicht nur Samsung SSDs betroffen sind ;-)
Schau im offiziellen Corsair Forum. Das Problem ist dort seit Monaten, sogar Jahren bekannt und die entsprechenden Threads seitenlang.

Wie es beim neuen Intel sein wird, werden wir vermutlich bald sehen, wenn sich dort die Fälle auch häufen.
 
Im CB-Forum gibt es jemanden, der das Problem auch auf dem neuen Intel Chipsatz hat.
Außerdem ist es nicht nur ein Samsung-Problem, sondern auch Corsair (MP510/MP600) ist z.B. betroffen. Siehe deren offizielles Forum...

Kannst du diesen Bericht verlinken. M. W. gibt es dort bisher einen einzigen sehr schlichten Fallbericht. Unter welchen Rahmenbedingungen dieser aufgetreten sein soll, wird nicht dargestellt. Dass man auf Intels Comet Lake-Plattform ebenfalls einen Abfall der Schreibleistung auslösen kann, habe ich oben bereits beschrieben. Allerdings ist dieser schlimmstenfalls auf wenige Minuten, in denen der SLC-Cache geleert wird, beschränkt.
 
Schau im entsprechenden Thread dort selber nach. Ich werde da jetzt nicht die letzten 30 Seiten nach dem Post durchsuchen, wenn du in der Lage bist, es auch selber zu machen.
 
Dass man auf Intels Comet Lake-Plattform ebenfalls einen Abfall der Schreibleistung auslösen kann, habe ich oben bereits beschrieben. Allerdings ist dieser schlimmstenfalls auf wenige Minuten, in denen der SLC-Cache geleert wird, beschränkt.
Man kann bei jeder SSD mit Pseudo-SLC Schreibcache diesen füllen und dann schreibt sie eben langsamer, weil sie direkt ins TLC oder QLC NAND schreiben muss, aber derweil leert sie den Pseudo-SLC Schreibcache nicht. "Minuten, in denen der SLC-Cache geleert wird" ist also falsch, sondern eher, Minuten bis sie den lange genug Idle war um den Pseudo-SLC Schreibcache zu leeren.
 
Also ich finde im CB-Forum keinen einschlägigen Thread mit 30+ Seiten. In den Threads zur 980pro und pm9a1 gibt es insgesamt einen Einzeiler, nachdem ein 500GB-Modell auf Rocket Lake betroffen sei.
 
@SimonX200

Kannst du mal dein log posten?


Ich finde meine Data Units Written und Read arg hoch für ne SSD die gerade mal 1 Monat lief.


PM9A1

Code:
C:\Program Files\smartmontools\bin>smartctl -A /dev/sdb
smartctl 7.2 2020-12-30 r5155 [x86_64-w64-mingw32-w10-20H2] (sf-7.2-1)
Copyright (C) 2002-20, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF SMART DATA SECTION ===
SMART/Health Information (NVMe Log 0x02)
Critical Warning:                   0x00
Temperature:                        43 Celsius
Available Spare:                    100%
Available Spare Threshold:          10%
Percentage Used:                    1%
Data Units Read:                    56.085.510 [28,7 TB]
Data Units Written:                 38.253.171 [19,5 TB]
Host Read Commands:                 1.416.982.831
Host Write Commands:                1.001.016.994
Controller Busy Time:               261
Power Cycles:                       162
Power On Hours:                     346
Unsafe Shutdowns:                   28
Media and Data Integrity Errors:    0
Error Information Log Entries:      0
Warning  Comp. Temperature Time:    0
Critical Comp. Temperature Time:    0
Temperature Sensor 1:               43 Celsius
Temperature Sensor 2:               47 Celsius


Dagegen meine 1 1/2 Jahre alte 970evo (alte System SSD)


Code:
C:\Program Files\smartmontools\bin>smartctl -A /dev/sdc
smartctl 7.2 2020-12-30 r5155 [x86_64-w64-mingw32-w10-20H2] (sf-7.2-1)
Copyright (C) 2002-20, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF SMART DATA SECTION ===
SMART/Health Information (NVMe Log 0x02)
Critical Warning:                   0x00
Temperature:                        39 Celsius
Available Spare:                    100%
Available Spare Threshold:          10%
Percentage Used:                    1%
Data Units Read:                    81.250.071 [41,6 TB]
Data Units Written:                 74.922.610 [38,3 TB]
Host Read Commands:                 912.097.676
Host Write Commands:                869.506.434
Controller Busy Time:               3.057
Power Cycles:                       2.414
Power On Hours:                     5.289
Unsafe Shutdowns:                   391
Media and Data Integrity Errors:    0
Error Information Log Entries:      6.707
Warning  Comp. Temperature Time:    0
Critical Comp. Temperature Time:    0
Temperature Sensor 1:               39 Celsius
Temperature Sensor 2:               40 Celsius

Nochmal mit CrystalDiskInfo

PM9A1

1618257319405.png


970 evo

1618257345862.png
 
Zuletzt bearbeitet:
Ich finde meine Data Units Written und Read arg hoch für ne SSD die gerade mal 1 Monat lief.
Da kann ja die SSD nichts dafür, wenn da viel gelesen und geschrieben wird, dies macht ja der Rechner in dem sie steckt. Aber wenn so viel darauf zugegriffen wurde, dann sollte es nicht wundern wenn deren Pseudo-SLC Schreibcache immer wieder voll ist und nicht geleert wurde, wenn gebencht wird. Wenn Du Dir nicht erklären kann woher diese Zugriffe kommen, dann musst Du wohl den Resourcen Monitor und HWInfo64 -> mitlaufen lassen und immer mal wieder beobachten was die ganzen Zugriffe erzeugt.
 
Deswegen frag ich doch ob es nur an meinem System liegt oder allgemein an der SSD.
 
Es kann nur am System liegen, eine SSD kann ja nicht selbst Lese- oder Schreibbefehle erzeugen, die müssen immer vom System kommen.

Die neue hat ja sogar mehr Befehle, vor allem mehr Lesebefehle, erhalten als die alte 970 Evo:
Host Read Commands: 1.416.982.831
Host Write Commands: 1.001.016.994

zu:
Host Read Commands: 912.097.676
Host Write Commands: 869.506.434
 
Die Writes auf der Systemplatte hatte ich identifiziert und reduziert. (Diagnostic Execution Service, Microsoft Update Health Service, SysMain, Windows Font Cache Service)

@King Bill

Ich hatte auch erst suchen müssen. SysInternals procmon ist dein Freund.

Ich hatte massive Log file writes von Windows. Den Diagnostic Execution Service und die anderen habe ich disabled.
Der Windows Defender hat auch viel geschrieben Den habe ich durch einen andere AV ersetzt.

Wenn ich jetzt nicht arbeite, dann schreibt nur noch Chrome seine unzähligen Cachfiles und sonst eigentlich nichts wesentliches.
Bei der Arbeit schreibt VSCode und VS gerne, aber nicht viel.

Vom 25.3 bis heute den 12.4 wurden 3T, oder 180M pro Tag, auf die Systemplatte geschrieben.
Stehe jetzt bei 42.8T auf der Systemplatte.

BTW:

Windows ist ein Schmutzfink.
Schreibt z.B. regelmäßig logfiles in c:\Windows\System32\config\Software.LOG1 (
Hat da definitiv nichts zu suchen. Kann man nicht abstellen.

 
Zuletzt bearbeitet:
ich hab irgendwie eine böse vermutung in verbindung mit der neuen nzxt cam software.


da gehts primär um freezes und cpu auslastung. aber die aktuelle version verursacht bei mir ab und zu 4-5mb/s schreiblast auf der ssd.

aber da muss ich erstmal weiter beobachten. dennoch kann das nicht direkt soviele Terabytes machen. Auch die Benches waren nicht mehr als mit der 970evo.
 
aber da muss ich erstmal weiter beobachten.
Richtig, nur so kannst Du rausfinden was da wie viel auf die SSD schreibt, der Resourcen Monitor ist gut, weil man da sehen kann welcher Prozess auf welche Datei zugreift, bei HWInfo64 -> Sensors sieht man gut in Echtzeit wie viel gerade gelesen und geschrieben wird und wenn es mal wieder unerwartet viel ist, dann wechselt man schnell auf den Resourcen Monitor um zu sehen welcher Prozess auf welche Datei zugegeriffen hat.
dennoch kann das nicht direkt soviele Terabytes machen.
Wenn man eine Diagnose macht, sollte man unvoreingenommen da rangehen und nicht vorab aufgrund des Bauchgefühls irgendwelche Schlüsse ziehen, sonst wird das meistens nichts.
 
Wenn ich jetzt nicht arbeite, dann schreibt nur noch Chrome seine unzähligen Cachfiles und sonst eigentlich nichts wesentliches.

Der Chrome schreibt so mehrere 10G pro Tag. Viel in den DiskCache.
Den habe ich jetzt in eine StarWind Ramdisk mit 2G verlegt.
Funktioniert gut.
 
In den letzten Tage habe mit unterschiedlichen Schreiblasten versucht, den Leistungsabfall auf einer PM9A1 zu triggern. Zunächst habe ich dazu ausschließlich sequenzielle Zugriffe, welche über die Größe des SLC-Caches hinausgehen, angewendet. Die Schreibleistung hat sich dabei mit dem Leeren des SLC-Caches immer wieder auf ca. 3,5 GB/s regeneriert. Später habe ich ca. 1,2 TB mit hohem Anteil an Random-Zugriffen am Stück geschrieben. Dieser Test liegt nun vier Tage zurück. Inzwischen hat das System viele Stunden im Idle verbracht. Die sequenzielle Schreibleistung hat sich trotz Leerens des SLC-Caches ( man kann diesen Vorgang anhand des Parameters "namespace utilisation" mit smartctl gut beobachten) aber nicht mehr vollständig erholt und liegt derzeit bei etwa 2,5GB/s.
 
Wieso die Leerung oder Nichtleerung des Pseudo-SLC Schreibcaches von der Art (sequentiell, random) der Schreibzugriffe abhängig sein sollte, lässt sich logisch nicht erklären und ist bei anderen SSDs meines Wissens auch nicht der Fall. Es dürfte also ein FW Bug sein, aber es erklärt, wieso der Schreibcache nach dem Ausspielen eines Images, was ja sequentielles Schreiben ist, dann wieder geleert wurde und die Schreibrate sich wieder erholt hat.
 
Glauben kannst du in der Kirche.

Ich hatte die MP510 und MP600 und es betraf ebenfalls nur die Schreibleistung.
Wie gesagt: Schau in das offizielle Corsair-Forum.........
 
Glauben kannst du in der Kirche.
Mit so einem Spruch gewinnt man keine Sympathiepunkte und ins Corsair-Forum werde ich sicher auch nicht schauen. Die genannten Corsair haben einen ganz anderen Controller als die Samsung SSDs um die es hier geht, daher sind das sowieso getrennte Fälle, auch wenn es in beiden Fällen nur FW Bugs sein sollten.
 
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