Readspeed degradation 2022 kein Thema mehr ? Von wegen ! MP510 -> 14MB/s ! 980pro auch nicht ohne Probleme...

Nicht nur WD...
+Corsair MP510 ...
+Crucial P5Plus ...
+Samsung 970 EVO Plus ...
(siehe den Eingangspost - ich halte den Momentan aktuell und Sammle)
Meine Samsung 980Pro zeigt auch Tendenzen nach unten. Auch wenn ich hier nicht von einem "Versagen" des Refreshes sprechen würde (noch nicht? die Platte ist einfach auch ein Jahr Jünger gewesen als meine MP510)... Trotzdem ist sie vor dem manuellen Refresh auf 4GB/s (overall, spielepartition) unten gewesen und danach auf 5.7GB/s hoch).
 
ThommyDD schrieb:
Viel Spaß, wenn nach einem Jahr dein Windows nicht mehr startet, weil eine länger nicht upgedatete Bibliotheksdatei nicht mehr lesbar ist.
Aber genau das ist doch gar nicht passiert. Der Threadersteller redet eingangs von 2-3 Jahre alten Dateien und auch diese wurden korrekt gelesen, nur halt nicht in der von euch erwarteten Geschwindigkeit. Keins der hier aufgezeigten Beispiele im Thread hat Lesefehler aufgezeigt so das Daten gar nicht mehr lesbar waren.

"In Betrieb" an sich ist schon ein ziemlich schwammiger Begriff, da es Powersave Modi gibt wo sowohl der Flash als auch der Großteil des Controllers stromlos sind und damit einem Zustand ensprechen wo die SSD auch im Schrank liegen könnte, nur das viele denken würden sie wäre in Betrieb weil der Rechner mit der SSD drin doch an ist.

Die FW hat ein paar wenige Parameter woran sie einen Refresh festmachen kann. Zeit, so wie hier schon angesprochen wurde in der Form "Zwei mal pro Jahr" oder so gibt es nicht. Der Controller und die FW haben keinen persistenten Zeitgeber. Ob zwischen zweimal Power On ein Tag oder ein Jahr vergangen ist, kann die FW nicht wissen. Ein zweiter möglicher Parameter sind die Power On Hours, aber die können durch die Stromsparmodi sehr verfälscht werden und der Trigger für den Refresh darauf muss sehr konservativ gesetzt werden. Daher ist eins der eindeutigsten Kriterien Bitfehler beim Lesen. Man liest einfach die Daten, sieht wieviel Fehlerkorrektur notwendig ist und erst wenn sich dadurch andeutet dass es zu Problemen kommen kann wird umkopiert. Und nur weil es längert dauert, heißt es noch lange nicht das die FW gleich umkopiert. Erst wenns eng wird, wird gehandelt, da ja im gleichen Atemzug weitere Prüfungen notwendig sind, ob der Block noch in Ordnung ist, da fehlerhafte Daten durch Alterung nicht sofort unterschieden werden können von fehlerhaften Daten durch andere Defekte im Flash.

Man darf nie vergessen das Löschzyklen sparen das große Motto über alles ist, daher wird quasi nichts proaktiv gemacht was ohne technischen Grund Löschzyklen verbraucht.
 
  • Gefällt mir
Reaktionen: Corpus Delicti
Chuuei schrieb:
Aber genau das ist doch gar nicht passiert. Der Threadersteller redet eingangs von 2-3 Jahre alten Dateien und auch diese wurden korrekt gelesen, nur halt nicht in der von euch erwarteten Geschwindigkeit. Keins der hier aufgezeigten Beispiele im Thread hat Lesefehler aufgezeigt so das Daten gar nicht mehr lesbar waren.

"In Betrieb" an sich ist schon ein ziemlich schwammiger Begriff, da es Powersave Modi gibt wo sowohl der Flash als auch der Großteil des Controllers stromlos sind und damit einem Zustand ensprechen wo die SSD auch im Schrank liegen könnte, nur das viele denken würden sie wäre in Betrieb weil der Rechner mit der SSD drin doch an ist.
Wenn der Controller die Daten innerhalb von 2-3 Jahren nicht aufgefrischt hat und selbst bei Zugriff mit 7-12MB/s und Antwortzeiten >2s noch nicht - was ist dann Plausibler ? Dass er in einem weiteren Jahr auffrischt oder dass er in einem weiteren Jahr gar nicht mehr drauf zugreifen kann ?

"Von uns erwarteter Geschwindigkeit" - welche Geschwindigkeit darf ich von einer PCIe Gen 3 Nvme die mit >3GB/s verkauft wird denn erwarten ? Muss ich 7-10MB/s erwarten (so weit unten wars bei mir)?

Und "in Betrieb" ist nicht schwammig - das kann man auslesen:
Im Falle meiner MP510 sagt SMART die Platte war 17812 Std. in Betrieb ... Das sind mal eben 16 Stunden am Tag die letzten 3 Jahre... Ich würde mal sagen das ist nicht "im Schrank"... Ich gehe davon aus, dass in Betrieb nur Stunden gezählt werden in denen zumindest der Controller wach/die Platte nicht Stromlos war, denn sonst wüsste ich nicht wie er die Stunden sonst erfassen will... War auch kein Laptop...

Aber: Meine Überlegungen gehen auch dahin ob es Einstellungen gibt die den Refresh behindern...

Sonst wüsste ich nicht warum so wenige Meldungen rein kommen... Anderseits - wie schon an meinem Beispiel: Die Geschwindigkeit war auf 7-12MB eingebrochen. Die Ladezeit von Plague Tale 1 war damit bei 2-3 Minuten pro Kapitel. Da wird man misstrauisch... Wäre die Speed "nur" auf 250MB/s eingebrochen dann wären wir so grob bei 5-10 Sekunden -> da hätte ich vermutlich eher an ein schlecht optimiertes, älteres Spiel gedacht... Und vermutlich haben auch nicht so viele ein Spiel 3 Jahre auf der Platte und starten es auch noch...

Ich verstehe das Problem der Hersteller: Immer billigere Speicher (pro MB) mit immer höherer Packdichten und dafür immer schlechterer Zyklenfestigkeit und vermutlich auch Haltezeit der Ladungen... Also müsste der Controller beim Refresh immer aggressiver vorgehen um die Geschwindigkeit oben zu halten - was aber die schlechtere Haltbarkeit noch schlimmer machen würde... Trotzdem scheint hier zB Corsair übers Ziel hinausgeschossen... Was bringen mir 1700TBW wenn die Platte die Lesegeschwindigkeit dafür auf 10MB/s einbrechen lässt und Datenverlust als Gespenst zumindest mal im Raum steht... Hättens mal lieber 800TBW versprochen und dafür die Refresh Zyklen gescheiter gemacht... WENN nicht was anderes Faul/die Ursache ist...
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: Drahminedum, ThommyDD, Teeschlürfer und eine weitere Person
Ich hab einen Fall aufgezeigt wo "in Betrieb" einer stromlosen SSD entsprechen kann, scheint bei dir nicht der Fall zu sein, okay.

Aber die Aussage mit welchen Datenraten man rechnen muss irritiert mich schon ein wenig. Bei 4k random ohne Parallelität schafft ne MP510 im besten Fall auch nur zwischen 40 - 50 MB/s. Das sagt dir sogar CDM. Und das ist kein außergewöhnlich schlechter Wert. Es gibt in der Praxis nur ganz ganz wenige Situationen wo SSDs im realen Betrieb auch nur annähernd an ihre beworbenen Geschwindigkeiten kommen.
 
Klar kommt es auf den typischen Datenmix an... Die Zeiten in denen Spiele aber mit einer Trillion Einzeldateien daher kamen sind meist auch vorbei... Denn auch die Spielehersteller wollen gute Ladezeiten und packen die Dateien daher zusammen in größere Files... Und spätestens der Gegentest zeigts doch...
Vor dem erzwungenen/manuellen Refresh: Zugriff auf meinen Datenmix (c.a. 600GB Spiele) -> Durchschnitt 14MB/s
Danach 3GB/s (exakt die selben Daten) ... Also war 14MB/s ein (unnötig) schlechter Wert...
(Fast) alles was ich hier mit die Durchkaue wäre übrigens auch im Eingangsposting gestanden auf das ich daher nochmal hinweisen möchte... Der erste Post wird von mir gepflegt und enthält eine Liste mit Infos und den Platten die durch einen Refresh messbar schneller wurden...

Was man als Verbraucher erwarten kann - darum müssten sich dann vermutlich zur Festlegung Gerichte kümmern (das ist kein Aufruf zu Klage)... Ich würde sagen bei einer Platte die für Gamer vermarktet wird sollte beim typischen Mix den Games heutzutage bringen mindestens 66% (2/3) der beworbenen Speed auch anliegen - auch nach 2 oder 3 Jahren noch - es sei denn es limitieren halt Faktoren wie die CPU oder die Anbindung... (oder die Platte lag im Schrank) <- das ist eine MEINUNG...

Fakt ist jedoch dass es in jüngster Vergangenheit Gerichtsurteile gab, die sich mit solchen Fragen beschäftigten und Formulierungen wie "bis zu x unter optimalen Bedingungen" in die Schranken wiesen...
 
Zuletzt bearbeitet:
BigKid1973 schrieb:
Und spätestens der Gegentest zeigts doch...
Nicht zwangsweise, da du damit noch einen ganz anderen Effekt unabhängig von der Alterung beeinflusst.

Die Lesegeschwindigkeit einer SSD ist von zwei Faktoren abhängig. Einmal die Art wie gelesen wird. Das können wir bei deinem Versuch mal als konstrant betrachten. Der zweite Faktor, der allermeisten ignoriert wird, wie wurden die Daten geschrieben.

Ich denke es ist nicht ganz falsch anzunehmen, dass die Spielesammlung ursprünglich über eine gewisse Zeit gewachsen ist. Also mal wurde was installiert, dann das nächste Spiel irgendwann später, vielleicht mal nen Spiel deinstalliert, dann wieder was zugekommen usw. Dazwischen mal Daten der alten Spiele geändert durch Patches etc. Das führt zu sehr fragmentierten Mappingtabellen der FW (nicht der Daten, die mögen die SSDS ja kreuz und quer über alle Flashes).

Das ist eine ganz andere Ausgangslage, als wenn du alle Daten durch nen Refresh neu schreibst und alles hintereinander in den Mappingdaten ist. Da hat die FW wesentlich weniger Arbeit zu leisten.

Es gibt z.B. hier von Swissbit, einem deutschen SSD Hersteller, eine AppNote zu dem Thema.

Nicht falsch verstehen, ich stimme euch zu, dass eure aufgezeigten Problem SSDs in den Fällen es durchaus vielleicht besser hinkriegen sollten. Aber meine ganzen Beiträge zeigen hoffentlich das es alles andere als trivial ist zu bewerten, was ist schlechtes Verhalten, was ist gutes Verhalten und was ist fehlerhaftes Verhalten.
 
Zuletzt bearbeitet:
"Das führt zu sehr fragmentierten Mappingtabellen der FW (nicht der Daten, die mögen die SSDS ja kreuz und quer über alle Flashes)."

Wenn dem so wäre, dann wäre der eigentlich unisono anerkannte Fakt dass Defrags bei SSDs (eigentlich) unnötig sind FALSCH... Siehe: HIER (CT)
"Für uns noch relevanter: Die einzelnen Speicherzellen von SSDs werden grundsätzlich immer mit der gleichen Geschwindigkeit erreicht. Es macht also beim Lesen und Schreiben von Daten auf der SSD keinen Unterschied, ob die Datenblöcke hintereinander oder verteilt liegen."

Das gilt natürlich auch für die Mapping Tabelle selbst. Der Einfluss ist zu vernachlässigen. Mal ganz abgesehen davon, dass ich annehme, dass die Mapping Tabelle in einem Cache liegt (so vorhanden).

Dazu kommt, dass ja das Wear-Leveling ja auch dazu führt, dass die Daten früher oder später sowieso kreuz und quer liegen... Der Controller/die Firmware muss also eh mit verteilten Daten klar kommen...


Also nein... Der Defrag bewirkt demnach keine wirklich relevante Veränderung ausser dem Auffrischen durch Neuschreiben... WENN die Platte am Ende ihrer Lebenszeit wäre, DANN könnte der Defrag dazu führen das Blöcke auf "bessere Zellen" wandern... bei 4TB von 1700TBW gehe ich mal nicht davon aus dass es wirklich schlechte Zellen gibt...
 
Zuletzt bearbeitet:
Lies dir bitte die verlinke AppNote durch. Da ist es sehr anschaulich erklärt. Es geht um die Fragmentierung der Mappingdaten, nicht um die der Daten im Flash. Sind zwei paar komplett unterschiedliche Dinge.

Und die Aussage im verlinkten Artikel stimmt einfach nicht bzw. verallgemeinert viel zu sehr. Es fängt damit an, dass Flash Zellen nicht unabhängig angesprochen werden können sondern bei NAND Flash eine Page (deren Größe ist abhängig vom Flash) die Mindesteinheit ist. So wie beim Schreiben (was immer ein Löschen erzwingt) ein Block die Mindesteinheit ist. Oder wenn man z.B. Daten liest die auf zwei Flashes verteilt sind die am gleichen Flash Channel hängen, dann ist ein gleichzeitiges Lesen auch unmöglich weil beide Flashes erst nacheinander per ChipEnable aktiviert werden müssen. Der Autor möchte wahrscheinlich einfach sagen, dass Daten bei SSDS nicht physisch sequentiell im Speicher liegen müssen, das ist korrekt, wäre sogar eher kontraproduktiv.

Aber ob ich mir 100MB Daten als einen Block in den Mappingtabellen mit einem Lookup holen kann weil die damals sequentiell in einem Block geschrieben werden konnten, oder 20000 Lookups benötige, weil es alles kleine 4k Blöcke waren die dann vielleicht auch noch kreuz und quer verteil sind. Das macht nen riesen Unterschied.
 
Würde ich gerne - aber der Link ist nicht korrekt so wie es aussieht...

Trotzdem wiederhole ich die Frage: Liegt die Mapping Tabelle nicht eh im Cache sodass die Fragmentierung der Tabelle selbst nach dem ersten Load keinen Walzer spielen sollte ?

Und können die restlichen Effekte wirklich einen Einbruch von 3GB/s auf 14MB/s erklären ?
Oder von 400MB/s auf 9MB/s (SATA) ? Oder auch nur von 4GB/s auf 2GB/s ?

Wenn dem so wäre, dann wäre die Aussage das Defrags bei SSDs nicht nur unnötig sondern schädlich sind einfach FALSCH sondern die Empfehlung müsste dann eher sein das alle 6 Monate zu machen...
Glaubst du nicht, dass nicht mindestens 1 Hersteller von Defrag Software damit Hausieren gehen würde ?
 
Zuletzt bearbeitet:
Opps, mein Fehler, hab den Link korrigiert.

Und ja, bei SSDs mit DRAM liegt im Idealfall die gesamte Mappingtabelle dann im Cache. Aber so ein Lookup ist ja trotzdem nicht kostenlos und erfordert Rechenzeit durch die Controller. Was bei jedem Lookup genau gemacht wird gibt kein Hersteller komplett preis, aber es finden ja verschiedenste Aktionen statt neben dem dann folgenden Flash Zugriff, wie z.B. die Prüfungen fürs Wear Leveling, Read Disturb Management etc. Es muss geguckt werden ob z.B. noch zu schreibende Daten in den pSLC Cache passen oder ob umkopiert werden muss in den TLC Bereich etc. Sind nur Beispiele, geht einfach darum, das jedes mal ne ganze Latte von Dingen zusätzlich zumindest geprüft werden muss und daher sind weniger Zugriffe besser als viele.
 
Der Link geht immernoch nicht ... Ich glaube aber du liegst falsch...

"Logical block addresses (LBA) including the related static sector address or information are mapped correspondingly to physical block addresses (PBA). A table is maintained by the controller or firmware, translating requests for the particular LBA to its corresponding PBA. Logical blocks are distributed across all available Flash chips and ‘good’ blocks, e.g. logical block 0 might correspond to a physical block at chip 1 block 2, and logical block 1 might correspond to a physical block on chip 3, block 3."

So wie ich das Lese muss sowieso JEDER logische Block auf einen physichen Block gemapped werden...
Weil eben bei SSDs nicht nur der User mit der Zeit für Chaos sorgt sondern auch das Wear Levelling... Dann wird das quasi in Hardware gemacht werden und kostet keine Zeit...
 
Bist zu schnell, hab den Link erst nach dem Beistrag erstellen angepasst :)

Ja klar muss alles gemappt werden, die Frage ist nur wie oft muss nachgeguckt werden um alle Informationen zu erhalten und wie oft werden dadurch weitere Aktionen getriggert.
 
Wenn sowieso ALLES gemapped werden muss dann wird SOWIESO jeder einzelne LBA bei jedem Zugriff auf einen Physischen gemapped... Dann gibts da kein mehr oder weniger...
Dann ist das auch ne statische Tabelle (fixe anzahl Zeilen und Spalten) und somit erfolgt der Zugriff quasi (zeit)verlustfrei weil man das in Hardware giessen kann...

https://www.elinfor.com/knowledge/overview-of-ssd-structure-and-basic-working-principle2-p-11204

"Andere Aktionen" dürfte es nur beim Schreiben geben - zB das Wear Levelling...
Der Refresh dürfte meist ein Task sein, der im Hintergrund laufen sollte wenn die Platte nichts zu tun hat... Auch wenn man also annehmen sollte, dass die Platte merkt dass was Faul ist wenn der Zugriff wie bei mir 2s (statt 0,1ms und mit 12MB statt 3GB/s erfolgt und dann was tut ("Andere Aktionen") - scheints ja in der Praxis nicht so zu sein...

EDIT: Jetzt geht der Link von dir... Danke dafür...
"Die Lesegeschwindigkeit ist nicht von so vielen Faktoren abhängig wie die Schreibgeschwindigkeit. Hier kommt es nur darauf an, mit welcher Zugriffsart geschrieben wurde und wie gelesen wird. Die Daten in Abschnitt 1 wurden zufällig geschrieben und wieder zufällig – aber in einer anderen Reihenfolge – gelesen. Hier wird die geringste Leseleistung erreicht, da der Suchaufwand in den Zuordnungstabellen sehr hoch ist und die Effizienz der Datenübertragung zwischen Speichermedium und Host wegen der Paketgröße von 4 KiB gering ist. In Abschnitt 2 werden zufällig geschriebenen Daten sequentiell gelesen. Die Lesegeschwindigkeit ist viel höher, da pro Zugriff nun 128 KiB zum Host übertragen werden, was die Effizienz erhöht. Der Suchaufwand in den Zuordnungstabellen ist aber weiterhin sehr hoch. Vor Abschnitt 3 wurde das Speichermedium nun sequentiell beschrieben. Die Lesezugriffe in diesem Abschnitt wurden zufällig ausgeführt. Entsprechend niedrig fällt die Lesegeschwindigkeit wegen der Paketgröße von 4 KiB aus. Durch das sequentielle Schreiben ist die Suche in den Zuordnungstabellen aber einfacher und die Geschwindigkeit höher als in Abschnitt 1. In Abschnitt 4 erreicht das Speichermedium die maximale Leseleistung. Die sequentiell geschriebenen Daten werden nun auch sequentiell in 128 KiB-Paketen gelesen. Die Suche in den Zuordnungstabellen ist sehr einfach, die Übertragung zum Host sehr effizient, und beim internen Zugriff auf den NAND-Flash kann „Read-Ahead“ zum Einsatz kommen. Bei einem Speichermedium mit pSLC-Cache würden in den vier Abschnitten für einen Teil der Speicheradressen eine höhere Lesegeschwindigkeit auftreten – nämlich dann, wenn diese Adressen im pSLC-Cache liegen. "

Sorry... Meiner Meinung nach ist das nur eine Detailliertere Erklärung warum 4k Random Read langsamer ist als Sequentieller Read... ;) Meiner Ansicht nach steht da auch ausdrücklich, dass es nur um die Reihenfolge geht in der die Daten geschrieben vs. die Reihenfolge in der sie gelesen werden und eben nicht darum wie verteilt sie auf der Platte liegen... Es ist beim Defrag davon auszugehen, dass die Daten wieder in der selben Reihenfolge geschrieben werden wie vorher - nur eben am Stück... sonst hätte der Defrag das Thema verfehlt... Mir fallen nur ganz wenig Anwendungsfälle ein bei denen EIN FILE nicht am Stück geschrieben würde...

Nach meinem Verständnis hat das also rein garnix damit zu tun, dass ein Defrag auf einer SSD einen anderen positiven Effekt haben könnte als den Refresh durch Rewrite...
 
Zuletzt bearbeitet:
Ich bezweifle auch stark, dass bei einer SSD mit Mapping Table im DRAM da irgendein deutlicher Unterschied besteht und erst recht nicht in solchen Größenordnungen.
 
Ich würde ehrlich gesagt auch bei Platten ohne DRAM davon ausgehen, dass darauf geachtet wurde, dass das Mapping performant bleibt.. zB indem die Mapping Tabelle in einem speziellen Teil des Speichers liegt - eben damit das Mapping zumindest Teilweise in Hardware gelöst werden kann...
 
Also ich habe mal eine MX500 2 TB und eine MX300 750 GB überpüft. Die waren völlig unauffällig.
 
22x Firmware = IMFT NAND (Intel/Micron Joint Venture). Die Firmware mit dem NAND scheint nicht betroffen bzw deren NAND hält die Ladezustände länger als der WD/Sandisk BICS3 bei den 11x/12x Firmware-Typen
 
  • Gefällt mir
Reaktionen: Engaged
Ich habe noch eine Samsung 860 Evo 2 TB getestet, die sich in einem externen Gehäuse befindet.

Erstes Ergebnis:
2022-11-10 22.16.39 Results for L.png


Eindeutig betroffen! Danach habe ich versucht es in Dateiübertragungen im Explorer nachzustellen. Da war die Geschwindigkeit aber normal hoch.

Daher noch ein Durchlauf gemacht:
2022-11-11 00.07.09 Results for L.png


Es wurde nichts von mir unternommen! Nun ist die Frage, was hier passiert ist. Ich gehe davon aus, das die Firmware der 860 Evo gemerkt hat, dass die Zellen erneuert werden müssen und hat das dann parallel auch getan. Daher ist die Geschwindigkeit nun wieder normal.

Aber sollte das so sein? Die SSD war zwischenzeitlich etliche Stunden angesteckt, auch im Idle. Hätte die Firmware dass da nicht schon auffrischen müssen?
 
Vor einiger Zeit hatte ich bei meiner MX500 eine hohe write amplification festgestellt und auch in diese Richtung gesucht. Bin mir nicht mehr sicher ob das Dokument von Micron/Crucial stammte, aber da ging es eben auch um solche Entscheidungen. Lebensdauer oder schnelle Zugriffe.
Das Problem was ich hatte und auch noch immer habe ist, scheint vor allem bem 24/7 Betrieb aufzutreten. Da sie SSD dauerhaft an ist wird öfters neu umkopiert und es entsteht die hohe WAF.

Das müsste auch ja auch nochmal finden lassen.
 
  • Gefällt mir
Reaktionen: Engaged
Zurück
Oben