840 evo 1 TB ist lahm auf "alten" Daten

[klampf]

Ich würde mich freuen, wenn du uns auf den aktuellen Stand hältst.

Mach ich gerne
Als erste Antwort kam ein Fragebogen, den es auszufüllen gilt. Systeminformationen wie Motherboard, Treiber usw. sind gefragt.
Das kann ich heute abend erst machen.
Crystalkdiskinfo-Ouptut hatte ich schon gelich mitgeschickt.

 

[Holt]

Auf meiner 4 Wochen alten EVO tritt das Problem ansatzweise schon bei 0 Zyklen (laut Magician S.M.A.R.T. Info) auf.

Das ist ja nur ein Durchschnittswert und wenn Du 80% der Kapazität anfangs beschreibst, dann wird ja noch nichts gelöscht, nur im TurboWrite Puffer, aber dessen Zyklen scheinen da nicht mit erfasst zu sein, was auch sinnvoll ist.
Dann lässt Du 10% frei und kannst die übrigen 10% schon 10x beschreiben, bevor Du im Schnitt den ersten P/E Zyklus erreicht hast, die Zellen in denen nicht diese 80% künftig alter Daten liegen, haben dann aber so zwischen 5 und 10 Zyklen hinter sich, die anderen einen halb, die ja erst das P (Programm) und noch nicht das E (Erease) vom P/E Zyklus erfolgt ist.

der Grund könnte evtl auch in einem ursprünglichen ungünstigen Schreibvorgang liegen da es bis jetzt nur relativ wenige Dateien betrifft

Wie wurden sie denn ungünstig geschrieben? Nicht am Stück mit seq. Schreibzugriffen? Dann wäre es i.d.R. möglich, dass das diese langsam gelesen werden, etwa log Dateien die kontinuierlich ein Stück wachsen.

 

[Blublah]

Wie wurden sie denn ungünstig geschrieben? Nicht am Stück mit seq. Schreibzugriffen? Dann wäre es i.d.R. möglich, dass das diese langsam gelesen werden, etwa log Dateien die kontinuierlich ein Stück wachsen.

Nein eigentlich nicht. Sind 30MB RAW Dateien die ich einfach von einer HD kopiert habe als die SSD noch völlig jungfräulich war. Deswegen denke ich, dass bei diesen erst 4 Wochen alten 200-300 MB/s Dateien anscheinend schon das langsamere Lesen eingesetzt hat.

Und dabei hab ich die SSD wie gesagt noch nicht 1x komplett vollgeschrieben. Momentan mach ich extra praktisch nix drauf damit ich mir die für mehr Tests so belasse.

 

[Hallo32]

Was bencht eigentlich AS SSD/Atto/usw. bei der EVO?

Theoretisch doch nur den TurboWrite Puffer, der bei der kleinsten Version schon 3GB hat, oder?

Ergänzung (10. September 2014)

Wie wurden sie denn ungünstig geschrieben? Nicht am Stück mit seq. Schreibzugriffen? Dann wäre es i.d.R. möglich, dass das diese langsam gelesen werden, etwa log Dateien die kontinuierlich ein Stück wachsen.

Bleiben diese "Informationen" eigentlich beim Verschieben der Daten vom TurboWrite Puffer in den TLC erhalten?

 

[Blublah]

Was bencht eigentlich AS SSD/Atto/usw. bei der EVO?
Theoretisch doch nur den TurboWrite Puffer, der bei der kleinsten Version schon 3GB hat, oder?

Ja. Aber der Turbo scheint nicht direkt das Problem zu sein denn verschiedene Leute haben schon ein komplettes Backup ihrer SSD gemacht und das dann wieder draufgespielt. Danach waren die Leseraten über die gesamte SSD 1a. Es ist also nicht so, dass prinzipiell nur Daten aus dem Turbo schnell gelesen werden. Der Turbo Cache ermöglicht primär höhere Schreibraten.

 

[Hallo32]

@Blublah

Dass der Turbo für die Schreibraten da ist, ist mir bekannt. Mir stellte sich nur die Frage, warum das Problem bis jetzt nicht in einen Review aufgefallen ist.

Liegt es an den verwendeten Benchmarks und den Turbo oder ist es ein systematischer Fehler in den Reviews?

 

[Blublah]

Na ja, in den Reviews werden ja fast nur Benchmarks eingesetzt die ihre Testdateien selber neu erstellen. Dabei tritt das Problem ja nicht auf. Wenn man genau wüsste, was der Auslöser der Verlangsamung ist, könnte man sicher auch gezielt danach testen. Genauso wie irgendwann die SSD Tester angefangen haben die Steady State Performance in ihre Tests einzuschliessen.

Bei HDs war es gegenüber SSDs noch relativ einfach praktisch alle Aspekte zu testen scheint mir.

 

[klampf]

Bei HDs war es gegenüber SSDs noch relativ einfach praktisch alle Aspekte zu testen scheint mir.

Die haben nicht so ein "intelligentes" Eigenleben entwickelt, aber Besonderheiten gab es da auch immer wieder. Festplatten die am Anfang immer ein Verify gmeacht haben und eshalb nur mit halben Speed schreiben oder welche, die nach 3 Sek. idle den Kopf schon reinfährt.

Jetzt wurden ja die ersten HDD Spuren vorgestellt, die überlappend geschrieben werden, die fangen dann auch an irgendwie zu optimieren und müssen mehr neu Schreiben als nur die geänderten Daten. Das wird spannend.

 

[Holt]

Ja, eigentlich benchen diese Benchmark nur den TurboWrite Puffer, aber der Filebench misst ja die Lesegeschwindigkeit der Dateien auch im normalen NAND Bereich, denn da landen sie ja schon nach wenigen Minuten im Idle. Beim Kopieren dürfte der Fehler also noch nicht passieren, die Dateien werden ja in den ersten Tage, Wochen, Monaten noch schnell gelesen. Daher bleiben die Informationen also wohl erhalten bzw. wird der Inhalt des TurboWrite dann auch so gut verteilt ins normale TLC geschrieben, dass ein schnelles Lesen möglich ist.

 

[klampf]

Es gibt auch einen Thread zum Thema bei overclockers.co.uk.

Da hat einer das Problem auf einer 3 Tage alten Evo:
http://forums.overclockers.co.uk/showpost.php?p=26754385&postcount=66

Das wird also gleich mitgeliefert

 

[Holt]

Moment mal, wenn man die Lesegeschwindigkeit mit dem Filebench ermittelt ist das ok, aber mit Low-Level Benchmarks wie HD Tune oder HDTach geht das nicht, was ich auch gleich am Anfang in #20 schon ausgeführt hatte. Also bitte sachlich bleiben, mit dem passenden Benchmark testen und Ergebnisse unpassender Benchmarks besser ignorieren! Auch wenn er geklont hat, man weiß nie genau, wie das Kloneprogramm da genau gearbeitet hat, da gibt es auch Unterschiede und unterschiedliche Einstellungen innerhalb der Programme.

 

[Hallo32]

@Holt

HD Tach mit 8/32MB Blöcken geht iO.
Die Blöcke sind groß genug um bei der Evo ein seq. lesen zu triggern.

 

[Blublah]

HD Tach mit 8/32MB Blöcken geht iO.
Die Blöcke sind groß genug um bei der Evo ein seq. lesen zu triggern.

Also bei mir passt das Ergebnis von HD Tach definitiv nicht so ganz zu der Praxis. HD Tach gibt eine durchschn. Lesegeschwindigkeit von 280MB/s an. Wenn ich dagegen die Dateien umkopiere auf eine andere SSD oder mit FileBench teste dann krieg ich Werte gut über 400MB/s.

HD Tune und HD Tach sollte man also bzgl. der Lesegeschwindigkeit mit Vorsicht geniessen. Ich hab auch schon Ergebnisse von HD Tune gesehen die recht gut mit denen von FileBench übereinstimmen. Aber inwiefern das eher Zufall ist oder nicht lässt sich schlecht beurteilen.

 

[Holt]

Trotzdem bleiben Low-Level Benchmark ungeeignet, wenn Du einmal nicht weißt was im Hintergrund für Zugriffe auf das Laufwerk passieren und zum anderen nicht weißt ob der Bereich auch so sequentiell beschrieben wurde, wie es gelesen wird. Es gibt auch Klone Programme die nur die belegten LBAs kopieren.

 

[Hallo32]

Also bei mir passt das Ergebnis von HD Tach definitiv nicht so ganz zu der Praxis. HD Tach gibt eine durchschn. Lesegeschwindigkeit von 280MB/s an.

Mir geht es bei HD Tach nicht um absolute Werte, sondern um zu sehen ob die EVO extrem einbricht oder die Leistung konstant liefert.

Ergänzung (11. September 2014)

Trotzdem bleiben Low-Level Benchmark ungeeignet, wenn Du einmal nicht weißt was im Hintergrund für Zugriffe auf das Laufwerk passieren ....

Ist bei allen anderen closed Source Benchmarks nichts anders. Keiner kennt die Implementierungen der Zugriffe. Bei Benchmarks geht es um die Reproduzierbarkeit der Werte.

... und zum anderen nicht weißt ob der Bereich auch so sequentiell beschrieben wurde, ...

Wo ist das wichtig? Problematisch wird es nur, wenn der Lookup eines unbelegten LBAs deutlich schneller erfolgt als für einen belegten.

... wie es gelesen wird. Es gibt auch Klone Programme die nur die belegten LBAs kopieren.

Ist vom Ansatz ja auch gut.

 

[Holt]

Hallo32, die hast die Problematik der Verteilung von Daten über die NANDs Kanäle und wie das mit den Schreib- und Lesezugriffen zusammen hängt, die ja eine Länge von einem LBA bis maximal 2^16 LBA pro Befehl haben, noch überhaupt nicht verstanden.

 

[Hallo32]

@Holt

Wie sieht die Praxis aus? Wie sind die Zugriffe im täglichen Einsatz verteilt?

Deine 2^16 (65.536) LBAs sind zwar schön aber wie oft kommen solche Zugriffe vor?
Mein letzter Stand ist, dass die meisten Zugriffe eine Größe von 4KB haben und dieses sind 2^3 (8) LBAs bzw. 0,01% von 2^16.
Aufgrund der Größe, die kleiner als/gleich einer Page ist, lassen sich diese auch nicht parallelisieren.

Dieses ist eines der größten Probleme der SSDs.


Quelle:http://www.thessdreview.com/our-rev...-ssd-enthusiasts-report/3/?PageSpeed=noscript

 

[Holt]

Ob die meisten Zugriffe nur 4k haben, dürfte von der Verwendung der SSD abhängen und die 2^16 LBAs unterstützt auch nicht jedes Laufwerk, die geben in den IDENTIFY DEVICE Data auch an, wie viele LBAs sie pro Befehl maximal unterstützen.

Das die 4k Lesend sehr wichtig sind und dort die Fortschritte am schwersten zu realisieren aber im Alltag für Heimanwender auch am spürbarsten sind, ist klar.

 

[sheng]

Kann jemand bestätigen, dass das Problem auch bei der vorherigen Firmware-Version besteht?

 

[juenger]

Das ist ja nur ein Durchschnittswert und wenn Du 80% der Kapazität anfangs beschreibst, dann wird ja noch nichts gelöscht, nur im TurboWrite Puffer, aber dessen Zyklen scheinen da nicht mit erfasst zu sein, was auch sinnvoll ist.

Dann lässt Du 10% frei und kannst die übrigen 10% schon 10x beschreiben, bevor Du im Schnitt den ersten P/E Zyklus erreicht hast, die Zellen in denen nicht diese 80% künftig alter Daten liegen, haben dann aber so zwischen 5 und 10 Zyklen hinter sich, die anderen einen halb, die ja erst das P (Programm) und noch nicht das E (Erease) vom P/E Zyklus erfolgt ist.

Sorry wenn ich da nochmal nachfrage, aber da ich weder verstanden habe wie Wear Leveling funktioniert und auch kaum eine Ahnung von Overprovisioning habe, verstehe ich nicht was das bringen soll 10% freizulassen und dann 10% zu belegen und wiederholt zu beschreiben um die P/E hochzutreiben ?

Werden die freigelassenen 10% nicht intern auf FTL Ebene einfach als OP Space verwendet und bei den folgenden Schreibvorgängen inklusive der internen OP Area (also den rund 7% Umrechnungsfaktor von MiB in MB) mitverwendet?