News Samsung kündigt SSD 840 Evo und erste NVMe-SSD an
- Ersteller MichaG
- Erstellt am
- Zur News: Samsung kündigt SSD 840 Evo und erste NVMe-SSD an
Ist die Frage wie das umgesetzt ist und wieviel NAND da wirklich verbaut ist und als "Cache" zur Verfügung steht. Auf jeden Fall wird man sich so langsam nach praxistauglichere Messmethoden umsehen müssen.Holt schrieb:
SanDisk macht das ja auch ähnlich mit ihrem nCache. Ob und was für einen Einfluss sowas hat kann man ja immer nur schlecht messen.
Dafür hat man wenigstens anschließend vollständig gefüllt Blöcke und muss nicht nachträglich rumschaufeln. Höher ist die WA sicherlich, aber nicht zwingend dramatisch höher.
Hab ja auch keine Wertung abgegeben.
Wofür die gedacht ist, sollte klar sein.
Mich würde nur einfach interessieren wie die Schreibperformance ohne diesen "pseudo-SLC-Cache" aussehen würde. Bzw. wie Samsung dem entgegen wirkt. Allein der Cache kanns ja nicht sein. Oder doch? Fragen über Fragen.
bensen schrieb:
Auf thessdreview.com findet sich folgendes:
Seltsam ist nur, dass es für die 500GB und die 1TB Versionen keine Angaben zur Schreibrate wohl aber welche über die Größe des TurboWrite Buffers gibt. Beim schreiben in den TurboWrite Buffer müssten sie auch 520MB/s schaffen und ohne sollten sie bzw. zumindest die 1TB Version eigentlich auch wenigstens die gleichen 420MB/s wie die 750GB Version schaffen.
Zuletzt bearbeitet:
Der Inhalt des "Cache" wird wohl immer dann zurück geschrieben wenn grad keine neuen Schreiboperationen anstehen.
Bzw. sollte das auch eigentlich parallel gehen. Nur dann hätte man nicht die volle Geschwindigkeit des "Cache-Speichers".
@Holt
Interessant
Insgesamt finde ich solche Techniken lobenswert, auch zB solche wie die Komprimierung von Sandforce.
Aber die Laufwerke müssen auf jeden Fall auch dann noch gute Performance zeigen wenn diese Mechanismen nicht greifen. (Also unkomprimierbare Files beim Sandforce oder eben riseige Datenmengen zum schreiben hier bei Samsung).
Und was definitv erforderlich ist, ist die Angabe von Dauertransferraten wenn eben die Mechanismen nicht greifen.
Es ist einfach nur Bauernfang wenn bei Sandforce-Laufwerken selbst die 60 GB versionen mit 500/500 MB/s (R/W) angegeben werden und klar ist, dass das Laufwerk bei unkomprimierbaren Files vielleicht 50 MB/s schafft.
Ähnliches befürchte ich jetzt bei Samsung. Je nach dem wie lange (oder kurz) man diese Transferraten aufrecht erhalten kann sollten auch die Transferraten "danach" angegeben werden.
Aber Tests müssen erstmal zeigen wie das genau funktioniert und wie sich das in der Praxis auswirkt.
Denn generell ist das im Consumerbereich ne gute Sache. Da hier immer die Kosten minimiert werden müssen und dadurch bei der Performance Kompromisse eingegangen werden müssen, kann man so doch noch nen Stück mehr rausholen.
Bzw. sollte das auch eigentlich parallel gehen. Nur dann hätte man nicht die volle Geschwindigkeit des "Cache-Speichers".
@Holt
Interessant
Insgesamt finde ich solche Techniken lobenswert, auch zB solche wie die Komprimierung von Sandforce.
Aber die Laufwerke müssen auf jeden Fall auch dann noch gute Performance zeigen wenn diese Mechanismen nicht greifen. (Also unkomprimierbare Files beim Sandforce oder eben riseige Datenmengen zum schreiben hier bei Samsung).
Und was definitv erforderlich ist, ist die Angabe von Dauertransferraten wenn eben die Mechanismen nicht greifen.
Es ist einfach nur Bauernfang wenn bei Sandforce-Laufwerken selbst die 60 GB versionen mit 500/500 MB/s (R/W) angegeben werden und klar ist, dass das Laufwerk bei unkomprimierbaren Files vielleicht 50 MB/s schafft.
Ähnliches befürchte ich jetzt bei Samsung. Je nach dem wie lange (oder kurz) man diese Transferraten aufrecht erhalten kann sollten auch die Transferraten "danach" angegeben werden.
Aber Tests müssen erstmal zeigen wie das genau funktioniert und wie sich das in der Praxis auswirkt.
Denn generell ist das im Consumerbereich ne gute Sache. Da hier immer die Kosten minimiert werden müssen und dadurch bei der Performance Kompromisse eingegangen werden müssen, kann man so doch noch nen Stück mehr rausholen.
Zuletzt bearbeitet:
Ist doch in dem Artikel auch beschrieben:
Toshiba und Samsung haben ihre NAND sicher darauf ausgelegt, aber man sollte sowas eben nicht mit NANDs machen, die dafür nicht vorgesehen sind.
Es wird zuerst in den Puffer (schnell) geschrieben und wenn der voll ist, wird langsamer direkt in die TLC NANDs geschrieben. Im Idle werden die Daten aus dem Puffer dann in die normalen Zellen kopiert. So machen es auch alle, die so einen Pseudo-SLC Modus implementiert haben. Wichtig ist dabei aber vor allem, dass die NANDs intern auf dieses Beschreiben mit nur einem Bit ausgelegt sind und somit nicht bei der Ladungsunterscheidung versuchen mehr unterschiedliche Ladungszustände zu erkennen als wirklich vorhanden sind. Die Haltbarkeit leidet wegen des Kopierens, was ja die WA erhöht, sowieso schon und wenn sich dann noch die internen Schwellwerte verschieben, umso mehr.
Toshiba und Samsung haben ihre NAND sicher darauf ausgelegt, aber man sollte sowas eben nicht mit NANDs machen, die dafür nicht vorgesehen sind.
Nein, so einfach ist es nicht. Wenn Du genau 111 schreiben willst, da dauert das eben so lange als wenn Du 110 oder 101 oder sonstwie 3 Bits schreibst, Das geht also nicht nicht so einfach und vergiss nicht, es sind ja nicht einzelne Bits die da geschrieben werden, es sind 8 verschiedene Ladungszustände man unterscheiden muss. Dabei geht es auch keine echte 0, denn Restladung bleibt spätestens nach einigen Löschzyklen auch immer zurück.
In den Pseudo-SLC NANDs die darauf ausgelegt sind, wird sich irgendwo ein "Schalter" sein, der der internen Logik sagt, dass nun nur ein Bit geschrieben wird, das hat Toshiba 2011 ja auch so beschrieben. Dann braucht man wirklich nur Ladung oder nicht Ladung zu unterscheiden. Dafür kann man aber nicht noch die weiteren Bits schreiben, sondern muss alles löschen, umschalten und dann hat man wieder MLC/TLC und deshalb hat der Bereich bei denen ja auch eine feste Größe.
Das ist was anderes als was OCZ bei der Vertex4 und Vector macht, denn das Micron NAND ist für dieses Beschreiben mit nur einem Bit nicht vorgesehen. Intern justiert die Elektronik im NAND die Schwellwerte zum Unterscheiden der Ladungszustände (Bits) laufend nach und das kann eben erst geschehen, wenn alle Bits geschrieben wurden. Schreibt man öfter immer nur ein Bit, so unterbleibt die Anpassung und die Wert laufen aus dem richtigen Bereich hinaus, dann hat man ein Problem. Die Vector ist mit über 4% Ausfallrate also nicht zufällig deutlich schlechter als der Durchschnitt von 1,39%, den OCZ nach der Bereinigung der Modellpalette zuletzt aufgewiesen hat.
Das man jetzt immer öfter liest, dass neue Vector mit einige TB geschriebenen Datenvolumen in den S.M.A.R.T. Werten ausgeliefert werden, ist daher nicht nur dem Testen geschuldet, sondern dürfte vor allem dazu dienen, diesen Effekt zu minimieren. Diese Testdaten werden mit Sicherheit so geschrieben, dass immer beide Bits gefüllt werden und die NANDs damit die richtigen Schwellwerte "lernen" und die gerade am Anfang stärker auftretenden Abweichungen kompensieren. Es wird also ein Burn-In der NAND vorgenommen und damit erreicht, dass diese in einen Abnutzungszustand kommen, in dem sich die Schwellwerte nicht mehr so stark ändern wie am Anfang.
Die anfänglichen Ausfallraten wird man damit sicher senken können, aber wie langfristig dieses anhält, wird auch davon abhängen, wie gut es der FW gelingt nicht immer in den gleichen NAND Blöcken nur ein Bit zu schreiben. Es muss als eine zweite Stufe des Wear-Levelings geben, welche nicht berücksichtigt wie oft ein NAND Block schon gelöscht wurde, sondern auch wie oft er (zuletzt) mit einem oder zwei Bits beschrieben wurde. Das macht die sowieso schon hochkomplexe FW nicht einfacher und immer wenn man Kompromisse zugunsten der Haltbarkeit eingehen muss, geht es meist auf die Performance. Legt man seine FW nur auf die Performance aus, so geht es eben auf die Haltbarkeit, gerade wenn man die NANDs anders als von Hersteller vorgesehen verwendet. Das hat OCZ nun wohl endlich verstanden.
In den Pseudo-SLC NANDs die darauf ausgelegt sind, wird sich irgendwo ein "Schalter" sein, der der internen Logik sagt, dass nun nur ein Bit geschrieben wird, das hat Toshiba 2011 ja auch so beschrieben. Dann braucht man wirklich nur Ladung oder nicht Ladung zu unterscheiden. Dafür kann man aber nicht noch die weiteren Bits schreiben, sondern muss alles löschen, umschalten und dann hat man wieder MLC/TLC und deshalb hat der Bereich bei denen ja auch eine feste Größe.
Das ist was anderes als was OCZ bei der Vertex4 und Vector macht, denn das Micron NAND ist für dieses Beschreiben mit nur einem Bit nicht vorgesehen. Intern justiert die Elektronik im NAND die Schwellwerte zum Unterscheiden der Ladungszustände (Bits) laufend nach und das kann eben erst geschehen, wenn alle Bits geschrieben wurden. Schreibt man öfter immer nur ein Bit, so unterbleibt die Anpassung und die Wert laufen aus dem richtigen Bereich hinaus, dann hat man ein Problem. Die Vector ist mit über 4% Ausfallrate also nicht zufällig deutlich schlechter als der Durchschnitt von 1,39%, den OCZ nach der Bereinigung der Modellpalette zuletzt aufgewiesen hat.
Das man jetzt immer öfter liest, dass neue Vector mit einige TB geschriebenen Datenvolumen in den S.M.A.R.T. Werten ausgeliefert werden, ist daher nicht nur dem Testen geschuldet, sondern dürfte vor allem dazu dienen, diesen Effekt zu minimieren. Diese Testdaten werden mit Sicherheit so geschrieben, dass immer beide Bits gefüllt werden und die NANDs damit die richtigen Schwellwerte "lernen" und die gerade am Anfang stärker auftretenden Abweichungen kompensieren. Es wird also ein Burn-In der NAND vorgenommen und damit erreicht, dass diese in einen Abnutzungszustand kommen, in dem sich die Schwellwerte nicht mehr so stark ändern wie am Anfang.
Die anfänglichen Ausfallraten wird man damit sicher senken können, aber wie langfristig dieses anhält, wird auch davon abhängen, wie gut es der FW gelingt nicht immer in den gleichen NAND Blöcken nur ein Bit zu schreiben. Es muss als eine zweite Stufe des Wear-Levelings geben, welche nicht berücksichtigt wie oft ein NAND Block schon gelöscht wurde, sondern auch wie oft er (zuletzt) mit einem oder zwei Bits beschrieben wurde. Das macht die sowieso schon hochkomplexe FW nicht einfacher und immer wenn man Kompromisse zugunsten der Haltbarkeit eingehen muss, geht es meist auf die Performance. Legt man seine FW nur auf die Performance aus, so geht es eben auf die Haltbarkeit, gerade wenn man die NANDs anders als von Hersteller vorgesehen verwendet. Das hat OCZ nun wohl endlich verstanden.
Zuletzt bearbeitet:
@Holt
Die technische Realisierung von TLCs ist mir bekannt.
Das Schreiben des beiden Zustände "000" und "111" sollte sich schneller realisieren lassen, indem man keine Referenzmessung der Ladung auf dem Floating Gate benötigt, wenn das Floating Gate mit der maximalen "Programmierspannung" umgeladen wird. Das iterative Verfahren zur Anpassung der Ladung des Floating Gates entfällt somit.
Daten schreiben -> zurück lesen und vergleichen -> fertig
Die technische Realisierung von TLCs ist mir bekannt.
Das Schreiben des beiden Zustände "000" und "111" sollte sich schneller realisieren lassen, indem man keine Referenzmessung der Ladung auf dem Floating Gate benötigt, wenn das Floating Gate mit der maximalen "Programmierspannung" umgeladen wird. Das iterative Verfahren zur Anpassung der Ladung des Floating Gates entfällt somit.
Daten schreiben -> zurück lesen und vergleichen -> fertig
Richtig, aber genau deswegen würde ich nicht "000" und "111" schreiben, weil man eben die eingebrachte Ladung nicht so genau kennt und sie daher dem Wert für 111 entspricht. Also kann man dieser auch keinen 3Bit Wert zuordnen. In dem SLC Modus ist das einfach eingebrachte Ladung oder keine Ladung (also die Grundladung die nicht mehr abfließt).Hallo32 schrieb:
BestQualityHS
Banned
- Registriert
- Feb. 2010
- Beiträge
- 1.000
Chip hat die neue Samsung SSD 840 Evo 1 getestet.
http://www.chip.de/artikel/Samsung-840-EVO-1-TB-MZ-7TE1T0BW-SSD-Test_63269603.html
Die meinen das die neue 840Evo noch schneller ist wie 840Basic und sogar auch 840Pro.
Hat Chip recht das neue 840Evo schneller ist wie 840Basic und Pro?
Ich habe Samsung 840Pro 256GB aber umsteigen auf eine andere lohnt noch nicht, sicher für neu einsteiger.
Ich warte erst bis 1TB SSD deutlich billiger so wie jetzt normale HDDs kosten mit ab 1TB bis 5TB.
Die SSDs müssen echt mal billiger werden, wenn SSDs, so billig sind wie normale HDDs.
Ewig sollen SSDs nicht teuerer sein wie normale HDDs Festplatten.
http://www.chip.de/artikel/Samsung-840-EVO-1-TB-MZ-7TE1T0BW-SSD-Test_63269603.html
Die meinen das die neue 840Evo noch schneller ist wie 840Basic und sogar auch 840Pro.
Hat Chip recht das neue 840Evo schneller ist wie 840Basic und Pro?
Ich habe Samsung 840Pro 256GB aber umsteigen auf eine andere lohnt noch nicht, sicher für neu einsteiger.
Ich warte erst bis 1TB SSD deutlich billiger so wie jetzt normale HDDs kosten mit ab 1TB bis 5TB.
Die SSDs müssen echt mal billiger werden, wenn SSDs, so billig sind wie normale HDDs.
Ewig sollen SSDs nicht teuerer sein wie normale HDDs Festplatten.
http://www.anandtech.com/show/7173/...iew-120gb-250gb-500gb-750gb-1tb-models-tested
Hier etwas ausführlicher =)
Hier etwas ausführlicher =)
Was haben die denn da getestet? Ich sehen kein Benchmarkergebnis, das sieht eher wie eine Produktbesprechung aus und eine schlechte dazu. c't hat offenbar immer noch keine Kompetenz was SSDs angeht. Da hat sogar tomshardware.de es geachafft von der 840 Evo endlich mal einen lesenswerte Test zu bringen und die haben früher viel Müll in ihren Artikeln und Reviews verzapft.BestQualityHS schrieb:
Tests von der Evo gibt es fast überall und von allen möglichen Kapazitäten (oft sogar gleichzeitig), nur hier bei CB leider noch nicht.
Ähnliche Themen
