Solid State Drive (SSD) (Part 5|2)

[SSDfix]

@Witell:
Kein Grund sich hier in rage zu reden.
alles was ich gesagt habe, ist, dass es mehrere Ursachen haben kann wenn Datenkorruption auftritt. Das muss nicht zwangsweise an MLC liegen.
Jeder macht seine Erfahrungen mit SSD, das Forum dient zum Austausch. Nur weil andere Leute mit MLC keine schlechten Erfahrungen gemacht haben wie Du, muss das nicht gleich heissen dass die Unrecht oder keine Ahnung haben.
Du sagst immer Mtron ist so toll. Mtrons sind auch gut, aber haben auch Ihre Macken und sind bei einigen Kunden von uns auch schon durch die Evaluierung geflogen.
Und die Entwicklung neuer Controller macht nicht halt (Mtron Neo, Indilinx Barefoot, JMicron 602B, Phison) und es wird immer neue SSDs mit besseren Werten geben.
Und gerade durch die neuen Controller werden viele Schwächen der aktuellen MLC Designs ausgemerzt.
Aber Deine Trotzreaktion am Ende (macht doch was Ihr wollt) ist schon etwas verwunderlich. Wenn alle der gleichen Meinung sind, braucht man auch kein Forum. ;-)

 

[SSDfix]

Mahlzeit,


ist das schon bekannt?Sieht sehr gut aus!

http://www.tweakpc.de/news/15341/g-skill-titan-ssds-mit-128-und-256-gbyte/


mfg

Schade dass nicht dabei steht welchen Controller die verwenden....

 

[glare]

gskill titan:

intel x25-m:

Transcend 32GB JMicron B Controller

Randomwrite-technisch hat sich dort nicht viel getan bei der gskill titan.

 

[vander]

Aus dem Startposting entnehme ich das die Schreibleistung bei vielen kleinen Blöcken der Knackpunkt bei MLC SSDs ist, solange kein Kontroller mit Cache zu Einsatz kommt. Kann man das nicht mit Hilfe des Schreibcaches von Windows optimieren? AFAIK kann man bei SATA im Gerätemanager sogar einen erweiterten Schreibcache aktivieren.
Ansonsten wäre da noch meine andere Idee, einen speziellen Filtertreiber für MLC SSDs zu installieren der die Schreibzugriffe erstmal ins RAM umleitet und in möglichst kontrollerfreundlich auf die SSD schreibt. So einen Treiber gibt es zwar (noch) nicht, aber einen ähnlichen Effekt könnte man vielleicht mit dem EWF(Enhanced Write Filter) oder FBWF(File based write Filter) erreichen.

P.S. Hoffentlich bin ich in diesem Thread richtig. für eine allgemeine Diskussion.

 

[antiram]

wahrscheinlich schon wieder 2 zusammengeklebte JMicrons als Raid0 bei G-Skill Titan, wegen dem schlechten 4k write.

wie beim OCZ Apex
http://www.ocztechnologyforum.com/forum/showthread.php?t=47949

und Photofast G-Monster V2
http://nueda.main.jp/blog/archives/004068.html
http://translate.google.de/translat...p+v3+photofast+monster+v2&hl=de&safe=off&sa=G

 

[Mitch]

Aus dem Startposting entnehme ich das die Schreibleistung bei vielen kleinen Blöcken der Knackpunkt bei MLC SSDs ist, solange kein Kontroller mit Cache zu Einsatz kommt. Kann man das nicht mit Hilfe des Schreibcaches von Windows optimieren? AFAIK kann man bei SATA im Gerätemanager sogar einen erweiterten Schreibcache aktivieren.
Ansonsten wäre da noch meine andere Idee, einen speziellen Filtertreiber für MLC SSDs zu installieren der die Schreibzugriffe erstmal ins RAM umleitet und in möglichst kontrollerfreundlich auf die SSD schreibt. So einen Treiber gibt es zwar (noch) nicht, aber einen ähnlichen Effekt könnte man vielleicht mit dem EWF(Enhanced Write Filter) oder FBWF(File based write Filter) erreichen.

P.S. Hoffentlich bin ich in diesem Thread richtig. für eine allgemeine Diskussion.

grundsätzlich schon, aber allein beim lesen der letzten seite hättest du merken können, dass der rückschreibcache in den meisten fällen die performance mindert.

 

[antiram]

Aus dem Startposting entnehme ich das die Schreibleistung bei vielen kleinen Blöcken der Knackpunkt bei MLC SSDs ist, solange kein Kontroller mit Cache zu Einsatz kommt.

das liegt nicht am fehlenden Cache. Ein Cache kann das Schreibproblem bloß ein paar zehntel Sekunden in die Zukunft verschieben, bis der cache voll ist.

das ganze funkioniert so derzeit bei JMicron, Mtron:
zb. OCZ V1 hat 38 GB NANDs, 30 GB zugänglich, Rest ist hinter einem Vorhang und leer.
Beim schreiben von 4k + commit werden die 4k an die richtige Stelle in einem leeren Eraseblock hintern Vorhang geschrieben, dann wird der Rest des alten Eraseblocks drüberkopiert. Alter und neuer Eraseblock werden vertauscht. Der alte Eraseblock ist jetzt hinter dem Vorhang und kann gelöscht werden. D.h. bei write(4k)+commit wird der also der ganze Eraseblock neu geschrieben. Bei OCZ V1 sind 1 Eraseblock = 8MB. Ein Cleaner muss laufen der die Eraseblocks mit kalten und heißen Daten vertauscht, damit alle Eraseblocks gleichmäßig abgenutzt werden.

Bei Intel gehts wahrscheinlich so:
In einer Zuordnungstabelle steht wo welcher Sektor in der Hardware zu finden ist. 4k writes werden so lange in einen leeren Eraseblock geschrieben, bis er voll ist. Dabei wird die Zuordungstabelle (im Cache) immer sofort angepasst. Dadurch gibts zigtausend IOPS. Allerdings wird dadurch beim Überschreiben immer neu geschrieben, was dazu führt daß Eraseblocks auch nicht mehr aktuelle Daten enthalten. Deshalb muss ein Cleaner laufen, der ständig die noch aktuellen Daten zusammenfasst um die dabei entstehenden Eraseblocks mit alten Daten löschen zu können. Wenn sehr viel geschreiben wird hat auch der Cleaner mehr zu tun und die Performance geht ein bißchen runter.

In keinem Fall braucht man dazu einen Datencache.

 

[crysel]

@ glare:

Nimm das Bild der Intel da raus... ist jawohl ein schlechter Witz die miteinander zu vergleichen. Die Intel mit nur 50MB und die anderen beiden 500MB.

 

[vander]

Hmm, nach meiner Vorstellung sollte das verschieben des Problems dabei helfen einen Lag wegen der überlaufenden Queue am kontroller zu verhindern?
Außerdem stelle ich mir vor das ein guter Cache im optimalem Fall mehrere Zugriff zu einem Zugriff zusammenfassen könnte, was auch eine Entlastung des kontrollers zur Folge haben sollte. Zum Beispiel beim schreiben vieler kleiner Dateien auf eine FAT Partition wird zum einen die Datei geschrieben, zum anderen die FAT aktualisiert. Die Blöcke der Datei können sofort geschrieben werden, der Block mit der FAT könnte aber auch erst später aktualisiert werden. Dann würden alle Schreibzugriffe auf die FAT nur einmal erfolgen und Lesezugriffe würden durch den Cache erfolgen.
Geht das so oder stelle ich mir das grad zu einfach vor?

 

[antiram]

kann sein daß der Cache ein bißchen hilft. Aber zb. kernel compilieren dauert 15min, die Queue ist 15min voll und der Cache kann die Lags nicht verhindern. Die lags sollen aber auch dann verhindert werden.

Schreiben kann aus mehreren Streams bestehen, zb. Daten und FAT oder Daten und Journal. Aber bei commits muss Cache und Queue auf alle Fälle leer geschrieben werden. Sonst verliert das Dateisystem die Kontrolle darüber was jetzt wirklich sicher geschrieben wurde und was nicht. Z.B. bei Daten und Journal wichtig.

Edit: bzw. stimmmt schon. Die Plattencaches schalten man zwecks Datensicherheit ja ab bei Servern. Dann ignoniert ja der Festplattecache die commits. Darf aber trotzdem nicht laggen.

 

[sanic]

erledigt, danke snoopy

 

[glare]

@ glare:

Nimm das Bild der Intel da raus... ist jawohl ein schlechter Witz die miteinander zu vergleichen. Die Intel mit nur 50MB und die anderen beiden 500MB.

Naja um dich zu beruhigen, hier die Werte ausm CrystalDiskMark mit 500MB der Intel X25-M in tabellierter Form, und du siehst keine sehr großen Änderungen v.a. hinsichtlich der Random Writes @4KB zwischen 50MB und 500MB (Schwankungen sind eher bedingt durch die unterschiedlichen Controller als durch die Size von 50MB bzw. 500MB in dem Fall, die bei SSDs eh einen kleineren Einfluß hat als bei HDDs, ausser der Cache der SSD wird durch die Testfile nicht aufgefüllt):

CrystalDiskMark @500MB:

Hier auch nochmal untabelliert, eine andere Quelle @500MB:
http://d.hatena.ne.jp/HIN/20080929
--------------------------------------------------
CrystalDiskMark 2.2 (C) 2007-2008 hiyohiyo
Crystal Dew World : http://crystalmark.info/
--------------------------------------------------

Sequential Read : 254.016 MB/s
Sequential Write : 78.983 MB/s
Random Read 512KB : 174.298 MB/s
Random Write 512KB : 78.135 MB/s
Random Read 4KB : 19.823 MB/s
Random Write 4KB : 54.595 MB/s

Test Size : 500 MB

 

[Fairy Ultra]

sehr toll Mix-Computer hat es hinbekommen mir 2 mal die IDE Variante zu schicken ...
somit von mir vorerst keine Ergebnisse.

 

[AoEGoD]

rofl was für Deppen

 

[Eddie Eagle]

Hallo,

auch nach Neuinstallation hat sich das Verhalten der MOBI 3525 16GB aus #2229 nicht geändert. In der Kompatibilitätsliste ist das ASUS P5Q-E geführt. Winkom habe ich gemailt wie es jetzt weitergehen soll. Mist, ist echt zum k....

Eddie

 

[glare]

http://www.theinquirer.de/2009/01/06/sandisk-stellt-nachste-ssd-generation-vor.html

Sandisk stellt nächste SSD-Generation vor

Dienstag, 06 Januar 2009 17:17 von G. Kustermann

Und möchte mit den neuen Festplatten-Modellen vor allem im Netbook-Markt punkten - da wächst wenigstens noch was.

Die sogenannten pSSD-Festplatten sollen in den Größen 8, 16, 32 und 64 GB erhältlich sein und SATA-Schnittstellen haben, damit sie herkömmliche Festplatten ohne Probleme ersetzen können.

Laut Sandisk kommt bei der Technologie, die für die neuen SSDs verwendet wird, eine patentierte All Bit Line (ABL)-Architektur zum Einsatz, die mit proprietären Programmierungsalgorithmen und Multi-Level-Data-Storage-Management dafür Sorge tragen soll, dass Performance und Verlässlichkeit nicht auf der Strecke bleiben.

Die neuen SSDs befinden sich in Japan bereits in der Produktion - dabei ist Toshiba als Partner beteiligt.

Auf den Markt kommen sollen die Festplatten im Februar, und offenbar hat Sandisk dafür schon eine Kampagne geplant - versprochen wird jedenfalls eine “aggressive Preispolitik”, was die SSD-Preise ja vielleicht endlich weiter nach unten treibt. [gk]

The Inquirer UK

Bestimmt so lahme Büchsen wieder.. aber billigst.... und lahm...
>200MB/s Stories wären mir bei weitem lieber, ich kann die ganzen billigen Krücken nicht mehr sehen.

 

[DoubleJ]

@glare Hotlink entfernen (1. Bild)

 

[WiTell]

@ssdfix,
ich rede mit keinem Wort von Mtron, sondern von SLC-SSDs im allgemeinen, so wie ich von MLC im allgemeinen rede.
Was mich innerlich so nervt ist, das man mir diese Testergebnisse nicht glaubt, obwohl wir mehr als 1000 SSD im Einsatz haben, aber anderen die nur ein einziges in ihrem Rechner benutzen jeden Benchmark abnimmt. Das ist das was mich so aufregt.

 

[glare]

@glare Hotlink entfernen (1. Bild)

Done. Wußte nicht, dass das nicht erlaubt ist.

 

[SiggiUA]

Ich wollte keine Diskussion MLC versus SLC lostreten. Fakt ist, dass egal wie schlecht oder gut der Flash Speicher einer SSD ist, sie keine falschen Daten liefern darf, sondern einen Fehler melden muss. Es gibt dafür nicht nur einen ECC (Error Correction Code), sondern dieser fungiert auch als EDC (Error Detection Code). Das Liefern von falschen Daten ist schlicht und ergreifend ein Bug (wohl meist in der Firmware). Dieser kann nur unter bestimmten Betriebsbedingungen auftreten und daher schwer reproduzierbar sein. (Die Firmware einer SSD ist alles andere als trivial, wir stehen noch vergleichsweise am Anfang der Entwicklung, was Fehler noch wahrscheinlicher macht). Der von mir zitierte Artikel behauptet, es gäbe solche Bugs, kann sie aber leider nicht benennen. Wie ist es hier im Forum mit derartigen Erfahrungen? Ist WiTell der einzige (der ja leider hier nicht Ross und Reiter nennen kann) der solches berichten kann? Wie war es bei den Usern, die defekte SSDs hatten? Waren sie schlicht tot oder haben sie falsche Daten geliefert und es gab keinen Eintrag im Event-Logging und keine Fehlermeldung? Gab es z.B. Fehler in verschlüsselten Dateien (diese konnten nicht mehr entschlüsselt werden)? Gab es korrupte ZIP Archiven (fehlgeschlagene CRC Prüfung)? Selbst in gewöhnlichen Textdateien würde man Verfälschungen bemerken können (enthalten sie Source-Code, so compiliert dieser für gewöhnlich nicht). .NET Framework Anwendungen sind mit einem Hash signiert, jede Änderung einer solchen ausführbaren Datei würde gemeldet werden. Wenn also jemand solche bemerkt hat, aber keine Fehlermeldung von der Disk erhalten hat, so würde mich das sehr interessieren.

Gruß
Siggi

 

[RunnY]

gskill titan:
BILD[IMG]
intel x25-m:
[IMG]BILD[IMG]
Transcend 32GB JMicron B Controller
[IMG]BILD[IMG]

Randomwrite-technisch hat sich dort nicht viel getan bei der gskill titan.[/QUOTE]

Sanic hat mit den 32GB Transcends (JMircon B Cotroller) und dem ICH10R(korrigier mich wenn ich falsch liege), diese Werte erreicht: [URL="http://www.forumdeluxx.de/forum/showpost.php?p=10999178&postcount=2115"]Link ![/URL]
Also deulich über den Werten aus deinem verlinktem Bild

 

[schnurri]

@WiTell: Wir hätten gern ein Scenario mit PC-Hardware und Linux/Mac/Win OS, mit dem wir deine MLC Probleme nachvollziehen können. Solange es nur mit unbekannter Software (OS + Appli) auf unbekannter Hardware auftritt, wird kaum jemand es glauben. Wenn es tatsächlich ein prinzipielles Problem aller aktuellen MLC SSDs ist, muß man es auch auf dem eigenen PC mit einer Testsoftware nachvollziehen können.

 

[RunDLL]

Was mich innerlich so nervt ist, das man mir diese Testergebnisse nicht glaubt, obwohl wir mehr als 1000 SSD im Einsatz haben, aber anderen die nur ein einziges in ihrem Rechner benutzen jeden Benchmark abnimmt. Das ist das was mich so aufregt.

Nur weil die schreiben die dir nicht glauben, heißt es nicht dass keiner dir glaubt!

 

[glare]

Sanic hat mit den 32GB Transcends (JMircon B Cotroller) und dem ICH10R(korrigier mich wenn ich falsch liege), diese Werte erreicht: Link !
Also deulich über den Werten aus deinem verlinktem Bild

Danke für den Hinweis(habs jetzt korrigiert im Posting), hatte ausversehen die alte A Rev. verlinkt gehabt,
trotzdem bleiben die Randomwrite Werte bei 4KB auf einem ziemlich miesen Niveau.

 

[aquamaler]

mich hat witell überzeugt.
wenn ich mir eine ssd kaufe, dann eine slc .

 

[wolf-cottbus]

... Wie ist es hier im Forum mit derartigen Erfahrungen? Ist WiTell der einzige (der ja leider hier nicht Ross und Reiter nennen kann) der solches berichten kann? Wie war es bei den Usern, die defekte SSDs hatten? Waren sie schlicht tot oder haben sie falsche Daten geliefert und es gab keinen Eintrag im Event-Logging und keine Fehlermeldung? Gab es z.B. Fehler in verschlüsselten Dateien (diese konnten nicht mehr entschlüsselt werden)? Gab es korrupte ZIP Archiven (fehlgeschlagene CRC Prüfung)? Selbst in gewöhnlichen Textdateien würde man Verfälschungen bemerken können (enthalten sie Source-Code, so compiliert dieser für gewöhnlich nicht). .NET Framework Anwendungen sind mit einem Hash signiert, jede Änderung einer solchen ausführbaren Datei würde gemeldet werden. Wenn also jemand solche bemerkt hat, aber keine Fehlermeldung von der Disk erhalten hat, so würde mich das sehr interessieren.

Gruß
Siggi

Hier ich hatte mit meiner oder besser auf meiner Supertalent korrupte ZIP Archive. Auch SpielePatch als exe datei waren nicht mehr ausführbar.
Nicht gleich am Anfag kamen die Fehler. Natürlich waren die dann auch im Backup, also auch unbrauchbar.
Hatte ich auch schon mal hier geschrieben.
In Moment geht es wieder, ich teste jetzt aber jede Woche die Daten.

Gruß Wolf

 

[DjAcid]

und wie testest du die?

 

[Morpog]

Meine OCZ Core im Netbook hat Datenkorruption wenn sie mit AHCI betrieben wird. Mit IDE gibts keinerlei Probleme.

 

[Hypocrisy]

So, ich habe jetzt mal ein paar Minuten investiert und gebencht. Es ist jeweils nur der erste Durchlauf, da ich nur ganz wenig Zeit habe, aber je einmal mit und ohne Rückschreibcache.

Von HDTach habe ich erstmal keine Version für Vista64 gefunden. Werde morgen mal nen Kompa-Modus für XP versuchen. Da meine Freundin Geburtstag hat, gewinnt sie heute gegen den PC. Ich bin dann morgen wieder da.

 

[sanic]

also ich weiß nicht

entweder nen controller für MLC SSDs ca. 340 Euro

oder

3x MTRON MOBI-SATA-3525 16/32GB mit onboard