News Samsung 840 Evo SSD zeigt erneut sinkende Leistung

[domidragon]

Danke für die Info. Sehr informativ!
Jetzt hast du mein Vertrauen in HD Tune zerstört

Nun, wenn ich mit diesem Tool teste, erreiche ich durchschnittlich 309mb/s.

Aber wieso ist das System dann so extreme langsam? Es dauert ohne witz teilweise 10 sekunden, bis der explorer offen ist! (in der VM, siehe unten, teilweise aber auch auf dem lokalen System)

Systeminfo:
Es sind 2 SSDs im Laptop verbaut.
Die Samsung 840er ist eine 1tb SSD, die nutzen wir für unsere VMs. (Die andere ist ebenfalls eine Samsung, aber mit 256gb und hat nen komischen Namen^^)
Bis vor ein paar Wochen konnte ich ohne Probleme 3 VMs gleichzeitig laufen lassen und damit arbeiten.
Seit dieser Zeit läuft alles enorm langsam. Ich habe mittlerweile ein Systemmonitoring Tool an, um die Werte zu sehen. Da kriegt die SSD auch selten mehr als 6mb/s raus, wenn ich was in der VM mache.
Beim Test zeigt es mir dann aber ebenfalls über 300mb/s an, also mit dem Tool oben.

Ich lasse über die Nacht mal die gesamte SSD benchen, dann sehe ich vlt. mehr.

Wenn das nichts ergibt, muss es softwareseitig sein, bzw. irgend ein Problem mit den VMs -.-

 

[Holt]

HD Tune ist optimal für HDDs, aber eben nicht geeignet um damit SSDs zu benchen, die funktionieren intern eben total anderes und wenn man damit keine sinnvollen Ergebnisse produzieren. Obendrein liest HD Tune in der Standardeinstellung nicht die ganze Kapazität, wo wie man es meinen könnte wenn man den Screen sieht, sondern nur ab und an 64kB, was aber nicht reicht um bei aktuellen HDDs an ihr Limit zu kommen, denn es wird ja auch mit QD 1 und nicht wie bei ATTO mit 4 Overlapping I/O gebencht, da brauchen selbst einige SATA SSDs schon 512 Byte lange Zugriffe um die volle Performance zu erzielen, PCIe SSDs meist noch viel längere.

Das Hauptproblem ist aber die Anordnung der Daten die eben nicht auf die LBAs bezogen passiert wie es bei HDDs der Fall ist und wie Low-Level Benchmarks wie auslesen. Wenn ein LBA gar nicht mit gültigen Daten beschrieben ist, dann braucht der Controller auch keine Daten aus den NANDs auszulesen, welches sollte er auch lesen? Er liefert dann gewöhnlich nur Nullen zurück und das eben sehr schnell, wie beidiesem alten Review einer Intel X25-V bei awardfabrik.de:

bzw.

Die getestete SSD kann gar keine 200MB/s oder gar mehr lesen, die Kurven zeigen nur da die reale Geschwindigkeit halbwegs richtig an, wo der Speicher auch wirklich belegt ist. Wie man sieht wurden zwischen den Benchmarks noch mal 4GB auf der SSD belegt und so richtig gleichmäßig sind die Leseraten auch nicht, es gibt auch einen kräftigen Einbruch. So schnell kann die lesen, wenn man auch wirklich Daten zum Lesen hineingeschrieben hat:

Dabei haben sie den Effekt des Schattenfilesystems noch nicht zu sehen, denn der tritt eben erst mit der Nutzung auf und die Reviewer packen ja meist ein Image auf die SSDs und schrieben ein paar Testdaten, die werden damit also vor allem sequentielle beschrieben, genau wie es dann bei den Low-Level Benchmarks zu gleichmäßige Leseraten führt, werden die wirklich fileweise mit vielen kleinen Dateien beschrieben und dann auch immer wieder mal neue Dateien geschrieben oder alte überschrieben und die Metadaten des Filesystems ändern sich laufend, dann hat man schnell überall die Einbrüche bei den Low-Level Benchmarks, was aber eben normal ist und kein Hinweis auf einen Bug.

Ergänzung (22. März 2016)

behardware hatte dazu im Rahmen eines Tests auch mal geschrieben (die englische Seite ist nicht mehr am Netz, ich verlinke daher auf das französische Original):

Between the compressible and incompressible readings then, there’s a big difference both between reads and writes on some SSDs. Let’s see what happens on some SSDs when we read the data. There are three distinct zones on these screenshots:

- A corresponds to the system image previously described
- B corresponds to a very compressible 4 GB file then an incompressible 4 GB file created via IOMeter
- C corresponds to the unused area of the SSD



On the unused part of the Corsair Force 3, a SandForce SSD with asynchronous memory, we’re at the theoretical maximum of close to 510 MB/s. But in practice on the partition with data we’re far below this at just 272.5 MB/s on average, with a minimum of 187 MB/s and a maximum of 509 MB/s, which corresponds among other things to the zone occupied by pagefile.sys. On the compressible test file we’re at around 425 MB/s and 190 MB/s on the incompressible one.

Da sieht man auch schön wie bei Sandforce sogar die Datenkompression die Ergebnisse weiter verändert.

Wieso die Entwickler von HD Tune es nicht bei der Angabe "Hard Disk Utilities" im Titel des Screens belassen haben, ist mir wirklich unverständlich, aber man kann ja nun auch filebasierte Tests damit machen, was eben bei SSDs Pflicht ist, nur kann man damit keine Verlangsamung der Leseleistung alter Daten ermitteln, weil diese Benchmarks dann alle die Dateien schreiben und sofort wieder lesen, die Testdaten werden also nie alt. Daher muss man eben Tools wie Filebench nehmen, die wirklich die Leserate vorhandener Dateien durch das dateiweise Lesen ermitteln. Da kann zwar mal ein andere Zugriffe dazwischenfunken und für schlechte Werte sorgen, was ja auch bei HD Tune zu einem Zacken nach unten führt. Oder der Virenfinder schaut man länger auf eine Datei, weshalb man die Mindestgröße etwas höher als 1MB stellen sollte, aber über eine ausreichende Menge an Dateien gleich sich das aus und die Darstellung ist ja auch so, dass die Größe der Kreise einen Hinweis auf gelesenen Datenvolumen gibt.

 

[sini]

Waaas die Werte entsprechen nicht der Realität? Niemals! Nachher behauptest du noch die Herstellerangaben von Verbrauchswerten für KFZs und Elektrogeräte sind utopische Angaben

 

[Holt]

Welche Ergebnisse man bekommt, hängt halt immer davon ab wie man testet, bei Autos wie bei SSDs. Nur gibt es eben sinnvollere und sinnlose Tests, hier wie da.

 

[domidragon]

Danke für die Ausführungen! Hab sowas noch niergends gelesen -.- Aber man lernt ja nie aus.

Hier ein Screenshot mit FileBench:



Gewisse Tendenz bei den älteren VMs sieht man schon.

Frage: Spielt beim Alter der Datei, bei welcher diese SSD einbricht das Datum der Datei eine Rolle oder wie lange diese schon auf der SSD liegt?

 

[klampf]

Also ich habe verstanden, dass man HD Tune ganz wunderbar zum Testen verwenden kann.
Man muss nur die Ergebnisse verstehen

@domidragon
wie lange die schon drauf liegen bzw. genauer wann die das letzte mal neu geschrieben wurden.

 

[Holt]

VM Images sind für den Test ganz unglücklich, denn:
1.) Das Datum der Dateien des VM Images dürfte nur das von Anlegen der VM zu sein, die Daten drain dürfte damit neuer sein, wenn die VM auf ihre "Platte" schreibt und damit innerhalb der Imagedatei, aber das Datum der Datei selbst nicht aktualisiert wird. Bei VM Ware ist es meine ich so, zumindest sieht es bei meinen VMs so aus. Wenn wurden den die VMs jeweils zuletzt benutzt? Oder sind das alles Dateien einer einzigen VM?

2.) Da die VM ja auf die Datei wie auf ihre Disk schreibt, hat man den gleichen negativen Effekt des Schattenfilesystems wie bei einem Low-Level Benchmark, weil man die Daten wieder nicht in dem Zusammenhang liest wie sie wirklich in die NANDs geschrieben wurden, denn die werden nicht so am Stück geschrieben wie sie als Image auf der SSD stehen, sondern wie die Dateien auf der virteullen Platte innerhalb der VM stehen. Die VM schreibt und überschreibt dann immer wieder etwas was nur einem Stückchen der Imagedatei entspricht und damit passen die internen Datenstrukturen im NAND wieder nicht zu den Image Dateien der virtuellen Disks. Im Grunde müsste man da Filebench innerhalb der VM laufen lassen um wirklich wieder die Daten dateiweise so zu lesen, wie sie auch geschrieben wurden. Nur bremst die VM natürlich selbst beim Lesen auch wieder, aber nur so wäre dann so wie es bei einer normalen SSD wäre. Probiere das mal, vor allem bei der VM mit den ältesten Dateien von 08/2014 und dann bei der neuesten Dateien die wirklich schnell gelesen werden konnten.

3.) Wenn VM Ware die Dateien in Spare anlegt, also so das sie bei Bedarf wachsen, dann können sie sehr stark fragmentieren und das bremst die Lesegeschwindigkeit ebenfalls, weil es ja wie viele Zugriffe auf kleine Daten wird, da ja jedes Fragment einer Datei einzeln gelesen werden muss und damit keine Zugriffe möglich sind die länger als das Fragment selbst sind. Mit Contig von sysinternals kann man contig -a Dateiname die Fragmentierung analysieren lassen, bei starker Fragmentierung sind dann auch schlechtere Leseraten normal. Das wurde im Filebench Programm leider nicht berücksichtigt.

Aber trotzdem könnte das Ergebnis zeigen, dass es auch betroffene 840er gibt, aber nicht wie bei der 840 Evo wo der Effekt nach Wochen eintrat, sondern erst nach Monaten bis Jahren. Hat denn keiner hier eine 840er die ganz normal als Systemlaufwerk seit Jahren ohne Neuinstallation, Defragmentierung, Refresh, Image zurückspielen etc. gelaufen ist? Das wäre ein optimaler Kandidat für den Test.