Härtetest: Was hält eine SSD aus? (Fazit)

Den 180° Unterschied bemerkst du hoffentlich noch ...
Nein, ich bin schon so langsam so merkbefreit wir ihr :eek:

Deine Rückschlüsse zu Verbesserungen beim Produktionsprozess als Begründung das die zweite M4 länger hielt begründest du worauf?
Ich habe das richtige Kraut geraucht, da hat mir ein Spatz das gesungen :hmm:

Nach deiner These müssten dann ja die ersten besser gewesen sein, waren sie aber nicht - also These hinfällig? ;)
Du hast es nicht verstanden oder willst Du es nicht verstehen? Immer öfter denke ich, die Leute hier wollen es nicht versteten. Das am Anfang die Ausbeute extrem guter Dies sehr gerung ist, sollte bekannt sein und es hat sich nun einmal gerade während der Fertigungszeit der m4 ergeben, dass die Enterprise SSDs von SLC auf eMLC, was nicht anderes ist als die besten Dies der normalen MLC Fertigung, stattgefunden hat.

Mitunter so gebinnt und verkauft. Von Intel gibt es NAND mit mehr als 5k Zyklen, der noch lange kein eMLC ist.
Wer hat das Gebenteil behauptet? 5000 Zyklen waren und sind bisher zu wenig für eMLC.

Eigentlich schaute ich hier nur rein um zu sehen ob Dbode die zweite OCZ dazu gestopft hat. Leider fand ich dazu keinen Post, aber eben deine Posts.
Leider finde ich Deinen Post, das Leben ist eben hart zu uns beiden. :wall:
Sehe gerade, DragronTear hat es kürzer und diplomatischer verpackt. ;) Ich bin, zumindest die letzte Zeit, eher der direkte Typ.
Der ist auf meiner Ingone Liste, das landest Du jetzt auch, auf solche Typen habe ich langsam keinen Nerv mehr, man wird mit der Zeit eben dünnhäutiger.

Auf nimmerwiederschreiben!
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Es ist halt einfach die Dinge, die einem nicht in das Sichtfenster passen, einfach auszublenden. Daher kam wohl auch keine Erklärung, inwiefern OCZ denn auf Amazon Druck ausüben könnte, um deine Theorie zur Versandumleitung zu untermauern.
Du hast es nicht verstanden oder willst Du es nicht verstehen? Immer öfter denke ich, die Leute hier wollen es nicht versteten.
Vielleicht mag man mitunter subjektive Meinungen auch einfach nicht als Fakten schlucken. Es wirkt nun einmal manchmal so, als würdest du Tatsachen mit Mutmaßungen zu neuen Tatsachen machen. Das ganze klingt dann erst einmal logisch, genauer betrachtet, ist es das aber zumindest für mich in vielen Fällen nicht.

Beispiel M4:
Ja, zu Anfang jeder neuen Serie von NAND ist sicherlich die Ausbeute schlechter, als später. Da sind wir uns natürlich einig. Daraus aber abzuleiten, dass deshalb die zweite M4 so viel länger hielt, ist einfach Quark.
Es waren lediglich 2 Laufwerke, was statistisch eben nichts aussagt. Ein drittes SSD hätte genau so gut wieder früh sterben können.

Beispiel eMLC:
Das war aber eine andere Zeit, damals wurde MLC nur in Consumer SSDs verbaut und erst als die zweite m4 schon im Test lief, begannen die Hersteller Enterprise SSDs mit MLC zu bringen.
Wenn damals zu M4 Zeiten (Ende 2011) MLC nur in Consumer SSDs verbaut wurde, wäre doch die Gegenfrage angebracht, was dann mit dem schon 2009/2010 in 34nm produzierten eMLC von Micron gemacht wurde? Nur weil Produkte nicht im Endkundenmarkt waren, bedeutet das für mich nicht zwangsläufig, dass es keine gab.

Schon 2010 gab es die Ankündigung seitens Intel eMLC in 25nm in Zukunft in Enterprise Laufwerke zu packen. Wieso sollte Intel/Micron dann nicht zu Beginn der Fertigung schon dementsprechend gebinnt haben? Deine Aussage war ja quasi: Weil es noch keine Produkte mit eMLC im Endkundenhandel gab, hat Intel/Micron auch keinen eMLC gebinnt, sondern diesen in Consumer SSDs mit verwurstelt und deshalb hielt die zweite M4 so lange.

Nur wo läge da der Sinn? Für mich ist es viel wahrscheinlicher das, eben gerade wenn die Ausbeute zu Anfang gering war, erst einmal genügend NAND in eMLC Güte zu binnen, damit man später auch genügend Enterprise Laufwerke ohne Lieferschwierigkeiten anbieten kann.
 
Zuletzt bearbeitet:
@Mr.Mito Vergiss es lieber.. mit Holt kann man in diesem Thread nicht richtig diskutieren..

Zum Artikel: Ihr solltet die Autoupdates ausschalten sonst funkt Windows dazwischen! ><
Des weiteren, interessant dass die Samsung jetzt relativ schnell an % verliert. Bin gespannt ob sich das wieder verlangsamt.
 
Wenn man sich den Graphen bei Techreport zur normalen 840 anschaut, ist nicht damit zu rechnen.

The SSD Endurance Experiment: Casualties on the way to a petabyte - The Tech Report - Page 2

OT
Ja, leider. Mag sein das ich vom Schreibstil her über die Stränge schlug, inhaltlich bleibe ich aber dabei. Das ist halt, gerade was die eMLC/M4 Thesen betrifft, Kaffeesatzlesen. Es gibt ja zig Möglichkeiten, selbst ich nannte verschiedene. Überproduktion guter NAND und "Entsorgung" in Consumer Laufwerken oder das Gegenteil - geringe Ausbeute und von Anfang an der Produktion strikte Selektion für spätere Enterpriselaufwerke. Im Endeffekt wird es mal so, mal so laufen, je nach Marktsituation und Yield.
Dann gibt es noch Holts Theorie, wo zu Anfang eMLC in bei den Consumern landete und Intel/Micron erst anfing in die Richtung zu binnen, als Enterprise Laufwerke anstanden. Wobei ich das für am unwahrscheinlichsten halte, da man beim Marktstart der Enterprise Laufwerke nun einmal volle eMLC Lager braucht und ja schon Jahre zuvor 34nm eMLC produziert wurde, obwohl wir keine Laufwerke damit kannten. Irgendwo verbaut wurde der NAND aber sicherlich.

Das sind aber nun einmal alles nur Theorien, keine Fakten. Wissen tut es nur der Hersteller und daran ecke ich an. Wenn man dann nachbohrt wird das übergangen oder zerredet, wie die Amazon golden sample Geschichte. Wenn man zu etwas ausgefallene Theorien hat, sollte man die nicht als Fakten hinstellen und anderen unterstellen sie hätten "keinen Schimmer von der Geschäftswelt".
 
Zuletzt bearbeitet:
Aktuell hat die OCZ 58,5TiB plus 50TiB und steht bei 59%, also 41% für 108,5TiB -> 2,6TiB pro 1% spezifizierten Zyklen.
Die MX100 steht nach 43TiB bei 90%, also 4,3TiB pro 1% Zyklen, die Samsung hat nach 50,4TiB noch 83%, also 3TiB pro 1% spezifizierte Zyklen. Nach den früher abgelesenen S.M.A.R.T. Werte sind für die OCZ 3.000 P/E Zyklen hinterlegt, das sollte auch für die MX100 gelten und die Evo müsste um die 1200 spezifizierten P/E Zyklen haben. Wieso ist die OCZ nur bei 59%? Die verbraucht die P/E Zyklen entweder zu schnell oder hat sie schon ausgefallene Blöcke und darum wurde die Anzeigen der Restlebensdauer reduziert? Es war ja bei einigen OCZ SSDs schon so, dass die Restlebensanzeige nicht alleine auf den P/E Zyklen basierte.

Es wäre für ausgefallene NAND Blöcke aber noch zu früh und die Evo müsste eigentlich viel weniger TiB pro 1% der spezifizierten Zyklen haben, denn die hat ja viel weniger spezifizierte Zyklen und die außerdem hat die OCZ ab Werk am meisten OP, also zumindest die Voraussetzungen für die geringste WA der drei.
 
es sollte man jemand den Balken weg machen:-)
Und die Windesupdates stoppen, sonst gibt es einen Reboot:-)

Schöner Test, Danke
 
@Mr.Mito
Dbode hat beide OCZ aufgeschraubt, dann den Controller und die Teilenummer der NANDs verglichen und weil alles übereinstimmt beschlossen die 2. OCZ nicht mit in den Test aufzunehmen.
 
wäre es möglich jeden Tag eine andere SSD abwechselnd im Hard Disk Sentinel auszuwählen? Mich würden mal die Anderen interessieren, die MX100 hatten wir jetzt lange genug
 
Was ist denn nun los? Jetzt läuft da nur eine OCZ und die hat plötzlich 99% Restleben und nur 2,7TiB geschrieben, hat man also die 2. OCZ jetzt doch in den Test gepackt und die anderen dafür solange rausgenommen? Oder gibt es ein zweites Livebild für die 3 bisher getesteten?
 
Wovon sprecht ihr? Bei mir ist alles beim alten!
Seht ihr schon Gespenster. :d
 
Jetzt ist wieder das Bild wie gehabt mit den 3 SSDs zu sehen. Vielleicht schaltet das Bild ja regelmäßig um, jedenfalls scheint der Test mit der zweiten OCZ nun doch stattzufinden.

- - - Updated - - -

Bleibt aber die Frage aus #221, denn der verbrauch an Restleben der OCZ ist weiterhin höher und die zweite war bei 2,7TiB und hatte 32 Zyklen, also auch gerade etwas mehr als 1% der spezifizierten Zyklen verbraucht.

Aktuell hat die OCZ bei 68,3TiB plus 50TiB und steht bei 55% "Restleben", hat also 45% der spezifizierten P/E Zyklen für 118,3TiB verbraucht, was 2,6TiB pro 1% spezifizierten Zyklen entspricht.
Die MX100 steht nach 50TiB bei 88%, also 4,2TiB pro 1% Zyklen, die Samsung hat nach 58,7TiB noch 80%, also 2,94TiB pro 1% der spezifizierten P/E Zyklen.
 
Wieso nervt er? Ich finde seine Beitraege immer sehr lesenswert und er hat Plan wovon er spricht.
 
Wer selbst denkt war gewissen Leuten schon immer unbequem :eek:
 
Nichtsdestotrotz. Die Dinger sind ja ganz schön langlebig. Die Frage die ich mich hier stelle: Lohnt eine SSD für einen 24/7 Betrieb bei Überwachungskameras?
 
braucht TRIM eigentlich nicht auch leerlaufzeiten um zu arbeiten? Würde ja in so einem "Dauerlauf" ja nicht funzen sonst. Der Test wäre zwar immernoch gut aber auch nicht 100% aussagekräftig.
 
Naja Trim ist ja nur der Befehl bzw die Info vom Betriebssystem, dass eine Datei (Block) gelöscht wurde. Nicht mehr und nicht weniger.

Was der Controller der SSD damit macht ist sein Thema. Prinziepell gilt je voller eine SSD umso schwieriger das Thema aufräumen und freie Blöcke finden, aber das GC garnichtmehr statfindet das passiert nicht.
 
TRIM spielt hier eher eine untergeordnete Rolle, weil die SSDs immer komplett geleert und wieder gefüllt werden. Es kommt also quasi nie zu hoher Belegung und dann in Folge der Belegung zu hoher WA.

Bin mal gespannt ob die OCZ ab dem 16.9. die Daten für 2 Wochen halten kann...

@Dbode
Es wäre super, wenn ihr den Test mit voller SSD pausieren könntet, damit nach der Pause direkt der Gegencheck (gekippte Bits) durch auslesen gemacht werden kann!
 
braucht TRIM eigentlich nicht auch leerlaufzeiten um zu arbeiten? Würde ja in so einem "Dauerlauf" ja nicht funzen sonst. Der Test wäre zwar immernoch gut aber auch nicht 100% aussagekräftig.

Die Daten werden am Ende jedes Loops gelöscht, wobei das Trim-Kommando abgesetzt wird. Der Entwickler des Testprogramms hat m. W. die Karenz zwischen den Loops so bemessen, dass der SSD-Controller danach ausreichend Zeit zum Erasen des Flash haben sollte, bevor erneut geschrieben wird.

TRIM spielt hier eher eine untergeordnete Rolle, weil die SSDs immer komplett geleert und wieder gefüllt werden. Es kommt also quasi nie zu hoher Belegung und dann in Folge der Belegung zu hoher WA.

Wenn die Daten am Ende des Loops ohne Trim gelöscht würden, wäre das gesamte Flash nach 12 geschriebenen GB des zweites Loop bis auf das Spare Area für den Rest dieses Tests vollständig befüllt. Ich glaube schon, dass das eine ungünstige Auswirkungen auf die WA hätte.
 
Zuletzt bearbeitet:
Nichtsdestotrotz. Die Dinger sind ja ganz schön langlebig. Die Frage die ich mich hier stelle: Lohnt eine SSD für einen 24/7 Betrieb bei Überwachungskameras?
Wozu brauchst Du da eine SSD? Da musst Du schon eine Menge Kameras haben, damit die eine HDDs ans Limit bringen. Dann schreibst Du dauernd auf die SSD, so ewig lange werden die Consumer SSDs dann auch nicht halten und dann haben sie auch nur eine relativ begrenzte Kapazität.

Klar kann man das machen, man müsste sich aber gut überlegen, welchen Vorteil man sich davon verspricht und ob der die Kosten wert ist. Dazu müsste man auch ermitteln, wie viele Daten dort geschrieben werden um überhaupt abschätzen zu können, wie lange die SSDs etwa halt dürfte.

Der Test wäre zwar immernoch gut aber auch nicht 100% aussagekräftig.
Kein Test ist 100% aussagekräftig. Das ist hier auch absolutes Schönwetterszenario für SSDs, die werden ja immer seq. überschrieben und dabei ist die WA meist am geringsten. Reale Anwender haben eine Haufen statischer Daten auf der SSD, eben z.B. das installierte Windows und die Programme, da ändert sich ja kaum mal was und Bereich die ständig überschrieben werden und auch zwar oft mit kurzen, zufälligen Schreibzugriffen. Die reale WA ist daher meist schon deutlich höher als bei dem Test mit Anvils Tool, nur hängt die tatsächliche WA eben auch immer extrem vom einzelnen Nutzer ab. Schaffen die SSDs unter diesen Bedingungen aber viele 100TBW, so ist das immer noch mehr als genug um zu sagen, dass normale Heimanwender die in 10 Jahren und mehr nicht kaputt bekommen und so lange halten HDDs meist auch nicht, davon dass HW meist sowieso früher getauscht wird, mal ganz abgesehen.

TRIM spielt hier eher eine untergeordnete Rolle, weil die SSDs immer komplett geleert und wieder gefüllt werden. Es kommt also quasi nie zu hoher Belegung und dann in Folge der Belegung zu hoher WA.
So ist es, der Controller erfährt ja auch ohne TRIM durch das Überschreiben der LBAs, dass die alten Daten die denen vorher zugeordnet waren, nun ungültig sind und von der GC abgeräumt werden können. Da es auch noch sequentielle Schreibzugriffe sind, ist das sowieso kein echtes Thema.

Bin mal gespannt ob die OCZ ab dem 16.9. die Daten für 2 Wochen halten kann...
Wenn sie keine 2 Wochen hält, wäre das extrem traurig. Die JEDEC verlangt 12 Monate bei 30°C und da die DRT sich pro 10°C mehr halbiert, müsste man die SSD in einem Ofen bei konstanter Temperatur von z.B. 40°C nur 6 Monate, bei 50°C 3 Monate, bei 60°C 6 Wochen und 70°C noch 3 Wochen lagern um das zu überprüfen. Bei 80°C wären es noch 1 1/2 Wochen, aber da müsste man schauen, ob die Spezifikationen eine solche Lagertemperatur erlauben.
@Dbode
Es wäre super, wenn ihr den Test mit voller SSD pausieren könntet, damit nach der Pause direkt der Gegencheck (gekippte Bits) durch auslesen gemacht werden kann!
Gute Idee, dass man mit h2testw ja auch recht einfach realisieren.

Wenn die Daten am Ende des Loops ohne Trim gelöscht würden, wäre das gesamte Flash nach 12 geschriebenen GB des zweites Loop bis auf das Spare Area für den Rest dieses Tests vollständig befüllt. Ich glaube schon, dass das eine ungünstige Auswirkungen auf die WA hätte.
Ohne TRIM wäre die WA höher, keine Frage, aber so extrem voll würde das NANDs auch nicht werden, weil ja immer die gleichen LBAs dann wieder überschrieben werden und der Controller auch so erfährt, welche Daten er löschen kann um wieder aktuelle Daten zu schreiben. Da hier im Test ja keine statischen Daten auf den SSDs liegen, ist auch das Wear-Leveling keine echte Herausforderung für die Controller. Das war bei Test auf xtremesystems.org noch anders, da wurden die SSDs teils sogar zu 2/3 der Kapazität mit statischen Daten gefüllt, was das Wear-Leveling vor ganz andere Herausforderungen stellt.

- - - Updated - - -

Nichtsdestotrotz. Die Dinger sind ja ganz schön langlebig. Die Frage die ich mich hier stelle: Lohnt eine SSD für einen 24/7 Betrieb bei Überwachungskameras?
Wozu brauchst Du da eine SSD? Da musst Du schon eine Menge Kameras haben, damit die eine HDDs ans Limit bringen. Dann schreibst Du dauernd auf die SSD, so ewig lange werden die Consumer SSDs dann auch nicht halten und dann haben sie auch nur eine relativ begrenzte Kapazität.

Klar kann man das machen, man müsste sich aber gut überlegen, welchen Vorteil man sich davon verspricht und ob der die Kosten wert ist. Dazu müsste man auch ermitteln, wie viele Daten dort geschrieben werden um überhaupt abschätzen zu können, wie lange die SSDs etwa halt dürfte.

Der Test wäre zwar immernoch gut aber auch nicht 100% aussagekräftig.
Kein Test ist 100% aussagekräftig. Das ist hier auch absolutes Schönwetterszenario für SSDs, die werden ja immer seq. überschrieben und dabei ist die WA meist am geringsten. Reale Anwender haben eine Haufen statischer Daten auf der SSD, eben z.B. das installierte Windows und die Programme, da ändert sich ja kaum mal was und Bereich die ständig überschrieben werden und auch zwar oft mit kurzen, zufälligen Schreibzugriffen. Die reale WA ist daher meist schon deutlich höher als bei dem Test mit Anvils Tool, nur hängt die tatsächliche WA eben auch immer extrem vom einzelnen Nutzer ab. Schaffen die SSDs unter diesen Bedingungen aber viele 100TBW, so ist das immer noch mehr als genug um zu sagen, dass normale Heimanwender die in 10 Jahren und mehr nicht kaputt bekommen und so lange halten HDDs meist auch nicht, davon dass HW meist sowieso früher getauscht wird, mal ganz abgesehen.

TRIM spielt hier eher eine untergeordnete Rolle, weil die SSDs immer komplett geleert und wieder gefüllt werden. Es kommt also quasi nie zu hoher Belegung und dann in Folge der Belegung zu hoher WA.
So ist es, der Controller erfährt ja auch ohne TRIM durch das Überschreiben der LBAs, dass die alten Daten die denen vorher zugeordnet waren, nun ungültig sind und von der GC abgeräumt werden können. Da es auch noch sequentielle Schreibzugriffe sind, ist das sowieso kein echtes Thema.

Bin mal gespannt ob die OCZ ab dem 16.9. die Daten für 2 Wochen halten kann...
Wenn sie keine 2 Wochen hält, wäre das extrem traurig. Die JEDEC verlangt 12 Monate bei 30°C und da die DRT sich pro 10°C mehr halbiert, müsste man die SSD in einem Ofen bei konstanter Temperatur von z.B. 40°C nur 6 Monate, bei 50°C 3 Monate, bei 60°C 6 Wochen und 70°C noch 3 Wochen lagern um das zu überprüfen. Bei 80°C wären es noch 1 1/2 Wochen, aber da müsste man schauen, ob die Spezifikationen eine solche Lagertemperatur erlauben.
@Dbode
Es wäre super, wenn ihr den Test mit voller SSD pausieren könntet, damit nach der Pause direkt der Gegencheck (gekippte Bits) durch auslesen gemacht werden kann!
Gute Idee, dass man mit h2testw ja auch recht einfach realisieren.

Wenn die Daten am Ende des Loops ohne Trim gelöscht würden, wäre das gesamte Flash nach 12 geschriebenen GB des zweites Loop bis auf das Spare Area für den Rest dieses Tests vollständig befüllt. Ich glaube schon, dass das eine ungünstige Auswirkungen auf die WA hätte.
Ohne TRIM wäre die WA höher, keine Frage, aber so extrem voll würde das NANDs auch nicht werden, weil ja immer die gleichen LBAs dann wieder überschrieben werden und der Controller auch so erfährt, welche Daten er löschen kann um wieder aktuelle Daten zu schreiben. Da hier im Test ja keine statischen Daten auf den SSDs liegen, ist auch das Wear-Leveling keine echte Herausforderung für die Controller. Das war bei Test auf xtremesystems.org noch anders, da wurden die SSDs teils sogar zu 2/3 der Kapazität mit statischen Daten gefüllt, was das Wear-Leveling vor ganz andere Herausforderungen stellt.
 
So ist es, der Controller erfährt ja auch ohne TRIM durch das Überschreiben der LBAs, dass die alten Daten die denen vorher zugeordnet waren, nun ungültig sind und von der GC abgeräumt werden können. Da es auch noch sequentielle Schreibzugriffe sind, ist das sowieso kein echtes Thema.

Im Endurancetest von ASU wird sequenziell und zufaellig geschrieben.
 
Stimmt, etwas Random wird auch gerschrieben, wobei der bei der OCZ sehr viel weniger als bei den anderen beiden ist. Ist ja links der zweitunterste Wert in den Blauben Kästchen und da hat die Crucial 22500MiB auf 50,7TiB im Ganzen (444MiB / 1TiB), die Evo 27200MiB auf 59,5TiB (457MiB / 1TiB) und die OCZ nur 1584,52MiB auf die aktuell angezeigten 69,25TiB (23MiB / 1TiB, im Verhältnis also viel weniger und als einzige so eine krumme Zahl). Da scheinen die Einstellungen abweichend zu sein. Trotzdem macht das auch bei den anderen weniger als ein halbes Prozent das gesamten Schreibvolumens aus, sofern die Einheiten noch wie in diesem Screenshot sind.
 
Die Samsung 840 Evo ist ja erst später in den Test gekommen, sie liegt nach sieben Tagen im Härtetest bei 63 TB. Ihre Life-Time ist auf 78% herunter gegangen, sodass sie entsprechend bei 0% angekommen wäre, wenn ca. 286 TB geschrieben worden wären. Samsung spezifiziert die Zellen also für eine etwas höhere Schreiblast als OCZ.
Das ist übrigens falsch, denn wie ich hier schon ausgerechnet habe, verbraucht die OCZ einfach mehr P/E Zyklen pro geschriebenes TB als die anderen. Die hat also eine höhere Write Amplification unter diesen Bedingungen:
Aktuell hat die OCZ 58,5TiB plus 50TiB und steht bei 59%, also 41% für 108,5TiB -> 2,6TiB pro 1% spezifizierten Zyklen.
Die MX100 steht nach 43TiB bei 90%, also 4,3TiB pro 1% Zyklen, die Samsung hat nach 50,4TiB noch 83%, also 3TiB pro 1% spezifizierte Zyklen. Nach den früher abgelesenen S.M.A.R.T. Werte sind für die OCZ 3.000 P/E Zyklen hinterlegt, das sollte auch für die MX100 gelten und die Evo müsste um die 1200 spezifizierten P/E Zyklen haben.
Die Werte stimmen auch mit den aktuellen Angeben noch recht genau:

OCZ: 139TBW/53% = 2,62TBW/1% spezifizierte P/E Zyklen
Evo: 75,3TBW/26% = 2,9TBW/1% spezifizierte P/E Zyklen
MX100: 65,6TBW/16% = 4,1TBW/1% spezifizierte P/E Zyklen

Damit kann die Frage beantwortet werden:
Die verbraucht die P/E Zyklen entweder zu schnell oder hat sie schon ausgefallene Blöcke und darum wurde die Anzeigen der Restlebensdauer reduziert?
Auch ohne einen Blick auf die S.M.A.R.T. Werte, der natürlich trotzdem wünschenswert wäre, kann wohl recht sicher davon ausgehen, dass die Anzeige nicht von ausgefallenen Blöcken beeinflusst ist (die es vermutlich noch nicht gibt) sondern die WA einfach höher liegt.

Das kann man auch ausrechnen, denn bei der OCZ und der MX100 sollte 1% der spezifizierten Zyklen 30 Zyklen entsprechen. Bei der Evo wäre jetzt wirklich ein Blick auf die S.M.A.R.T. Werte hilfreich, aber ich unterstelle mal 12. Dann sind das:

OCZ: 2,62TBW/30 Zyklen = 87,4GB / Zyklus ; 240GB / 87,4GB= 2,75
Evo: 2,9TBW/12 Zyklen = 241GB / Zyklus ; 250GB / 241GB = 1,04
MX100: 4,1TBW/30 Zyklen = 136,7GB / Zyklus ; 256GB / 136,7GB = 1,87

Dabei habe ich nun gemäß der JEDEC die Nutzkapazität zugrunde gelegt. Wie man sieht ist die Aussage "Samsung spezifiziert die Zellen also für eine etwas höhere Schreiblast als OCZ" so wohl nicht korrekt. Aber nur ein Blick auf die laut den S.M.A.R.T. Werte konkret verbrauchten P/E Zyklen würde das definitiv belegen.
 
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