SSD UltraDrive Supertalent / OCZ Vertex SSD / Indilinx Barefoot Controller [Part 11]

Status
Für weitere Antworten geschlossen.
Ich hab meine SSD 2x aktualisiert:
1. am 20.06.2009 auf 1571, ca. 2 Monate nachdem ich sie gekauft habe
2. vor ca. 3,5 Monaten auf 1916, welches aber nicht destruktiv war (Daten gingen nicht verloren, und die 3600 Stunden Betriebsdauer sind wesentlich mehr als 3,5 Monate)

Es fehlen also höchstens die ersten 2 Monate (war das Update auf 1571 noch destruktiv?), die SSD ist also vielleicht schon auf 85% statt 89% runter, hält sie halt "nur" noch 6 Jahre...

Ist bei mir ähnlich! Laut Vorbesitzer wurde sie direkt nach dem Kauf auf 1571 upgedatet, und von mir dann auf 1916 - also sollten die Daten in etwa stimmen!

Aber ich bin jetzt sehr beruhigt, war schon irgendwie "geschockt" das die SSD schon so "verbraucht" ist...ich vermute aber auch, das der Vorbesitzer da ein paar Benches hat drauf laufen lassen, was ja eigentlich nicht so dolle ist...
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Wie lange dauert eine RMA bei SST bzw. schickt der Händler (in meinem Fall Mindfactory) die SSD wirklich zum Hersteller?
 
@DerRob

Achso - na wenn du nur 1571 und 1916 hattest ist das natürlich jut. 1571 war destruktiv, ja.
 
1571 war nicht destruktiv. Nur ein Downgrade auf 1571 von einer höheren FW war destruktiv.
 
Wie lange dauert eine RMA bei SST bzw. schickt der Händler (in meinem Fall Mindfactory) die SSD wirklich zum Hersteller?

Die SSDs landen beim Disti der die gegen Neuware austauscht.
Wir machen das innerhalb weniger Tage. Wie lang der jeweilige Händler für die RMA Abwicklung braucht, ist immer wieder verschieden und auf die Abläufe haben wir auch keinen Einfluss.
 
So, daß TRIM bei einen SSD-Raid nicht geht, scheint sich zumindest unter der FW1916 dank GC wohl nicht negativ auf die Performance auszuwirken:

Am Tag der Einrichtung:
unbenannt1nr8n.png


Gerade gebencht:
unbenanntkssj.png
 
das ist ja das Tolle an GC.
Zumal GC bei der 1916 wirklich sehr gut arbeitet.
Allerdings hast du das Raid ja noch nicht so lange, schau dir das in 2-3 monaten nochmal an, schon als GC noch nicht implementiert war hatte es bei meinem damaligen Raid0 aus 3 Vertex 2-3 monate gedauert bis überhaupt mal ne verschlechterung sichtbar wurde, allerding bin ich zu der zeit noch sehr vorsichtig mit unnötigen schreibvorgängen gewesen, wie wurden großteils einfach nicht gemacht und wenn doch mal dann auf HDD verlagert.
 
Das stimmt, lang hab ichs noch nicht. Aber ich denke mal, daß ist die wohl optimalste Lösung die beiden kleinen GX zusammen als ein Laufwerk arbeiten zu lassen. Und flott ist es ja auch. ;)
 
Das stimmt, lang hab ichs noch nicht. Aber ich denke mal, daß ist die wohl optimalste Lösung die beiden kleinen GX zusammen als ein Laufwerk arbeiten zu lassen. Und flott ist es ja auch. ;)

Leider aber auch die gefährlichste Lösung. Aber es ist immer wieder schön, wenn man ein Versuchskaninchen hat. :fresse:
Also, bleib dran und informiere uns weiterhin.
 
das ist ja das Tolle an GC.
Zumal GC bei der 1916 wirklich sehr gut arbeitet.

Entschuldigung, das kann ich so überhaupt nicht bestätigen. Die Garbage Collection frisst hier in aller Seelenruhe meine Platte auf:

Code:
Jun 10 10:21:52 lake smartd[2958]: Device: /dev/sda [SAT], SMART Usage Attribute: 208 Average_Erase_Count changed from 376 (Raw) to 377 (Raw)
Jun 10 12:51:52 lake smartd[2958]: Device: /dev/sda [SAT], SMART Usage Attribute: 208 Average_Erase_Count changed from 377 (Raw) to 378 (Raw)
Jun 10 14:21:52 lake smartd[2958]: Device: /dev/sda [SAT], SMART Usage Attribute: 208 Average_Erase_Count changed from 378 (Raw) to 379 (Raw)

Die Platte hat also innerhalb von 4 Stunden im Schnitt jeden Sektor etwa zweimal gelöscht. Dies ist eine STT_FTM64GX25H mit 64 GByte, d.h. es waren Löschvorgänge mit insgesamt 128 GByte.

Laut Betriebssystem wurden insgesamt seit dem letzten Booten (9:21) nur 524524 kByte, d.h. 0.524 GByte auf die Platte geschrieben:

> iostat -k
Code:
Linux 2.6.34-44-default (lake)  10.06.2010      _x86_64_        (2 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          10,38    0,01    2,48    0,08    0,00   87,05

Device:            tps    kB_read/s    kB_wrtn/s    kB_read    kB_wrtn
sdb               0,02         0,80         0,00      15061          0
sda               2,83        53,44        27,73    1010690     524524

Mir fehlen schlicht die Worte.
 
Interessant. Vertrauen ist gut, Kontrolle ist besser - manchmal lag Lenin doch nicht so daneben.
 
Habe heute auf die Firmware 1.6 geflasht welche seit 2 Tagen verfügbar ist aber nicht darauf geachtet
wie der Wert für diesem hier ist, "Hex-Wert / Spezifikation des max. PE Zählerstandes".

Kann es sein das die Zyklen auf 5000 halbiert wurden mit dem neuen update, dacht dieser hätte 10.000 Zyklen.
Die SuperTalent 128GB GX hat zb. laut DiskInfo 10.000 Zyklen, diese OCZ 64GB eben halt nur 5000 Zyklen ?

Wer hat eine Info oder die SSD OCZ-Vertex 64GB und kann etwas darüber sagen.

SSD: OCZ-Vertex 64GB
CPU: Intel Q9650 @ 3,6Ghz
Controller: ICH10R
BS: W7 x64
Veröffentlichung: Ja
 

Anhänge

  • 1ocz64gb.jpg
    1ocz64gb.jpg
    70 KB · Aufrufe: 59
  • 2ocz64gb.jpg
    2ocz64gb.jpg
    191,2 KB · Aufrufe: 64
Zuletzt bearbeitet:
Hat sich anscheinend halbiert. Berichten auch mehrere im OCZ Forum.
Changelog gibts ja noch keinen.
 
Gut in hinsicht auf.. GC hält die SSD relativ schnell.

Mein reden war von anfang an das es 2 FW varianten geben soll, einmal mit und einmal ohne GC, leider hat man die NonGC version aber nach 1-2 tagen wieder von netz genommen.

Ich fand auch das GC nur für Raid User wínteressant ist für alle anderen eigentlich nur sinnfreie shcreibzugriffe, ich hab aber nichts zu melden bei ST jungs, ich bin nur Beta tester und kann sagen was ich denke, was die dann draus machen liegt nicht in meiner hand, leider.
 
Ich hätt gerne ne 3te Version, mit TRIM und sehr defensiven GC.
Aber auf mich hört auch keiner :fresse:
 
schon klar
deine 3. version wäre halt sinnbefreit wenn es ne version mit und ohne GC weiterhin gegeben hätte ;)
 
Auf meinem SSD wird wesentlich weniger gelöscht laut CDI.

Mittl. Löschzählerstand: 000...0A2, Max. 1A4.

Nach ein paar Wochen, 228 Betriebsstunden.
 
Zuletzt bearbeitet:
Ich denk auch das das was frief hat (mal davon ausgegangen das das richtig ausgelesen wird) sicherlich nicht der normal zusand ist, allerdings optimiert man ja gern mal so das unnötige schreibvorgänge weitestgehend ausgelagert oder abgestellt werden, da ists natürlich ärgerlich wenn GC oder WL überduchschnittlich viel schreibt.
Von daher hätte ich persönlich eine GC freie version schon für vorteilhaft empfunden (in diesem speziellen fall da es eben schon eine nonGC version gab).
Andererseits bieten andere hersteller aber auch keine zig versionen an. bei den Intel ist GC ja auch mit drin (wenn ich mich jetzt nicht irre) und da gibts auch keine auswahlmöglichkeit.
Also ist das schon ok so wie es ist und wie gesagt, GC funktioniert in hinsicht auf performance ganz ordentlich seit der 1916.
 
Zuletzt bearbeitet:
Leider aber auch die gefährlichste Lösung. Aber es ist immer wieder schön, wenn man ein Versuchskaninchen hat. :fresse:
Also, bleib dran und informiere uns weiterhin.
Quark! non_Raid ist nicht "ausfallsicherer" als Raid. Wer das glaubt, naja.
Ich hatte schon öfters im Festplattenbereich Raids, sowohl über onboard als auch mit externen Controllern, ausgefallen ist dort nie etwas. Im Gegenteil, Festplattencrash hatte ich ausschließlich immer im non_Raid Betrieb und da auch meist unreparierbar.

Das die beiden SSD im Raid laufen erfüllt den eigentlich erstrebten Grundgedanken 2 Datenträger zu vereinen und wenn das auch noch perform läuft, umso besser.
 
Quark! non_Raid ist nicht "ausfallsicherer" als Raid. Wer das glaubt, naja.
Ich hatte schon öfters im Festplattenbereich Raids, sowohl über onboard als auch mit externen Controllern, ausgefallen ist dort nie etwas. Im Gegenteil, Festplattencrash hatte ich ausschließlich immer im non_Raid Betrieb und da auch meist unreparierbar.

Das die beiden SSD im Raid laufen erfüllt den eigentlich erstrebten Grundgedanken 2 Datenträger zu vereinen und wenn das auch noch perform läuft, umso besser.

Könnte es eventuell, in ganz seltenen Fällen, so sein, dass Deine :fresse: größer als Deine Ahnung ist?

Ja ja, wie Du meinst...
 
Zuletzt bearbeitet:
natürlich ist das risiko auf datenverlust bei einem raid0 höher, liegt ja einfach daran das da 2 und mehr laufwerke sind wo eins ausfallen kann und somit daten futsch sind, also soweit sollte das logisch sein oder?
 
Ich hätt gerne ne 3te Version, mit TRIM und sehr defensiven GC.
Aber auf mich hört auch keiner :fresse:

Absolut. Denn nicht die GC an sich ist schlecht, sondern wie es implementiert wird.
 
Hi Morpog,
dann habe ich doch noch keine Alzheimer. :d

Die sind irgendwie lustig bei OCZ mal eben so nur noch die Hälfte angeben an Zyklen und wenn bzw. falls die SSD vor den
3 Jahren Garantie halt aufgibt weil die Zyklen verbraucht wurden können die sich damit rausreden, ich glaubs echt nicht. :motz:

Möchte mal wissen was bei denen aufm Rezept vom Doc gestanden hat. :shot:

Dann war es das letzte mal das ich von denen was gekauft habe, die glauben wohl ihre Kunden einfach mal so......... zu können !!
 
Zuletzt bearbeitet:
natürlich ist das risiko auf datenverlust bei einem raid0 höher, liegt ja einfach daran das da 2 und mehr laufwerke sind wo eins ausfallen kann und somit daten futsch sind, also soweit sollte das logisch sein oder?
Die gleiche Platte kann dir aber auch non_Raid ausfallen und dann? ;)

So oder so bis du eh nur auf der sicheren Seite wenn du wichtige Daten sicherst/spiegelst, egal in welchen Modis deine Platten/SSDs laufen, selbst Raid1 oder 10 würd ich da nicht mehr vertrauen wie Raid0.
 
Hi Morpog,
dann habe ich doch noch keine Alzheimer. :d

Die sind irgendwie lustig bei OCZ mal eben so nur noch die Hälfte angeben an Zyklen und wenn bzw. falls die SSD vor den
3 Jahren Garantie halt aufgibt weil die Zyklen verbraucht wurden können die sich damit rausreden, ich glaubs echt nicht. :motz:

Möchte mal wissen was bei denen aufm Rezept vom Doc gestanden hat. :shot:

Dann war es das letzte mal das ich von denen was gekauft habe, die glauben wohl ihre Kunden einfach mal so......... zu können !!

OCZ kannste da eigentlich nicht mal was vorwerfen, Indilinx ist da wohl eher der Verursacher. Ich bin mir fast sicher dass diese Änderung bei allen Herstellern kommen wird mit der nächsten FW.
 
Zuletzt bearbeitet:
boah was ist denn mit der 1916er los?
schreibt scheinbar die ganzezeit auf der platte rum. pc quasi unbenutzbar.

jetzt will ich wieder downgraden nur hat mein seriennummer kein aix oder bix drinnne :/ (supertalent ultradrive me einmal 64 einmal 128 gb)

---------- Beitrag hinzugefügt um 07:42 ---------- Vorheriger Beitrag war um 07:13 ----------

ftm64gx25h und ftm28gx25h hab ich wo finde ich da die 1571 firmware?

---------- Beitrag hinzugefügt um 08:04 ---------- Vorheriger Beitrag war um 07:13 ----------

und welche firmware nehme ich da am besten? die downgrade 1711 ->1571 ?
 
das ist weder OCZ noch Indilinx das ist MLC Problem, Intel spricht von 3000 Zyklen
ein Hersteller hat bei der Intel sogar nur etwas mehr als 1000 Zyklen gemessen,
 
Zuletzt bearbeitet:
Status
Für weitere Antworten geschlossen.
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh