[Sammelthread] Sind die Werte meiner SSD in Ordnung? (Teil VII)

Status
Für weitere Antworten geschlossen.
Die Sandforce Controller komprimieren die Daten und die beworbenen Transferrate werden mit ATTO mit extrem komprimierbaren Daten (nur Nullen) gemessen. Reale Daten sind weit weniger komprimierbar und damit die Werte teils sehr viel schlechter. Man kann alle SF-2281 SSDs mit async. ONFI NAND wie Deine Force3 leistungsmäßig mit einer Agility3 vergleichen und für die gab OCZ früher im Datenblatt auch die folgenden Werte mit nicht komprimierbaren Daten (AS-SSD Benchmark) an:

60GB: Seq. Lesen 180MB/s, seq. Schreiben 65MB/s, rand. 12.500 IOPS (50MB/s)/ 17.500 IOPS (70MB/s)

Davon ist Deine ja nicht weit weg und der Unterschied zu vorher, als das Alignment noch nicht gestimmt hat ist bei den 4k, 4k_64 schreibend und 4k_64 Lesend doch klar zu sehen, auf die seq. Werte hat ein falsches Alignment dagegen kaum kaum Auswirkungen, da trifft es bei den langen Zugriffen ja auch nur den ersten und letzten "Sektor", also 8k und deshalb macht es bei bis zu 16MB pro Zugriff eben kaum etwas aus.
 
Von einer 60GB SSD kann man auch nicht viel erwarten. Die 64GB Crucial m4 macht beim Schreiben auch keine 100MB/s.
Und mit aktuellen SSDs kann man die Größe nicht vergleichen, weil die erst bei 120GB anfangen und mehr NAND parallel beschreiben können.
 
Das hängt von der SSD ab, die Samsung 830 64GB z.B. schreibt seq. mit 160MB/s, die Plextor M6m auch und alles ohne Datenkompression oder Pseudo-SLC Cache. Die Crucial SSDs waren bei der seq. Schreibrate nie wirklich an der Spitze und die SSD mit Sandforce schon gleich gar nicht, wenn sie die Daten nicht extrem gut komprimieren können.
 
Zuletzt bearbeitet:
Habt ihr bei der 840 Evo auch einen etwas unglaubwürdigen wear leveling count?
Bis jetzt habe ich 4.54 TBW, aber der wear leveling count steht noch bei 4. Bei einer 500GB-SSD geht die Rechnung für mich nicht auf.
 
Alles klar.

Schönen Dank für eure Aussagen. Dann soll mir das so reichen :)
 
Ein WA von unter 1 kann schon angehen, wenn die Daten geschrieben und gleich wieder gelöscht oder überschrieben wurden, bevor sie auf dem Turbo-Write Pseudo-SLC Cache in den normalen TLC Bereich übertragen wurden. SanDisk rechnet bei der Ultra II die ja ganz ähnlich funktioniert damit auf diese Weise einie WA unter 1 erreichen zu können, da die P/E Zyklen des Pseuso-SLC ja nicht mitgezählt werden.

eremit007 4 bei einer 500GB mit 4.5TBW sind allerdings sehr wenig, hast Du auch auf den richtigen Wert geachtet? Der Rohwert ist entscheidend, da steht die Zahl der P/E Zyklen.
 
@Holt
Code:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  5 Reallocated_Sector_Ct   0x0033   100   100   010    Pre-fail  Always       -       0
  9 Power_On_Hours          0x0032   098   098   000    Old_age   Always       -       6031
 12 Power_Cycle_Count       0x0032   098   098   000    Old_age   Always       -       1487
177 Wear_Leveling_Count     0x0013   099   099   000    Pre-fail  Always       -       4
179 Used_Rsvd_Blk_Cnt_Tot   0x0013   100   100   010    Pre-fail  Always       -       0
181 Program_Fail_Cnt_Total  0x0032   100   100   010    Old_age   Always       -       0
182 Erase_Fail_Count_Total  0x0032   100   100   010    Old_age   Always       -       0
183 Runtime_Bad_Block       0x0013   100   100   010    Pre-fail  Always       -       0
187 Uncorrectable_Error_Cnt 0x0032   100   100   000    Old_age   Always       -       0
190 Airflow_Temperature_Cel 0x0032   074   058   000    Old_age   Always       -       26
195 ECC_Error_Rate          0x001a   200   200   000    Old_age   Always       -       0
199 CRC_Error_Count         0x003e   100   100   000    Old_age   Always       -       0
235 POR_Recovery_Count      0x0012   099   099   000    Old_age   Always       -       59
241 Total_LBAs_Written      0x0032   099   099   000    Old_age   Always       -       9767387633
 
Sind 4, also dürften bei Dir viel geschrieben werden, was gleich wieder gelöscht oder überschrieben wird und damit nie den Weg ins normale TLC nimmt.
 
Ok, das wäre eine Erklärung. Aber erklären kann ich mir das trotzdem nicht :)
Die SSD ist in einem normalen Desktop. Und ein Wear-Leveling-Count von 4 bei 4.5TBW würde bedeuten dass mehr als die Hälfte aller geschriebenen Daten nie im TLC ankommt. Nungut.
 
Habe nun meine etwas ältere SSD mit 64GB mal getestet, weil sie mir langsamer vorkam.
Vllt bilde ich mir auch nur ein, dass sie langsamer ist.

Kingston SV100S264G

Seq. Read:
232 MB/s

Seq. Write:
35.18 MB/s

Zugriffszeit:
Lesen: 0,377ms
Schreiben: 0,410ms


Die 35 MB beim schreiben sind doch nicht normal oder? Habs mit meiner alten HDD verglichen, und selbst die kommt auf 80MB/s.
Ist die SSD im Arsch? :/ Den Lesewert finde ich ja in "Ordnung" für so ne alte SSD.

Edit: Laut dem Tool "Hard Disk Sentinal", was ich durch Recherche gefunden habe, soll die SSD aber fehlerfrei sein. Was ich mir aber mit diesen Schreibwert nicht erklären kann.
Edit2: Kann es daran liegen, dass ich die SSD zu 85% voll habe?

HILFE
 
Zuletzt bearbeitet:
Das ist eine alte SSDs und die alten SSDs haben oft das Problem, dass die Performance mit der Zeit nachlässt, das ist bei denen fast normal, vor allem wenn sie nicht getrimmt werden. Prüfe mal mit TrimCheck ob TRIM wirklich funktioniert. Man lässt es zweimal laufen, beim ersten mal wird die Testdatei erzeugt und gelöscht, beim zweiten mal wird geschaut ob TRIM funktioniert hat. Dazwischen sollte man nichts am Rechner machen und ein paar Minuten warten. TrimCheck muss auf der SSD liegen, wenn es ausgeführt wird.
 
Schonmal danke für eure Antworten :)

@deo
Neueste Firmware ist noch nicht drauf, weil ich die aktuell noch als Systemplatte benutze.
Wird aber demnächst durch eine 128GB ersetzt.

Wollte die Kingston aber gern weiter verwenden um häufig benutzte Software darauf zu installiern :/

@Holt
"TRIM appears to be NOT WORKING"
Was heißt das genau? :/
 
Das bedeutet, dass vermutlich TRIM nicht funktioniert, oder Du hast nicht lange genug gewartet. Welches Windows hast Du? Vor Win7 gibt es sowieso kein TRIM, dann wäre das auch erklärt. Dann wäre die Frage, ob die SSD überhaupt TRIM unterstützt, poste also mal den Screenshot von CrystalDiskInfo, das zeigt an ob der Controller angibt es zu unterstützen. Dann öffne mal eine cmd.exe "Als Administrator" und führe dort aus:fsutil behavior query DisableDeleteNotify
Das Ergebnis sollte sein: DisableDeleteNotify = 0

Dann kann es noch sein, dass der Treiber die TRIM Befehle schluckt, poste also auch noch den Screenshot von Drive Controller Info.
 
Sind die Werte meiner SSD in Ordnung?
sandiskuii.PNG
 
Ohne zu wissen um welche SSD es geht, kann man das nicht sagen. AS-SSD kann den kompletten Screenshot selbst speichern (Datein -> Screenshot), dann sieht man oben auch welche SSD überhaupt getestet wurden. Die Information hast Du leider abgeschnitten.
 
Sandisk Ultra II
 
Hallo, habe mir eine Crucial MX100 mit 256 GB gegönnt und im AHCI Modus installiert. Außerdem ist bei mir der IRST installiert. Meine System"festplatte" ist eine m4 64 GB; aber um die geht es nicht. Ich habe soeben die MX100 mit AS-SSD gebenched und mit anderen Werten verglichen.

Problem: meine Schreibgeschwindigkeiten(en) unterschreiten deutlich die üblichen Benchmarkwerte. Außerdem ist der 4K-64K Lesewert erheblich niedriger. Woran kann das liegen?

hier ein üblicher Benchmark aus dem Netz:

Unbenannt.PNG

und hier meine Werte:

as-ssd-bench Crucial_CT256MX1 21.12.2014 12-08-38.png

Weiß jemand eine Lösung?
 
hurcos schrieb:
Dann ist die Schreibrate etwas zu gering.

MoJoe19 und hurcos, bencht mal im Abgesichterten Modus von Windows, vielleicht bremst der Virenfinder, die mit dem großen G am Anfang sind z.B. dafür bekannt.
 
Im abgesicherten Modus sind die Werte besser; wie kann ich die gleichen Werte im normalen Modus bekommen?
PS: Ja, ich habe G Data.
 
Status
Für weitere Antworten geschlossen.
Zurück
Oben