Samsung 840 rapider Verlust an Schreibgeschwindigkeit

[moniduse]

Ich habe festgestellt, dass die Schreibgeschwindigkeit meiner Samsung 840 250 GB stark gesunken ist. Woran kann das plötzlich liegen?

Weiß jetzt nicht, wann ich die Treiber mal aktualisiert habe, aber sollte ich vielleicht mal neu installieren? System das erste siehe Signatur.

 

[Hanne]

Samsung Magician

ist installiert - hier wird Auskunft über die SSD erteilt -

Im BIOS ist SATA-Mode = AHCI eingestellt und WIN wurde auch damit installiert ?

 

[Holt]

1.) Poste bitte mal den Screen von CrystalDiskInfo, ziehe aber bitte das Fenster soweit auf, dass alle Attribute und auch die Hex-Werte bzw. Rohwerte vollständig sichtbar sind.

2.) Wie voll ist die SSD?

3.) Prüfe mal wie wie stark deren Filesystem fragmentiert ist, den dadurch werden statt langer schneller Zugriffe viele kleine, kurze Zugriffe nötig.

4.) Prüfe mal mit TrimCheck ob TRIM wirklich funktioniert. Das sollte eigentlich der Fall sein, aber nebenbei sieht Du schon beim ersten Start des Programms auch, wie sehr dessen kleines Testfile fragmentiert wird, denn das zeigt es an.

5.) Benche mal im abgesicherten Modus von Windows um Einflüsse anderes Programme möglichst zu vermeiden. Virenfinder, vor allem die mit dem G am Anfang, bremsen SSD auch gerne mal.

 

[moniduse]

Programm ist installiert, damit habe ich auch getestet wie im 2. Screenshot zu sehen. Da wird alles als OK angezeigt. Win8 wurde mit AHCI installiert. Wie man sieht, hatte die SSD auch mal die volle Geschwindigkeit erreicht. Allerdings war der Speicherplatz in letzter Zeit immer ziemlich belegt, bis unter 1 GB. Habe mal 14 GB Platz geschafft, aber wirklich was gebracht hats auch nicht.

 

[Holt]

Wenn die so voll war und nun hier und da ein paar Dateien gelöscht wurden, dürfte das Filesystem stark fragmentiert sein und nur überall verteilt ein paar kleine Lücken haben, über die sich die Testdatei des Benchmarks verteilen muss. Das ergibt viele kurze Zugriffe und die sind sehr viel langsamer als die langen sequentiellen, wie der Vergleich von 4k und sequentiell auch zeigt. Schon deshalb und weil der Controller die Daten bei einer so vollen SSD auch nicht mehr so optimal über die NANDs verteilen kann, sollten immer mindestens 10% frei bleiben, besser 15!

 

[moniduse]

TrimCheck sagt beim 2. Aufruf:

TRIM check v0.6 - Written by Vladimir Panteleev
https://github.com/CyberShadow/trimcheck

Loading continuation data from C:\AMD\trimcheck-cont.json...
Drive path : \\.\C:
Offset : 48660979712
Random data : 93 FF 39 80 3D FA 80 7A 2E 1A EE EB 4E E2 65 59...

Reading raw volume data...
Opening \\.\C:...
Seeking to position 48660979712...
Reading 16384 bytes...
First 16 bytes: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00...
Data is empty (filled with 0x00 bytes).

CONCLUSION: TRIM appears to be WORKING!

Press Enter to exit...

CrystalDisk



Fragmentierung 28,73%

Antivirus habe ich nur den integrierten Windows Defender.


Ich hatte vorhin eine ganz neue Crucial M500 120GB angeschlossen und die war seltsamerweise auch sehr lahm. Allerdings hatte ich sie in einer Dockingstation per eSATA, womöglich war das das Problem.



Achso, Treiber ist dieser:

 

[Radde]

@moniduse
es kann sehr gut sein, dass ein zu geringer freier Speicherplatz das Problem ist/war. 1GB ist für eine SSD zu wenig, damit die internen Verwaltungsvorgänge ordentlich funktionieren.
Wenn du jetzt 15 GB frei hast, dann lass den Rechner mal ein paar Stunden im Leerlauf laufen, damit sich die SSD wieder selbst organisieren kann. Damit ist es möglicherweise schon getan.

Edit:
@Holt
Fragmentierung ist bei einer SSD aber dsoch völlig egal (zumindest beim Lesen). Fragmentieren bringt bei einer SSD überhaupt nichts und schadet ihr sogar!
Beim Schreiben braucht die SSD natürlich komplett freie Speicherzellen, weil sie eine halbvolle Zelle erst lesen, dann komplett auffüllen und anschließend speichern muss. Dafür muss man dem Controller aber "Platz zum Atmen" lassen. Und genau hier sehe ich das Problem im vorliegenden Fall.

 

[Holt]

TrimCheck sagt beim 2. Aufruf

Und was hat es beim ersten Lauf ausgegeben? Wie viele Fragmente hatte das kleine Testfile?

1GB ist für eine SSD zu wenig, damit die internen Verwaltungsvorgänge ordentlich funktionieren.

Das stimmt, aber dazu kommt eben der Effekt der kurzen Zugriffe, wenn das Filesystem stark fragmentiert ist. Das betrifft natürlich nur die später und vor allem die neu geschrieben Dateien, die am Anfang einmal dort abgelegte sind ja alle nur in einen Fragment geschrieben worden, sofern sie nicht größer geworden sind.

Es wird immer bezweifelt, dass die Fragmentierung auch bei SSD Einfluss auf die Performance nimmt, aber dabei wird immer das Filesystem vergessen, welche eben die den Adressraum organisiert und damit beim Lesen bzw. Schreiben einer Datei bestimmt, wo diese im Adressraum der Platte liegt. Bei HDDs führt diese Fragmentierung auch noch zu Kopfbewegungen, weil deren Adressen ja fix auf CHS umgerechnet werden. Das fällt bei SSDs weg, da veraltet der Controller selbst, wo die Daten im NAND liegen und versucht sie beim Scheiben möglichst optimal über die NANDs zu verteilen, was natürlich unmöglich ist, wenn ihm nur sehr wenig Platz zur Verfügung steht. Aber die Schreibvorgänge müssen lange genug sein, damit er erkennt, welche Daten zusammen gehören, es wird ja nicht Sektor für Sektor mit je einem Befehl geschrieben, sondern immer gleichen viele 100k bis MB am Stück mit einem Befehl. Es geht aber nicht mehr als die Länge des Fragmentes einer Datei mit einem Befehl zu schreiben, da das nächste Fragment dann wieder an einer anderen Stelle beginnt.

Fragmentierung ist bei einer SSD aber dsoch völlig egal (zumindest beim Lesen). Fragmentieren bringt bei einer SSD überhaupt nichts und schadet ihr sogar!

Eben nicht, das ist ein weit verbreiteter Irrglaube von Leute die keinerlei Ahnung von einem Filesystem haben und dieser daher konsequent ignorieren. Das Defragmentieren schadet einer SSD nicht, es kostet vielleicht einen oder auch ein paar P/E Zyklen, aber die NAND dieser SSD haben gerade erst 57 P/E Zyklen auf dem Buckel, 1000 werden garantiert und über 3000 wurden in allen Endurance Test erreicht.

Bei 57 Zyklen in etwa 11 Monaten reichen alleine die 1000 garantierten Zyklen noch für 180 Monate, also 15 Jahre. Da komt es auch einen Zyklus mehr oder weniger doch wirklich nicht an, oder? Zu oft sollte man das natürlich nicht machen, aber der Performanceverlust ist ja selbst bei dieser Extremen Fragmentierung noch eher gering und deshalb muss das auch nicht oft sein.

Beim Schreiben braucht die SSD natürlich komplett freie Speicherzellen, weil sie eine halbvolle Zelle erst lesen, dann komplett auffüllen und anschließend speichern muss.

Das ist ja richtig, aber das ändert nichts daran, dass eine fragmentierte Datei keine lange sequentiellen Zugriffe mehr erzeugen kann und kurze Zugriffe immer deutlich langsamer sind.

 

[Hanne]

Perfomance Optimatiom & OS-Optimation laufen lassen

Anschließen "Over-Provisioning"

 

[Holt]

Nein, blos nicht! Diese OS-Optimierungen sind der totaler Unsinn und kontraproduktiv. Das Problem ist hier klar die extreme Fragmentierung des Filesystems, welches nur noch kleine Lücken aufweist über die sich die Testdatei der Benchmarks verteilen muss. Mit "Over-Provisioning" wird das nur noch schlimmer, bzw. kann man das gar nicht mehr einrichten, weil selbst die höchsten LBA schon beschrieben sein dürften und Magician dabei nur die Partition verkleinert!

 

[moniduse]

Ich habe jetzt noch mal im abgesicherten Modus getestet und dort kommen wunderlich hohe Werte zustande:



Die erste Ausgabe von TrimCheck war:

TRIM check v0.6 - Written by Vladimir Panteleev
https://github.com/CyberShadow/trimcheck

USAGE: Place this program file on the same drive
you'd like to test TRIM on, and run it.

Press Enter to test drive C:...

Querying C:\ disk space and sector size information...
C:\ has 512 bytes per sector, and 8 sectors per cluster.
3775865 out of 60914431 sectors are free.
Generating random target data block (16384 bytes)...
First 16 bytes: 03 CD D8 1B 91 76 03 DE 92 1E 11 84 8A 20 8F BD...
Creating C:\AMD\trimcheck.bin...
Querying file final paths...
DOS : \\?\C:\AMD\trimcheck.bin
GUID : \\?\Volume{e70643a4-4925-4d84-879b-4ad96db782fa}\AMD\trimcheck.bin
NT : \Device\HarddiskVolume7\AMD\trimcheck.bin
NONE : \AMD\trimcheck.bin
Writing padding (33554432 bytes)...
Writing data (16384 bytes)...
Writing padding (33554432 bytes)...
Flushing file...
Checking file size...
Data is located at Virtual Cluster Numbers 8192-8195 within file.
Querying file physical location...
trimcheck.bin has 10 extents:
Extent 0: Virtual clusters 0-255 are located at LCN 19595540
Extent 1: Virtual clusters 256-767 are located at LCN 11809911
Extent 2: Virtual clusters 768-1811 are located at LCN 1792228
Extent 3: Virtual clusters 1812-3847 are located at LCN 46340097
Extent 4: Virtual clusters 3848-8314 are located at LCN 49025708
(this is the extent containing our data)
Extent 5: Virtual clusters 8315-10381 are located at LCN 12278266
Extent 6: Virtual clusters 10382-10543 are located at LCN 15756873
Extent 7: Virtual clusters 10544-14051 are located at LCN 10534004
Extent 8: Virtual clusters 14052-16340 are located at LCN 3484129
Extent 9: Virtual clusters 16341-17647 are located at LCN 1908202
Closing file.
Saving continuation data to C:\AMD\trimcheck-cont.json...
Flushing buffers on \\.\C:...
Opening \\.\C:...
Flushing buffers...
Deleting file...
Flushing buffers on \\.\C:...
Opening \\.\C:...
Flushing buffers...

Test file created and deleted, and continuation data saved.
Do what needs to be done to activate the SSD's TRIM functionality,
and run this program again.
Usually, you just need to wait a bit (around 20 seconds).
Sometimes, a reboot is necessary.

Press Enter to exit...

Und dann kommt:

TRIM check v0.6 - Written by Vladimir Panteleev
https://github.com/CyberShadow/trimcheck

Loading continuation data from C:\AMD\trimcheck-cont.json...
Drive path : \\.\C:
Offset : 200827092992
Random data : 03 CD D8 1B 91 76 03 DE 92 1E 11 84 8A 20 8F BD...

Reading raw volume data...
Opening \\.\C:...
Seeking to position 200827092992...
Reading 16384 bytes...
First 16 bytes: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00...
Data is empty (filled with 0x00 bytes).

CONCLUSION: TRIM appears to be WORKING!

Press Enter to exit...

 

[aurum]

Hast du nicht die Möglichkeit mal 50-100gb runter zu schmeißen?

 

[moniduse]

Ja könnte morgen mal den Steamordner verschieben. Dadurch kann sich das Ganze ja mal reorganisieren. Nur seltsam, dass die Geschwindigkeit im abgesicherten Modus ja da ist. Irgendwas spielt dem Schreibvorgang im Normalbetrieb dazwischen.

 

[Holt]

Dann ist klar, warum sie nun wieder schnell schreibt: Werden größere, alte Dateien gelöscht die nicht oder kaum fragmentiert waren, entsteen wieder Lücken die ausreichend lang sind und die Testdatei am Stück aufzunehmen und wenn nicht am Stück, so wenigsten in wenigen, großen Fragmenten. Auch im NAND passiert was ähnliches, da werden wieder eine Menge Blöcke über alle Kanäle frei die auch noch vergleichsweise wenige P/E Zyklen haben und daher kann der Controller die Daten wieder in langen schnellen Schreibzugriffen empfangen und optimal über die Kanäle verteilen. Wenn also zwischen den Tests was gelöscht wird, dann ändert sich immer wieder alles, dass ist dann auch normal.

Allerdings sind die 141MB/s bei AS-SSD noch 100MB/s zu wenig. ATTO zeigt schon deshalb mehr an, weil es mit 4 Oberlapping I/O läuft und die längste Datei im Test gerade 8MB groß ist, die passen sehr wahrscheinlich noch immer in ein Fragment, auch wenn die 32MB von Trimcheck auf 10 Fragmente verteilt waren.

Ergänzung (1. Juni 2014)

Du kannst ja mal MyDefrag runterladen, eine Analyse machen und den Screen posten. Dann sieht man, ob da große Lücken frei sind oder nicht.

 

[aurum]

Hab mal bei mir geschaut wie viel nach nem Jahr noch geht. Fazit: Ist bei dir definitiv zu wenig ^^

 

[moniduse]

Fragmentierung sieht so aus:

 

[Holt]

aurum, Du hast die Evo, sie hat die Vorgängerversion und bei der Evo kommt noch der Turbo Write Cache hinzu, weshalb einmal die Schreibrate deutlich höher ist und dann auch der Effekt der ungünstigen NAND Verteilung bzw. des Aufräumen müssens während des Schreibvorgangs, den Radde beschrieben hat, nicht um Tragen kommt. Der Turbo-Write Cache wird ja immer aufgeräumt und steht daher immer im optimalen Zustand zur Verfügung, egal wie voll die übrigen NANDs sind und wie gut dort die Daten verteilt werden können.

Wenn Du die SSD auch nie so voll gemacht und damit deren Filesystem so stark fragmentiert hast, dann fällt auch die drastische Verkürzung der Zugriffslängen nicht an, weil es ausreichend lange Lücken gibt in die die Benchmarks ihre Testfiles schrieben können.

Ergänzung (1. Juni 2014)

Habe mal wieder meine C: Analysiert, die war zwischenzeitlich auch mal viel zu voll und ist es immer noch:



Das blaue sind Bereiche mit nicht fragmentierten Dateien, die gelben Bereiche haben fragmentierte Dateien belegt, die roten nicht nicht verschiebbaren Systemdateien und die schwarzen sind frei. Davon habe ich oben noch einige größere zusammenhängende, wenn ich Benche sollte es also nicht so dramatisch sein.

Ergänzung (1. Juni 2014)

Man kann sich auch mit Contig von Sysinternals mal ansehen, wie stark die Datei von AS-SSD fragmentiert ist. Bei mir kommt raus:

C:\Sysinternals>contig -a C:\AS-SSD-TEST42\test.bin

Contig v1.55 - Makes files contiguous
Copyright (C) 1998-2007 Mark Russinovich
Sysinternals - www.sysinternals.com

C:\AS-SSD-TEST42\test.bin is in 27 fragments

Summary:
Number of files processed : 1
Average fragmentation : 27 frags/file

C:\Sysinternals>

Man muss aber eine cmd.exe "Als Adminitrator" starten und dort schon vorher contig -a C:\AS-SSD-TEST42\test.bin eingeben, sonst schafft man das während des Tests von AS-SSD u.U. gar nicht! Also vorbereiten, den Benchmark von AS-SSD starten, dann sofort zur cmd.exe wechseln und Enter drücken um den Befehl loszuschicken.

 

[moniduse]

OK habe ich mal gemacht.

C:\AMD>contig -a C:\AS-SSD-TEST42\test.bin

Contig v1.7 - Makes files contiguous
Copyright (C) 1998-2012 Mark Russinovich
Sysinternals - www.sysinternals.com

C:\AS-SSD-TEST42\test.bin is in 4 fragments

Summary:
Number of files processed : 1
Average fragmentation : 4 frags/file

Das kanns irgendwie nicht sein. Ich habe jetzt zudem 103 GB frei gemacht.

 

[Holt]

Wenn Du so viel freigemacht hast, ist es klar dass das Testfile nur in wenige Fragmente aufgeteilt wird. Da die Schreibrate im Abgesicherten Modus ja viel besser war, solltest Du in den Bereich Software weiter forschen. Also mal den Resourcen Monitor (kann man über den Taskmanager im Tab Leistung unten machen) starten, dort Datenträger auswählen und oben bei "Prozesse" sowie darunter bei "Datenträgeraktivität" schauen, wer noch so aktiv ist bzw. aktiv wird, wenn der AS-SSD loslegt. Ggf. auch noch mal im Abgesicherten Modus benchen und vergleichen.

 

[AdoK]

Bitte die extra oben angepinnten Sammelthreads beachten und benutzen!

[Sammelthread] Sind die Werte meiner SSD in Ordnung?