naja.. die begehrtesten sehen wohl anders aus
Solid State Drive (SSD) (Part 7|1)
- Ersteller Snoopy69
- Erstellt am
- Status
»»Michael ««
Enthusiast
Mh, begehrt naja.
Aber die gefragtesten. Schon wieder OT.^^
Aber die gefragtesten. Schon wieder OT.^^
WaDenKraMpF
Neuling
naja nich alle spiele, aber wenigtens die ich grad zocke, z.b. Fallout 3. Da haste alle paar min nen levelwechsel, wäre schön wenn das alles bissl beschleunigt würde... wenn man nur 2 spiele mit drauf packt, sind nochmal locker 10 gb weg...
dann noch nen paar große progs, photoshopt etc und die 32gb sind schnell weg. Klar würden die warscheinlich auch reichen, aber ich hab lieber nen bissl mehr platz, und nicht um jedes GB kämpfen müssen.
dann noch nen paar große progs, photoshopt etc und die 32gb sind schnell weg. Klar würden die warscheinlich auch reichen, aber ich hab lieber nen bissl mehr platz, und nicht um jedes GB kämpfen müssen.
»»Michael ««
Enthusiast
Du berechnest ja nicht die Treiber ein, die nehmen dir schon auch arg einiges weg.
Ich habe einen Vergleich zwischen üblicher 2.5" HDD mit 5400upm und einer SSD auf Basis des neuesten JMicron Controllers erstellt, falls von Interesse > klick mich
Reicht für normale Verhältnisse absolut aus und ist deutlich performanter als jede x beliebige Notebook Platte!
Die Berichte über die Hänger machen wir einfach etwas Angst...grundsätzlich würde mir die Performance schon ausreichen...
@32GB:
Ich hab auf meinem Notebook Win7 Ultimate (nix abgespeckt) und alle Treiber & Programme (wobei keine allzu grossen, Photoshop & Illustrator hab ich noch nicht drauf) und komme auf 16GB...klar, bei Spielen wirds dann sehr schnell sehr eng
64GB sind sicherlich angenehmer, da muss man sich nicht allzugrosse Sorgen machen. Falls ich die 30GB-Version kaufe müsste ich schon noch ziemlich abspecken (hibernate weg z.B. (brauchst ja nimmer bei der Bootzeit ).
Zuletzt bearbeitet:
Gibts es irgendwo vorher/nacher Benchmarks wo ein SLC Drive (am besten Mtron oder Intel) richtig hart rangenommen wurde ? Würde mich mal interessieren wie stark die Geschwindigkeit da nachlässt wenn überhaupt, oder hat nur die X25-E das Problem das der Speed ein wenig nachlässt und die Mobis garnicht ?
»»Michael ««
Enthusiast
Wie meinst du mit richtig hart?
Ich könnte eins machen da meine Mobi ca. 99 % voll ist. (100 MB frei...)
Der vorher Test ist einige Seiten vorher zu finden wo die Festplatte 75 % frei ist.
Hab mir erstmal RAM fürs Notebook (4 GB DDR2 800 MHz) gekauft.
Scheint ja auch wichtig zu sein, für SSDs mehr Ram als nötig zu haben.
Grüße,
Michael
Ich könnte eins machen da meine Mobi ca. 99 % voll ist. (100 MB frei...)
Der vorher Test ist einige Seiten vorher zu finden wo die Festplatte 75 % frei ist.
Hab mir erstmal RAM fürs Notebook (4 GB DDR2 800 MHz) gekauft.
Scheint ja auch wichtig zu sein, für SSDs mehr Ram als nötig zu haben.
Grüße,
Michael
Theoretisch sollten ja alle SSDs "einbrechen".
Praktisch zeigt sich das bei den Intels wohl am deutlichsten; die -E ist weniger betroffen als die -M, aber eben auch.
Bei den Mobis - soweit ich jetzt Erfahrungen und Benches gelesen habe - kann man das in den Benchmarks zwar feststellen (die Werte verschlechtern sich aber nicht eklatant), in der Praxis merkt man es aber nicht.
Gruß
Druss
hm ok, wobei die Intel ja trotzdem noch auf sehr hohem niveau bleibt, auch wenn sie abfällt...nur kostet sie eben auch ein Vermögen Naja, ich werde nur auf SLC gehen wenn meine jetzige erste SSD (Ultradrive ME MLC) mich schwer enttäuscht, aufjedenfall nie wieder eine normale HDD als OS Laufwerk
@Michael
100% Befüllung reicht nicht, am besten wäre 100% befüllen, Quickformat, nochmal Befüllen, Quickformat, IOMeter für eine Stunde oder FC-Test laufen lassen und dann nochmal benchen oder sowas in der Richtung. Aber ich kann verstehen wenn das hier keiner seinem Drive antun will.
Naja, ich werde nur auf SLC gehen wenn meine jetzige erste SSD (Ultradrive ME MLC) mich schwer enttäuscht, aufjedenfall nie wieder eine normale HDD als OS Laufwerk @Michael
100% Befüllung reicht nicht, am besten wäre 100% befüllen, Quickformat, nochmal Befüllen, Quickformat, IOMeter für eine Stunde oder FC-Test laufen lassen und dann nochmal benchen oder sowas in der Richtung. Aber ich kann verstehen wenn das hier keiner seinem Drive antun will.
KeinNameFrei
Enthusiast
Bauartbedingt brechen SLC viel weniger ein als MLCs. Das liegt einfach daran, das eine SLC-zelle nur ein Bit Speichern muss, und eine MLC-Zelle bis zu vier. Zusätzlich braucht die MLC-Zelle noch viel kompliziertere ECC-Algorithmen.
Am Anfang sind alle Blöcke leer, man kann also fröhlich reinschreiben. Sobald dann aber die SSD in ihren eigentlichen "Normalbetrieb" übergeht, sprich alle Blöcke wurden einmal 'angefasst' und es muss überschrieben werden, dann wird es langsam. Denn eine SSD kann nicht überschrieben, sie muss erst zwischenpuffern, denn Block blankputzen, und dann neu reinschreiben.
Die Datenraten die der Hersteller bewirbt sind schlichtweg die Raten für den Leerzustand, und nicht für den Normalbetrieb. Man bekommt Maximalwerte genannt, die man bereits nach kurzer Benutzung nicht mehr erreichen kann. Das Problem ist also nicht mal wirklich ein plötzliches "Einbrechen" der Leistung, es ist ganz einfach die Tatsache, dass einem glaubhaft gemacht wird, die Leerleistung einer SSD wäre normal.
Am Anfang sind alle Blöcke leer, man kann also fröhlich reinschreiben. Sobald dann aber die SSD in ihren eigentlichen "Normalbetrieb" übergeht, sprich alle Blöcke wurden einmal 'angefasst' und es muss überschrieben werden, dann wird es langsam. Denn eine SSD kann nicht überschrieben, sie muss erst zwischenpuffern, denn Block blankputzen, und dann neu reinschreiben.
Die Datenraten die der Hersteller bewirbt sind schlichtweg die Raten für den Leerzustand, und nicht für den Normalbetrieb. Man bekommt Maximalwerte genannt, die man bereits nach kurzer Benutzung nicht mehr erreichen kann. Das Problem ist also nicht mal wirklich ein plötzliches "Einbrechen" der Leistung, es ist ganz einfach die Tatsache, dass einem glaubhaft gemacht wird, die Leerleistung einer SSD wäre normal.
KeinNameFrei
Enthusiast
War auch mehr als Antwort auf Druss
Wobei man sagen muss, das mit Techniken wie TRIM das ganze Problem STARK entschärft werden kann, da das SSD dann viel mehr Blöcke zur Verfügung hat.
Beispiel:
Ein SSD mit 3 Blöcken ohne TRIM ist zu 100% gefüllt (2 Blöcke, der 3. ist Reserve) und es werden 2 Blöcke gelöscht und neu geschrieben. Das SSD muss also jetzt: 2x das gelöscht-Bit schreiben (oder wasauchimmer das Dateisystem für den Status "gelöscht" verwendet) was hoffentlich nur in einem Block liegt, dank Cache also einmal Lesen-Schreiben. Der Schreibvorgang findet übrigens auf Block 3 statt auf Block 1 statt, denn der wurde noch weniger benutzt. Dann werden noch 2 Blöcke neu geschrieben (natürlich nicht komplett, der Dateisystemindex z.B. bleibt ja noch gleich), also wieder Lesen-Schreiben, diesmal in Block 2 und nochmal Block 3. Bei einer Blockgröße von 4MB waren das insgesamt 12MB Schreibleistung für 5MB Daten. Dabei hat man doch extra noch 3 MB freigelassen!
Mit TRIM ist das Löschen von Daten genauso ein Schreibvorgang (vermutlich) im Dateisystemindex - ABER nachdem man dalles gelöscht hat, weiß das SSD dass die Daten die man im Moment in der Zelle hat komplett unnnötig sind - sie werden also nicht gelesen sondern gleich überschrieben, so wie das auch nach HDDErase funktioniert (das tut auch nichts anderes als dem SSD ein Kommando zu schicken "Du bist jetzt leer!" - daher geht das auch so schnell weil nur der Controller jetzt einfach sagt "alles klar, verstanden!" und seine Tabelle mit den derzeit belegten Blöcken leert) und das wiederrum hilft dem Controller sehr, noch einige unbelegte Zellen zu finden da viel mehr vorhanden sind. Write Combining wirkt dem Ganzen ja entgegen, indem gleich in mehrere leere Zellen zugleich geschrieben wird, daher ist jede freie Zelle ein Segen.
SLCs brechen nur deswegen nicht so stark ein (außer sie nutzen wie die Intel und vermutlich das io-Drive write combining und müssen daher bei einer Dateiänderung gleich mehrere Zellen erstmal auslesen und dann auch noch wieder in viele Zellen schreiben) weil sie simpler gestrickt sind und aufgrund des binären Charakters (ob jetzt 0,983 oder 0,967 - das ist einfach ca. 1!) weniger Fehlerkorrektur brauchen was natürlich den Controller entlastet. Würde man SLC in ein SSD mit "MLC-Mode" Controller bauen würde das das SSD kaum beschleunigen, da vermutlich die ECC-Informationen etc. der Falschenhals sind. Indilinx versucht das ja einfach mit bruteforce zu brechen (da sitzt ne gar nicht mal so üble ARM-CPU drauf) Intel vermutlich einerseits ebenfalls und andererseits scheinen sie eine für SSDs extrem große Tabelle mit Blockinfos im Cache zu halten mit der sie vermutlcih schneller noch freie Blöcke aufspüren können bzw. den vom Dateisystem gewünschten Block schneller finden.
Beispiel:
Ein SSD mit 3 Blöcken ohne TRIM ist zu 100% gefüllt (2 Blöcke, der 3. ist Reserve) und es werden 2 Blöcke gelöscht und neu geschrieben. Das SSD muss also jetzt: 2x das gelöscht-Bit schreiben (oder wasauchimmer das Dateisystem für den Status "gelöscht" verwendet) was hoffentlich nur in einem Block liegt, dank Cache also einmal Lesen-Schreiben. Der Schreibvorgang findet übrigens auf Block 3 statt auf Block 1 statt, denn der wurde noch weniger benutzt. Dann werden noch 2 Blöcke neu geschrieben (natürlich nicht komplett, der Dateisystemindex z.B. bleibt ja noch gleich), also wieder Lesen-Schreiben, diesmal in Block 2 und nochmal Block 3. Bei einer Blockgröße von 4MB waren das insgesamt 12MB Schreibleistung für 5MB Daten. Dabei hat man doch extra noch 3 MB freigelassen!
Mit TRIM ist das Löschen von Daten genauso ein Schreibvorgang (vermutlich) im Dateisystemindex - ABER nachdem man dalles gelöscht hat, weiß das SSD dass die Daten die man im Moment in der Zelle hat komplett unnnötig sind - sie werden also nicht gelesen sondern gleich überschrieben, so wie das auch nach HDDErase funktioniert (das tut auch nichts anderes als dem SSD ein Kommando zu schicken "Du bist jetzt leer!" - daher geht das auch so schnell weil nur der Controller jetzt einfach sagt "alles klar, verstanden!" und seine Tabelle mit den derzeit belegten Blöcken leert) und das wiederrum hilft dem Controller sehr, noch einige unbelegte Zellen zu finden da viel mehr vorhanden sind. Write Combining wirkt dem Ganzen ja entgegen, indem gleich in mehrere leere Zellen zugleich geschrieben wird, daher ist jede freie Zelle ein Segen.
SLCs brechen nur deswegen nicht so stark ein (außer sie nutzen wie die Intel und vermutlich das io-Drive write combining und müssen daher bei einer Dateiänderung gleich mehrere Zellen erstmal auslesen und dann auch noch wieder in viele Zellen schreiben) weil sie simpler gestrickt sind und aufgrund des binären Charakters (ob jetzt 0,983 oder 0,967 - das ist einfach ca. 1!) weniger Fehlerkorrektur brauchen was natürlich den Controller entlastet. Würde man SLC in ein SSD mit "MLC-Mode" Controller bauen würde das das SSD kaum beschleunigen, da vermutlich die ECC-Informationen etc. der Falschenhals sind. Indilinx versucht das ja einfach mit bruteforce zu brechen (da sitzt ne gar nicht mal so üble ARM-CPU drauf) Intel vermutlich einerseits ebenfalls und andererseits scheinen sie eine für SSDs extrem große Tabelle mit Blockinfos im Cache zu halten mit der sie vermutlcih schneller noch freie Blöcke aufspüren können bzw. den vom Dateisystem gewünschten Block schneller finden.
»»Michael ««
Enthusiast
Wollt die noch zurückgeben, daher mach ich das nicht.
Was denken die wenns die Platte nur noch mit guter IDE Geschwindigkeit läuft.
Also, ich weiß zwar nicht ob der Artikel hier schon bekannt ist, aber sehr viele Fragen die hier zuletzt gestellt wurden werden im 31 seitigen AnandTech Artikel "The SSD Anthology: Understanding SSDs and New Drives from OCZ" ausfürlichst erläutert. Der Artikel ist echt super geschrieben. Ich versuch mal kurz den Inhalt zu beschreiben:
Der Autor hatte in einem Review zu Intels X-25M alle anderen MLC-SSDs so runtergemacht, dass alle SSD-Hersteller erstmal den Kontakt zu ihm abgebrochen haben und ihm keine Test-Kits mehr zugeschickt haben. Später hat sich dann der OCZ-Chef persönlich bei ihm gemeldet und ihm ein Solid- und ein Vertex-Vorserienmodell zur Verfügung gestellt. Nachdem er seine Test gemacht hat und zumindes von der Vertex wieder sehr entteuscht war, hat OCZ ihn gebeten zu erklären wie er die SSD gerne optimiert hätte, damit sie ihm gefällt. Dann hat OCZ tatsächlich in Kürze eine neue Firmware vom Controller-Hersteller schreiben lassen, die letztlich tatsächlich nach seiner Vorstellung war. Die SSD wurden zwar schon an die Reviewer verschickt, aber OZC hat die Produktion gestoppt und die neue Fimware genommen.
Während dieser Zeit hatte er dann auch von dem Problem des Geschwindigkeitsverlustes erfahren und hat dieses erforscht. Erfolgreich.
Naja, jetzt ist er endlich dazu gekommen diesen lange geplanten Artikel zu schreiben. Angefangen von den oben genannten Hintergründen erklärt er erstmal verständlich mit Hilfe von einfachen Grafiken den Aufbau und die Funktionsweise von MLC-SSDs, den Unterschied zu SLC, wie es zum Geschwindigkeitsverlust kommt, wie man den Geschwindigkeitsverlust rückgängig macht, wie man ihn simmuliert, die Unterschiede und die Geschichte zu den verschiedenen Controllern,... das Ganze wird von Benchmarks begleitet die einen großen Teil der unterschiedlichen Controller abdecken.
Also, wie gesagt, der Artikel ist echt super und es lohnt sich in komplett durch zu lesen.
Hier gibts noch mal einen Kürzeren Artikel zu SSDs und HDDs im Enterprise-Vergleich:
SSD versus Enterprise SAS and SATA disks
Der Autor hatte in einem Review zu Intels X-25M alle anderen MLC-SSDs so runtergemacht, dass alle SSD-Hersteller erstmal den Kontakt zu ihm abgebrochen haben und ihm keine Test-Kits mehr zugeschickt haben. Später hat sich dann der OCZ-Chef persönlich bei ihm gemeldet und ihm ein Solid- und ein Vertex-Vorserienmodell zur Verfügung gestellt. Nachdem er seine Test gemacht hat und zumindes von der Vertex wieder sehr entteuscht war, hat OCZ ihn gebeten zu erklären wie er die SSD gerne optimiert hätte, damit sie ihm gefällt. Dann hat OCZ tatsächlich in Kürze eine neue Firmware vom Controller-Hersteller schreiben lassen, die letztlich tatsächlich nach seiner Vorstellung war. Die SSD wurden zwar schon an die Reviewer verschickt, aber OZC hat die Produktion gestoppt und die neue Fimware genommen.
Während dieser Zeit hatte er dann auch von dem Problem des Geschwindigkeitsverlustes erfahren und hat dieses erforscht. Erfolgreich.
Naja, jetzt ist er endlich dazu gekommen diesen lange geplanten Artikel zu schreiben. Angefangen von den oben genannten Hintergründen erklärt er erstmal verständlich mit Hilfe von einfachen Grafiken den Aufbau und die Funktionsweise von MLC-SSDs, den Unterschied zu SLC, wie es zum Geschwindigkeitsverlust kommt, wie man den Geschwindigkeitsverlust rückgängig macht, wie man ihn simmuliert, die Unterschiede und die Geschichte zu den verschiedenen Controllern,... das Ganze wird von Benchmarks begleitet die einen großen Teil der unterschiedlichen Controller abdecken.
Also, wie gesagt, der Artikel ist echt super und es lohnt sich in komplett durch zu lesen.
Hier gibts noch mal einen Kürzeren Artikel zu SSDs und HDDs im Enterprise-Vergleich:
SSD versus Enterprise SAS and SATA disks
Wie oft denn noch... außerdem ist Anand da auch etwas größenwahnsinnig, wenn er glaubt alleine für die Änderung der FW zuständig zu sein. Supertalent hat z.B. auch seine baugleichen SSDs verzögert ohne irgendwas zu Anand zu schicken. Außerdem hat er es im Gegensatz zu uns hier nicht geschafft die Vertex zum Ausfall zu bringen, daher hat er entweder nicht ernsthaft genug getestet oder zu schlampig. An Controllern werden z.B. Samsung Controlle quasi gar nicht abgedeckt und auch SLCs wie die Mtrons sind nicht zum Vergleich aufgeführt, nur die Intel-E.
KeinNameFrei
Enthusiast
Diese Punkte beiseite, ist dennoch der Artikelteil zum Thema Funktionsweise von SSDs einer der besten, die ich bis jetzt gesehen habe. Zumindest hat es vorher keiner geschafft, das Problem der verringerten Geschwindigkeiten so präzise, vollständig und leicht verständlich aufzuschlüsseln.
Man könnte den Link eigentlich zu jeder zweiten Frage im gesamten Storage-Forum als Antwort posten, und er wäre immer relevant
Man könnte den Link eigentlich zu jeder zweiten Frage im gesamten Storage-Forum als Antwort posten, und er wäre immer relevant
Karl Heinz
Neuling
- Mitglied seit
- 24.10.2008
- Beiträge
- 75
MFT von Easyco
Hi,
bringt diese Software eigentlich etwas bei meiner SSD Patriot Warp 32 GB ?
http://managedflash.com/
G
KH
Hi,
bringt diese Software eigentlich etwas bei meiner SSD Patriot Warp 32 GB ?
http://managedflash.com/
G
KH
Viele die hier Fragen stellen scheinen den Artikel nicht zu kennen. Also egal wie oft.
Genau das mein ich.
AlexQUAD23
Enthusiast
@Karl Heinz
Würde mich auch intressiern! ob die was bringt!
Kann einer was dazu sagen?
Würde mich auch intressiern! ob die was bringt!
Kann einer was dazu sagen?
AlexQUAD23
Enthusiast
@MacWolf
Wenn wir das noch nicht gemacht hätten häten wir nicht gefragt!!
Wenn jemand was dazu sagen kann soll ers sagen!
LG
Alex
Wenn wir das noch nicht gemacht hätten häten wir nicht gefragt!!
Wenn jemand was dazu sagen kann soll ers sagen!
LG
Alex
wenn ihr das getan hättet, hättet ihr auch was gefunden.
z.B. das hier:
http://www.hardwareluxx.de/community/showthread.php?t=574664&page=67
das Ganze zieht sich dann über einige Seiten...
z.B. das hier:
http://www.hardwareluxx.de/community/showthread.php?t=574664&page=67
das Ganze zieht sich dann über einige Seiten...
Zuletzt bearbeitet:
habe hier mal meine Ultradrive ME MLC maltretiert und Benches sowie Praxiswerte zu den Slowdowns geliefert:
http://www.hardwareluxx.de/community/showpost.php?p=11646215&postcount=591
http://www.hardwareluxx.de/community/showpost.php?p=11646215&postcount=591
Schon klar, aber wenn die Zellen voll sind (und alle Zellen der SSD einmal beschrieben wurden), dann ist erst mal egal, ob da ein oder vier bit drin sind. Die SSD muss dann einen ganzen Block löschen, um nur die keinste Einheit von 4kb zu speichern, muss das zu speichernde in den Cache laden => löschen => schreiben. Das kostet Zeit und stellt sich praktisch als Geschwindigkeitseinbuße dar.
Also müssen in der Theorie auch die SLC langsamer werden.
Praktisch sieht es ja meist etwas anders aus...
- Status