Brandkanne schrieb:
habe hier bei meinem Arbeits-PC (Xeon E3-1220; C226) mit einer Crucial BX300 (240 GB) ein ähnliches Problem.
Hast Du mal auf die S.M.A.R.T. Werte geschaut? Nicht das es ein Problem mit dem SATA Datenkabel gibt? Dies wäre am Rohwert vom Attribut 0xC7 (199) zu sehen.
superman1 schrieb:
Den gleichen Fehler hatte ich Ende 2012 Anfang 2013 auch mit einer Sandisk U100 128Gb SSD die im Samsung Notebook mitgeliefert wurde.
Das war auch so eine DRAM lose SSD mit einem schwachen Controller der nicht viele IOPS bietet, vor allem nicht schreibend.
Hans-juergen schrieb:
Zumindest bei Anandtech kann man das Phänomen anhand der hohen latenzen "nachvollziehen".
https://www.anandtech.com/show/11868/the-toshiba-tr200-3d-nand-ssd-review
Das die Latenzen hoch sind, sieht man dort deutlich, aber es ist nicht exlizit von extremen Latenzen wie hier im Review die Rede. Vielleicht verstecken sie diese in dem Mittelwerten.
Man sieht auch schön das die TR200 bei Betrieb gar nicht so sparsam ist, hier dürften die Datenkompression und der Pseudo-SLC Schreibcache eine Rolle spielen. Wenn Daten stark komprimiert werden muss weniger in die NANDs geschrieben werden und damit fällt die Leistungsaufnahme geringer aus. Ebenso ist es sparsamer NAND im Pseudo-SLC Schreibmodus mit nur einem Bit zu beschreiben als alle Bits auf einmal beschreiben zu müssen. Außerdem dürfte bei den DRAM losen SSDs noch eine Rolle spielen ob die Verwaltungsdaten des Tests der bei der Ermittlung der Leistungsaufnahme läuft ins intern SRAM passen oder aus dem NAND nachgeladen z.B. beim Schreiben immer wieder dort geschrieben werden müssen.
Hans-juergen schrieb:
Bleibt zu hoffen, das es über ein FW Update "optimierbar" ist. Lieber 10-20MB weniger Transferrate, dafür aber ein immer reaktionsschnelles System.
Ob da viel zu machen ist? Ich fürchte die schachen HW Resourcen eine solchen Budget Controllers mit nur einem CPU Kern und zwei NAND Kanälen, werden zu wenig hergeben, zumal der ja auch noch die Datenkompression stemmen muss.
Kowa schrieb:
Das gleiche Phänomen habe ich bei einer OCZ Vector 180 (960GB). Das gestreifte Gehäuse, nicht die "VT180".
Für jedes gelöschtes Gigabyte ist die SSD ca. 1 Sekunde zu 100% ausgelastet. Da ich Videos gerippt habe mit ca. 110GB Größe, bedeutete das 2 Minuten Stillstand, nachdem man solch ein Files gelöscht hat.
In meinen Augen ist die Ursache das TRIM-Kommando.
Das vermute ich auch fast. Wenn die TR200 noch da ist, könnte man TRIM ja mal zum Deaktivieren. Die geht mit
fsutil behavior set DisableDeleteNotify 1
aber besser als in der Registry!
PCPer analysiert die TRIM Speed in seinem Reviews, z.B.
hier bei der Intel 545s und da ist die TR150 die lahmste mit 0,749s pro GB, die 850 Evo braucht 0,051s/GB und die Intel 545s sogar nur 0,014s/GB, ist also im mehr als Faktor 50 schneller als die TR150. Die TR200 dürfte dort dann vermutlich den Negativrekord einfahren, aber ein Test mit deaktiviertem TRIM könnte zeigen wie sehr die Zeit für die Verarbeitung der TRIM Befehle an den Verzögerungen wirklich schuld ist, da dieses aber vor allem nach dem Löschen von Dateien auftreten, dürfte hier der Hase im Pfeffer liegen.
tmkoeln schrieb:
Ich stelle jetzt mal die Preisfrage:
Wer ist zur Zeit unter Toshiba Semiconductor tätig (SK-Hynix?).
Noch ist der Verkauf nocht abgewickelt, also ist diese SSD noch eindeutig unter der Verantwortung von Toshiba entstanden.
