840 evo 1 TB ist lahm auf "alten" Daten

[klampf]

Anscheinend ist es schon anderen aufgefallen. Siehe z.B. hier:
http://www.overclock.net/t/1507897/samsung-840-evo-read-speed-drops-on-old-written-data-in-the-drive

Auch meine Samsung 840 evo 1 TB zeigt das dort gezeigte Verhalten.
Mache ich einen Read mit HD Tune (so eingestellt, dass wirklich alles gelesen wird) geht die Leserate teilweise auf 65 MB/s runter.

Um zu checken, ob das evtl. nur leere Bereiche sind oder so, habe ich jetzt noch direkt Files gelesen, die schon auf der SSD drauf sind.
Genutzt dafür:
http://thesz.diecru.eu/content/parkdale.php

Das Tool macht genau das was man so will und man kann auch mit und ohne Pufferung lesen u.a..
Einfach ein File anwählen Read drücken und warten.
Hier zeigt es sich, dass z.B. eine 70 GB großes VirtualBox-Image mit 420 MB/s gelesen wird. Das scheint mir okay.

Ein paar älteren Dateien in der Größe von 2 GB werden allerdings nur mit 80 MB/s gelesen.
Das sind Dateien, die ich praktisch als allererstes auf die SSD kopiert habe (von einer Platte, die ersetzt wurde).
Die haben eine Größe von 2 GB je Datei. Ich überlege gerade, ob ich die mir einem Imagingtool eingespielt habe. Weiß es leider nicht mehr genau.

Insofern zeigt das Lesen von Dateien das gleiche Verhalten wie das blockweise Lesen der gesamten SSD. Es liegt also nicht an der Testmethode.
CrystalDiskInfo mal unten, das zeigt keine Auffälligkeiten. Die SSD ist fast neu und eher wenig benutzt.
Es ist auch nicht die Bootplatte und es lief keine Software von der SSD.
Kein aktiver on-access virenscanner.

Ich habe noch 2 Crucial SSDs drin (C300, M4) die zeigen das Verhalten nicht.

Ist das jetzt ein Defekt oder die Performance, die man erwarten darf?

Wenn es wirklich "normales Verhalten" ist, dann sag ich schönen Dank und sehr schade, dass die M550 noch nicht draußen war, als ich die Samsung gekauft habe.

Und jetzt spiele ich mir den Gedanken die SSD mal defragmentieren zu lassen ...

 

[Killerphil51]

Die SSD zu defragmentieren ist absoluter blödsinn.

 

[computerbase107]

Ich würde die SSD mit dem Samsung Testprogramm (Magician) prüfen von der beigelegten CD.

Eventuell gibt es ja eine neue Firmware, die sich damit auch aufspielen läßt.

Hier noch der Link zur Downloadseite von Samsung: http://www.samsung.com/global/business/semiconductor/minisite/SSD/de/html/support/downloads.html

 

[Blublah]

Hallo, was für einen Mobo-Chipsatz hast du denn? Jemand auf amazon.com meinte dass das Problem mit AMD Systemen zusammenhängen könnte (obwohl er dafür kaum gute Anhaltspunkte gebracht hatte, ausser dass er selbst ein AMD System hatte).

Ich werde mal versuchen das Problem irgendwie bei mir zu Hause nachzustellen, obwohl ich meine 1TB EVO erst seit ein paar Tagen habe. Bisher konnte ich beim Kopieren von Grossen Dateien keinerlei Probleme feststellen aber die SSD ist noch sehr neu. Falls es wirklich ein Problem mit der 840er EVO gibt dann würde ich das gerne vor den 30 Tagen Amazon Rückgabefrist rausfinden. Die FW ist die neueste. Magician habe ich mal installiert und angeworfen aber dann gleich aus dem Autostart rausgenommen (befindet sich neben der Autostart Gruppe auch als Task im Task Scheduler was ziemlich frech und nervig ist). Optimieren hab ich Magician nix gelassen. Ansonsten hab ich ein Z87 System und verwendete Intel IRST Treiber.

Ich hab noch diverse andere SSDs (Samsung 830 256GB, OCZ Max IO 240GB, OCZ Vertex 120GB,...) bei denen ich bisher kein vergleichbares (oder anderes Problem) hatte. Die mind 1 Jahre alten grossen Dateien der 830er wurden nahe 500MB/s auf die EVO kopiert.

Jemand auf Geizhals hat übrigens das gleiche Problem:
http://geizhals.at/de/?sr=977944,810630#7298136

 

[supastar]

Dürfte normal sein:
https://www.computerbase.de/2013-09/samsung-ssd-840-evo-test/2/

http://geizhals.at/de/?sr=977944,810630#7298136
http://geizhals.at/de/?sr=977944,810072#7292780

 

[klampf]

Die SSD zu defragmentieren ist absoluter blödsinn.

Tja, bewegt aber mal alle Daten, auch die "alten".

(Magician)

Die Software habe ich drauf. Firmware ist aktuell. Der Magician findet die SSD "Good".
Einen richtigen Test hat die SW aber nicht, oder?
Der kleine integrierte Benchmark zeigt auch 551 MB/s read, 532 MB/s wirite und 96595 r, 88512 w IOPS ... also alles supi so gesehen.

 

[BadBigBen]

Könnte das auch mal testen, aber erst wenn ich wieder zuhause bin. Habe da ein Intel Board z68 und ne 500 EVO, die ca. ein Jahr alt ist...

Tja, bewegt aber mal alle Daten, auch die "alten".

auf einer HDD ist dies zustimmend, zum teil... auf einer SSD aber nicht, denn da spielt der Controller auf der SSD nicht mit...

Siehe hierzu:

Fragging wonderful: The truth about defragging your SSD
http://www.pcworld.com/article/2047513/fragging-wonderful-the-truth-about-defragging-your-ssd.html

 

[MidwayCV41]

Hallo, was für einen Mobo-Chipsatz hast du denn? Jemand auf amazon.com meinte dass das Problem mit AMD Systemen zusammenhängen könnte (obwohl er dafür kaum gute Anhaltspunkte gebracht hatte, ausser dass er selbst ein AMD System hatte).

Kann hinkommen. Hatte mit meinen 2 Samsung 830er an einen AMD Chipsatz auch nur Probleme. Schlechter Performence und immer wieder Freezer. An einem Intel Chipsatz laufen beide ohne Probleme.

 

[klampf]

Sorry Systeminfo dazu:
Asus Max. hero IV m. Z87, Intel-Treiber, 4770K@4,2 GHz, 32 GB DDR-1600, ATI 7870

Danke für die Links auf andere "Problemkinder".

Der Test auf CB zeigt doch aber eher einen moderates Nachlassen der Geschwindigkeit.

 

[Blublah]

Dürfte normal sein:
https://www.computerbase.de/2013-09/samsung-ssd-840-evo-test/2/

Nein, das ist der 'normale' geringe Leistungsabfall wenn die SSD fast voll ist. Hier geht es darum dass die SSD alte Dateien (auch sehr grosse mit mehreren GB) nur noch mit 10%-20% der ursprünglichen Rate liest.

Ach ja, defragmentieren macht für SSDs keinen Sinn.

 

[klampf]

Könnte das auch mal testen

[...]
Fragging wonderful: The truth about defragging your SSD

Wäre spannend, wenn Du und andere das mal testen.

Zum Defragmentieren habe ich eigene Theorien
Auch von einer SSD kommen Daten schneller, wenn sie in größeren Blöcken gelesen werden können und weniger Zugriffe notwendig sind. Das mag evtl. nicht messbar sein, aber das macht es ja nicht falsch. Höchstens unnötig.

Der verlinkte "Test" probiert nur aus, ob eine Optimierung den Benchmark-Speed wieder auf das Niveau nach einem Secure Erase bringt.
Macht es natürlich nicht. Warum auch sollte es auch.

Egal, die Optimierung läuft mal und wenn es nur als ein Belastungstest der SSD ist.

 

[Hallo32]

Lasse dir von Windows doch einmal anzeigen wie fragmentiert deine SSD ist.

 

[BlubbsDE]

Deine Gedanken zur Defragmentierung gelten aber nur für eine HDD. Dort werde die Daten in Blöcken und das auch für Dich als User sichtbar abgelegt. Bei einer SSD geschieht das anders und Du oder das Defrag Tool hat keinerlei Einfluss, wo die Daten abgelegt werden. Somit ist das Defragmentieren total sinnlos. Die Daten hin und her kopieren würde reichen.

Und HD Tune eignet sich mal so gar nicht für eine SSD. Weil es eben auch auf die Blockweise Speicherung einer HDD aufsetzt.

 

[Blaze1987]

Sind deine CPU C-States aktiviert? Falls ja mal alle deaktivieren... (Performanceschub)
Welche Dateien sind die 2 GB Dateien genau? Komprimierte Dateien?
Wenn die Dateien älter sind und du diese schon länger nicht mehr genutzt hast, haben die ne geringerer Priorität für die SSD (Controllerfirmware) und daher für den Zugriff auch nicht optimiert.

Auch die 18x hard reboots könnten da mitspielen...?

http://www.samsung.com/global/business/semiconductor/minisite/SSD/us/html/about/whitepaper07.html

ID # 235 Power Recovery Count

A count of the number of sudden power off cases. If there is a sudden power off, the firmware must recover all of the mapping and user data during the next power on. This is a count of the number of times this has happened.

 

[Blublah]

Auch die 18x hard reboots könnten da mitspielen...?

http://www.samsung.com/global/business/semiconductor/minisite/SSD/us/html/about/whitepaper07.html

Interessant. Evtl. geht bei der Wiederherstellung der Mapping Informationen ("the firmware must recover all of the mapping and user data during the next power on") nach einem plötzlichen Stromverlust die Optimierung für sequentielle Dateien verloren und entsprechend sinkt die Lesegeschwindigkeit im schlimmsten Fall runter auf das Niveau von zufälligen Zugriffen (etwa 30MB/s).

Denn sequentielles Lesen ist bei einer SSD ja keine so eindeutige physikalische Eigenschft wie bei einer HD sonder hat viel mit der internen Datenorganisation zu tun.


Mal sehen was hier noch die Besitzer älterer EVOs berichten. Die Dateien zum testen sollten möglichst gross sein, damit wirklich getestet wird ob das sequenzielle Lesen betroffen ist. Viele sehr kleine Dateien werden ja im schlimmsten Fall ja eh nur mit 30MB/s gelesen.

Sind deine CPU C-States aktiviert? Falls ja mal alle deaktivieren... (Performanceschub)

Das betrifft eigentlich eher zufällige Zugriffe auf kleine Blöcke.

 

[klampf]

Die Daten hin und her kopieren würde reichen.

Was anderes macht ja ein Defrag nicht, nur, dass ich nicht händisch dran muss.

Und HD Tune eignet sich mal so gar nicht für eine SSD. Weil es eben auch auf die Blockweise Speicherung einer HDD aufsetzt.

Der Betrachtung kann ich mich nicht anschließen, denn alle anderen SSDs, CF-Karten, USB-Sticks usw. kann man so testen und die zeigen auch kein seltsames Verhalten.
Ist doch eins der Plus-Argumente einer SSD. Überall gleich schnell.

Daher finde ich den Test legitim und erwarte auch, dass es schnell ist. Spätestens wenn man ein Image von der SSD machen will, ist genau das auch ein normaler Nutzfall.

Sind deine CPU C-States aktiviert? Falls ja mal alle deaktivieren... (Performanceschub)
Welche Dateien sind die 2 GB Dateien genau? Komprimierte Dateien?

Es waren komprimierte und unkomprimierrte Daten dabei.
Da die 840 evo aber nicht komprimiert, sollte das keine Rolle spielen, oder?
C-States sind aktiv (evtl. nicht C6/7, steht auf Auto), Dynamic Storage Accelerator ist aber auch aktiv und naja, es hängt halt von den Files ab, welche gelesen werden.

Wenn die Dateien älter sind und du diese schon länger nicht mehr genutzt hast, haben die ne geringerer Priorität für die SSD (Controllerfirmware) und daher für den Zugriff auch nicht optimiert.

Gut, wenn Samsung jetzt offiziell sagt:
Daten, die 3 Monate alt sind, optimieren wir ihnen auf halben Festplattenspeed runter, wäre das auch eine Aussage.

Auch die 18x hard reboots könnten da mitspielen...?

Interessant. Evtl. geht bei der Wiederherstellung der Mapping Informationen ("the firmware must recover all of the mapping and user data during the next power on") nach einem plötzlichen Stromverlust die Optimierung für sequentielle Dateien verloren und entsprechend

Hm, tja, wenn das so ein Problem ist, wäre das immerhin eine Aussage.
Macht die SSD für mich auch zu einem Problemkind, denn die beiden anderen haben damit kein erkennbares Problem.

 

[Blaze1987]

Gut, wenn Samsung jetzt offiziell sagt:
Daten, die 3 Monate alt sind, optimieren wir ihnen auf halben Festplattenspeed runter, wäre das auch eine Aussage.





Hm, tja, wenn das so ein Problem ist, wäre das immerhin eine Aussage.
Macht die SSD für mich auch zu einem Problemkind, denn die beiden anderen haben damit kein erkennbares Problem.

Niemand weiß welche Algorithmen Samsung nutzt für deren TRIM Befehlen und anderen Mechanismen...

Alles unter Vorbehalt und ohne fundierte Kenntnisse meinerseits.

 

[BadBigBen]

Was anderes macht ja ein Defrag nicht, nur, dass ich nicht händisch dran muss.

Nö... Defrag versucht dies zu machen, aber der Controller, der ja weis wo unbenutze oder freie blöcke sind, schiebt diese dann natürlich dorthin wo ER sie haben will, und nicht wo das DEFRAG Programm es gerne hätte... und belässt unter Umständen die Daten genau da wo sie waren...

So, jetzt zu meiner Tests:

Kopieren von der 840 Evo 500GB auf eine HDD, 16GB VDX Datei (Windows XP Pro, die ich seit Anfang 2013 nicht mehr nutzte), wurde mit ca. 110 MB/s gemacht (Samsung 750er HDD, die schnellste im PC)...
auf eine Samsung 830 64GB, betrug der DatenTransfer 133MB/s im Durchschnitt, laut ASBenchmark (was ich danach machte) rennt die Kleine nur mit 160MB/s im Seq. Write...

Fazit: Kann das Phänomen hiermit nicht bestätigen.

So nun zur HDTach... Startete nicht auf Windows7 64bit, egal welchen Kompatibilitäts Modus ich einstellte...

 

[Hallo32]

So nun zur HDTach... Startete nicht auf Windows7 64bit, egal welchen Kompatibilitäts Modus ich einstellte...

Versoin 3.0.4.0 startet bei mir im Windows XP SP3 Kompatibilitätsmodus und mit Admin Rechten.

 

[Holt]

HD Tune und HD Tach sind "Hard Disk Utilities" wie auch im Titel des HD Tune Screens steht und nicht wirklich für SSDs geeignet, weil HDDs LBAs fest auf Kopf, Zylinder und Sektor umrechnen und diese dann einfach auslesen, SSDs aber mappen die LBAs auf immer wieder wechselnde Speicherbereiche. Da kann nichts ausgelesen werden, wenn eine LBA noch nie beschrieben oder getrimmt wurde und damit nicht gemappt ist, der Controller liefert dann einfach irgendwas zurück. Obendrein wird mit der Standardeinstellung immer nur alle paar MB mit 64k Zugriffen gemessen, aber 64k sind zu wenig für eine SSD um die maximalen seq. Leseraten auch nur annähernd zu erreichen. Außerdem führen SSDs ein Schattenfilesystem und verteilt die Daten entsprechend so zusammenhängend, wie sie geschrieben wurden. Bei einem Low-Level Benchmarks funktioniert das nicht, weil da die LBAs eben direkt und damit zusammenhanglos gelesen werden.

Die SSD ist also nicht lahm bei alten Daten und es ist auch kein Problem der Evo, es liegt schlicht am ungeeigneten Benchmark. Suche Dir eine größere alte Datei und kopiere diese z.B. unter einem Linux mit dd nach /dev/null mit einem bs=4m und Du siehst, wie schnell die wirklich gelesen werden kann. Hast Du kein Linux schrieben ein paar GB mit h2testw auf die SSD, lass die h2w Dateien drauf und prüfen die ab und an erneut. Auch wenn h2testw kein echter Benchmark ist, so solltest Du doch Geschwindigkeitseinbrüche merken.

Vorsicht aber wenn es Deine Systemplatte ist, dann Zugriffe von Windows oder anderen Programme bremsen natürlich jeden Benchmark und Windows macht laufend Zugriffe auf seine Systemdateien, wie Du im Resourcen Monitor ja leicht selbst sehen kannst. Das erzeugt bei den Benchmarks wie HD Tune und HD Tach dann auch entsprechende Einbrüche der Kurven, man kann damit also eigentlich nur Datenlaufwerke benchen, nie solche wo Windows darauf läuft. Beispiele dafür finden sich reichlich im Festplattenforum.