Test SSD-Controller im Test: Mushkin Europe 2 gegen Corsair P128

[weissbrot]

@eggi verdammt interessante geschichte - auch wenn ich grad schon ein wenig zu müde bin dafür.

Das heißt, dass die interne Blockgröße doch auch Einfluss auf die Performance in unterschiedlichen Bereichen hat. Sprich hat man eine kleine blockgröße, wie 64k muss man immer die 64k auslesen, was dann auf kosten der performance bei großen dateien gehen könnte. weil dann viel mehr blöcke ausgelesen werden müssen. Hat man eine zu große Blockgröße würde das Einfluss auf die Performance bei kleinen Dateien haben?

Da wäre mal ein Test interessant, wie sich das nun tatsächlich auswirkt. Ich mein Moros hat auch immer gemeint es is egal - hauptsache es sind ned die 63k von xp

Keine Ahnung ob ich das richtig verstanden haben *gg*

jetzt fällt mir doch noch was ein:
Sprich wenn ich 1024k Blockgröße habe und lauter 4-10K dinger haben will, die aber nicht im selben block sind, hab ich schnell mal meine 128mb cache voll -> weil ja immer der ganze Block geladen wird?

das is so weired ... aber ich denke mal dass das alles in der Praxis kaum einen Unterschied machen wird. Weil man kann nie wirklich sagen ob man nun viel oder wenig tatsächlich sequentielle read/writes hat..

so i geh dann mal pennen... wünsch euch nen schönen guten morgen... bin dann in ca 9h wieder da (bzw im büro )

 

[Attila265]

Warum sollte man einer der beiden SSDs kaufen wenn man eine viel Leistungsfähigere Intel Postville für vergleichbare Preise erhält ? (IOs, Random Werte)

Außerdem finde ich es blödsinn aktuelle SSDs mit herkömmlichen Festplatten zu vergleichen.
Jeder der etwas Ahnung von derThematik hat oder sich mit dem Thema beschäftigt weiß das konventionelle Festplatten hinsichtlich der Leistung absolut nicht zu vergleichen sind.

 

[Moros]

Die Intel ist beim Schreiben, Kopieren, Entpacken und z.T. Installieren schlechter als die Indilinx und Samsung SSDs. Außerdem ist sie nicht für unter 185€ zu bekommen.
Wenn das Budget knapp ist oder 64GB reichen oder häufig die eben beschriebenen Szenarien auftreten, sind Indilinx und Samsung eine gute Wahl.

Warum sollte der Vergleich mit Festplatten "Blödsinn" sein? Es geht hier um den Vergleich von Systemplatten und da lassen sich SSDs und HDDs hervorrangend vergleichen.

 

[weissbrot]

@attila du weisst aber schon dass etwa 95% der leute die hier auf die startseite kommen keinen Tau von SSDs haben - und für die dürfte das schon eine gute Informationsquelle sein!

@moros - echt? die intel is bei installationen langsamer? da will ich werte sehen nimmst du photoshop / office installationen auch in den test auf oder ned?

 

[Eggcake]

Warum sollte man einer der beiden SSDs kaufen wenn man eine viel Leistungsfähigere Intel Postville für vergleichbare Preise erhält ? (IOs, Random Werte)

Außerdem finde ich es blödsinn aktuelle SSDs mit herkömmlichen Festplatten zu vergleichen.
Jeder der etwas Ahnung von derThematik hat oder sich mit dem Thema beschäftigt weiß das konventionelle Festplatten hinsichtlich der Leistung absolut nicht zu vergleichen sind.

Der Vergleich ist überhaupt nicht Blödsinn, da wohl 90% der User von einer HDD mit 7200RPM wechseln würden, daher interessiert es die am meisten wieviel sie gegenüber HDDs profitieren. Wenn ich mich hier im Forum so umsehe gibt's ausserdem nach wie vor sehr viele Leute, die der Meinung sind eine SSD bringe kaum Performance. Von daher: immer schön weiter HDDs mit reinnehmen...

Die Postville ist in gewissen Bereichen besser, in anderen jedoch auch schlechter.

 

[Sunshine_10]

Wieso man die nicht vergleichen sollte verstehe ich auch nicht ... Preis fällt, Leistung steigt und der Platz ist wie gesagt das kleinste Problem derzeit.

 

[Eggcake]

Weitere Ausführungen von Icerbag:

Yeah, that is basically correct. The exact details depend on tons of factors so it may or may not be true in some particular case, but most OSes try to use temporal locality (things being written close together in time) and namespace locality (whether thing are in the same folder) as hints the items are likely to be used together and should be stored close together on a disk.

The drive is internally remapping everything around because of the constraints flash imposes, but does the same thing, using temporal locality the same way as the FS, and using logical locality (the address ranges on the drive that the OS chose) to try to figure out what to shove together into various flash blocks, and when to write data out to clean block as opposed to when to tack it on to the end of partially dirty blocks.

Das heisst auch eine SSD ordnet Dateien etwas dem Namen und der Zeit des Requests, ganz ähnlich wie das z.B. bei HDDs auch der Fall ist. Sicher kann man sich nicht sein, es kann auch per Zufall "nebeneinander" liegen, obwohl's zeitlich viel später geschrieben wurde.
Auf gut deutsch: um Random Reads in der Praxis hervorzurufen müssen Daten in verschiedenen Directories die zu verschiedenen Zeitpunkten geschrieben wurden geladen werden.

 

[weissbrot]

super eggi - versorg uns weiter mit solchen infos! verdammt interessant.
Sprich in Wahrheit kann man nie wirklich sagen ob man nun tatsächlich nen random read hat, weil man auf den controller keinen einfluss hat...

 

[Eggcake]

Doch eben schon

Also mit Sicherheit kann man's nicht sagen, aber die Wahrscheinlichkeit einen sequenziellen Read zu haben ist in einem ähnlichen Directory, das am besten noch zu einer ähnlichen Zeit geschrieben wurde viel höher, als wenn ein Directory an einem komplett anderen Ort, welches zu einer komplett anderen Zeit geschrieben wurde. Aber ja - ganz sicher kann man dabei nicht sein, weil man nicht weiss welchen Einfluss die derzeitige GC- und WL-Algorithmen haben.

Aber wenn ich Random Reads in der Praxis testen will ist es sicherlich keine gscheite Idee einfach 1000 Daten in einen Ordner zu knallen und alle nacheinander zu lesen. Das ist dann ziemlich sicher sequenziell. Es ist also ganz ähnlich wie bei einer (defragmentierten) HDD. Dasselbe gilt für Random Writes.

Edit: Achja, "Yeah, that's basically correct" kam als Antwort auf die Behauptung von mir, dass die Daten eines Programmes, welches in einen Ordner installiert werden auch bei SSDs "nahe" beieinander sind und die Daten eines zweiten Programms, welches später in einen anderen Ordner installiert werden an einem anderen Ort, aber ebenfalls "nahe" beieinander sind. Er lieferte im Prinzip noch die Erklärung dafür und wies eben darauf hin, dass bei SSDs halt noch div. Algorithmen dazwischenfunken können.

 

[Daniel#]

Ja Moros hast du noch eine Antwort auf meine Fragen?

MfG

 

[weissbrot]

ja hab schon verstanden eggi - mit wahrscheinlichen random reads kann man halt schwer konkrete aussagen treffen *gg*

 

[Moros]

@Moros:
1.Ich kenne die SSD Anthology auf Anandtech und die Folgeartikel, die habe ich aber noch nie ganz gelesen weil sie einfach viel zu lang und in recht anspruchsvollem Englisch geschrieben sind. Obwohl ich recht gute Englischkenntnisse habe sind die Artikel bie Anandtech doch schon schwer zu verstehen.

Ich stimme dir zu, dass die Artikel auf Anand z.T. ein sehr gutes Englisch und hohe Vorkenntnisse erfordern, aber der TRIM-Teil ist v.a. durch die unterstützenden Bilder relativ einfach zu verstehen:
http://www.anandtech.com/storage/showdoc.aspx?i=3531&p=10

2. Ich finde den Abschnitt "Performanceverlust" irgendwie konfus und wirr, vor allem was es mit den "Blöcken" und "Einheiten" auf sich hat???

Vielleicht sollte ich noch mal einen Artikel nur zu diesem Thema machen, mit theoretischer Herleitung, Praxistests usw.
Das wird aber frühestens in 3-6 Wochen was.

3. Wie kann HDDErase denn das Wear Levelling des Controllers umgehen und die ganze SSD löschen?

4. Sind einmalig gelöschte Flashzellen garantiert nicht wieder rekonstruierbar?

Dazu hat Eggcake ja schon einiges geschrieben. Ansonsten schau dir mal an, wie HDDErase funktioniert. Ich bin mir zu 99% sicher, dass nach HDDErase keinerlei Daten mehr rekonstruierbar sind.

 

[cerko]

Sprich in Wahrheit kann man nie wirklich sagen ob man nun tatsächlich nen random read hat, weil man auf den controller keinen einfluss hat...

Also mit Sicherheit kann man's nicht sagen, aber ....

Man kann auch mit Sicherheit nicht sagen, dass man gerade einen sequentiellen Read hat. Von daher ist es schon wichtig ob die Festplatte/SSD im Random Read schnell ist.
Nur ist es schon schwierig sowas in der Praxis zu testen

 

[Tekpoint]

Hier mal ein Test von zwei Mushkin in Raid 0

http://www.hartware.de/review_978_11.html

 

[Daniel#]

Hmm ich hab versucht mich über HDDErase schlau zu machen, denn es soll ja den "secure erase command" der ATA Firmware nutzen die seit 2001 in allen Festplatten ist, nur hab ich nirgends was genaues zu diesem "secure erase command" gefunden.

Und was ist dann der Unterschied zu herkömmlichen "Secure Erase Tools", die ja alles überschreiben?!

Wenn dieser "secure erase command" in der ATA Schnittstelle SSDs sicher löschen kann, warum benutzen dann die Programme für "normale Festplatten" nicht diesen command sondern überschreiben die ganze Platte?
Und auch alle "zertifizierten" Methoden zur sicheren Datenlöschung basieren ja auch auf das komplette überschreiben...

MfG

EDIT:
Das einzige etwas aufschlussreiche ist das hier, obwohl auch nicht erklärt wird wie es gemacht wird.

 

[Eggcake]

Weil diese Methoden bei HDDs nötig sind. Wenn man bei HDDs einen Sektor 1x überschreibt, ist er nach wie vor potenziell wiederherstellbar, da aus der Magnetladung der vorherige Zustand rekonstruiert werden kann. Genauer kann ich's dir auch nicht erklären - es soll aber theoretisch möglich sein.
Bei SSDs ist dies nicht der Fall. Zelle erased = Zelle erased, nix Restladung.

 

[Daniel#]

Sehr interessant...
Ich habe jetzt doch genaueres gefunden:
Hier ist ein Artikel darüber:
klick
und Hier die Offizielle Seite vom "Center for Magnetic Recording Research":
klick
und hier noch eine Anleitung aus dem ATA Wiki:
klick

Laut dem Artikel von storagesecrets und der pdf dokumentation von CMRR ist der "Secure Erase Command" sicherer als normales block-überschreiben, und das sicherste vor der kompletten physikalischen Zerstörung.

Anscheinend ist der "Secure Erase Command" schneller und besser als das "normale überschreiben"...

MfG

EDIT:
Ihr "Sponsor" war die NSA (National Security Agency), aber sie haben jetz kein Support Team mehr, steht am Anfang in der Readme.

 

[Dähn]

Hallo,
ersteinmal vielen Dank für die Mühe und den Aufwand Moros, immerhin ist das ja nicht deine einzige Beschäftigung!

Daniel0711 muss(te) ich aber auch in Bezug auf diesen Absatz zustimmen:

Ja, es gibt ihn, den Leistungsabfall bei aktuellen SSDs wie unseren beiden Testkandidaten. Dieser kommt u.a. dadurch zu Stande, dass SSDs zwar in Einheiten von normalerweise 4 Kilobyte lesen und schreiben können, das erneute Beschreiben aber in Blöcken erfolgen muss. Die Größe dieser Blöcke kann von wenigen MB bis zu einem Gigabyte variieren. Wenn eine Datei in solch' einem Block geändert werden soll, muss erst der gesamte Inhalt in den Cache bzw. RAM geladen werden, dann wird der Block komplett gelöscht und neu beschrieben. Das dauert natürlich etwas länger als das erstmalige Schreiben. Hinzu kommt, dass Dateien, die unter Windows gelöscht werden, nicht auf der SSD verschwinden (eine generelle Eigenart des Windows-Dateisystems). Das führt dazu, dass beim Schreiben auf die SSD jene Blöcke, die neu beschrieben werden sollen, erst gelöscht werden müssen, was ebenfalls zu Verzögerungen führt.

Der war beim erstmaligen Durchlesen für mich unverständlich (habe mich aber auch vorher noch nie mit SSDs und deren interner Arbeitsweise beschäftigt), nachdem ich dem Link weiter unten zum OCZ-Vertex-Test und dem TRIM-Kommando gefolgt bin, glaube ich was verstanden zu haben.
Trotzdem nochmal ein paar Fragen:

a) Das "erneute Beschreiben" aus dem oben zitierten Absatz bezieht sich auf schon einmal beschriebene Zellen (heißt das so?) der SSD, die zwar vom Betriebssystem als vermeintlich leer angezeigt werden, die Dateien darin faktisch aber nur vom "Inhaltsverzeichnis" gelöscht worden sind und trotzdem noch existieren.
Um nun aber eine neue Datei in jene Zellen speichern zu können reicht es (im Gegensatz zu Festplatten?) nicht einfach aus diese zu "überschreiben", sondern die alten Daten müssen zunächst explizit gelöscht werden um dann einen neuen Schreibvorgang durchführen zu können?
Das kostet mehr Zeit als bei "brandneuen" Zellen und verursacht einen Performanceverlust?

b) Dieses Verhalten tritt nur bei Windows auf (bzw. dem verwendeten NTFS-Dateisystem) und nicht etwa bei ext2/3/whatever bei bspw. Linux?

c) Erschwerend kommt noch hinzu dass nicht einfach nur die betroffenen Zellen (mögen es nur einige MB sein) gelöscht und wieder beschrieben werden müssen, sondern ein ganzer Block großen Ausmaßes (bis zu 1 GB?) der den Zeitaufwand entsprechend vervielfacht?

Ausgehend von diesem Textverständnis (bitte korrigiert mich, wenn ich da was durcheinander geworfen habe) stellt sich mir die Frage:

d) Warum werden bei Windows (oder [entspr. Frage b] Linux) nicht direkt beim Löschen die entsprechenden Zellen geleert? Das würde doch beim Schreiben die Unterscheidung zwischen "echten", neuen leeren Zellen und schon beschriebenen Zellen überflüssig machen und Zeit sparen.

e) Warum muss die SSD in solchen großen Blöcken wieder schreiben? Ist es nicht einfach möglich die Zelle direkt anzusteuern?

Vielen Dank schonmal und gute Nacht

 

[Eggcake]

Explizite Zahlen sind im folgenden an Indilinxdrives angelehnt, sind aber bei anderen SSDs sehr ähnlich.

Zu a)

Du hast es eigentlich erfasst, nur eine Kleinigkeit nicht erwähnt (bzw. bei c nachgeholt, aber ich will das doch nochmals festhalten, da es nicht eine "Kleinigkeit" ist sondern das Ausmass dieses Problems erst durch diesen Fakt so entsteht) : eine SSD wird mit pages von 4kb beschrieben. 128 solcher pages ergeben einen block. Gelesen werden können ebenfalls 4kb. Und jetzt folgt das eigentliche Problem: gelöscht werden kann jeweils nur ein ganzer Block von (in diesem Fall) 512kb. Das heisst wenn eine page geschrieben werden will, diese jedoch bereits beschrieben wurde, jedoch ungültig ist (also Daten enthält die im filesystem bereits gelöscht wurden) muss der gesamte 512kb block gelesen und in den Cache geschrieben werden, ungültige pages gelöscht werden und mitsamt den neuen daten erneut geschrieben werden.

b) Das Verhalten tritt eigentlich bei so gut wie allen gängigen OSes auf. Welche FS genau ausgeschlossen sind, weiss ich jetzt nicht - auf jeden Fall besteht das Problem auch sowohl bei Linux als auch bei Mac OS X.

c) siehe a)

d) Bisher war sowas schlicht nicht notwendig. Dies wird jedoch eben mit dem viel genannten TRIM-Command nach ATA-Spec eingeführt. Das OS erhält mit diesem Kommando die Möglichkeit einem Speichermedium mitzuteilen welche logischen Sektoren gelöscht werden können.

e) Zu dieser Frage habe ich grad keine Antwort parat, da müsste man sich wohl etwas in die NAND-Flashtechnologie einlesen...


Aber im grossen und ganzen hast du eigentlich alles richtig verstanden, denke ich

 

[Dähn]

Vielen Dank Eggcake, und wieder was gelernt (sogar zu später Stunde)
Eigentlich ist alle klar, nur noch mal sicherheitshalber nachgefragt:

d) Und das ist die Geschichte die ab Windows 7 ein manuelles Ausführen eines Tools überflüssig machen soll? Damit dürfte sich die ganze Geschichte ja erledigt haben, die SSDs würden dann ihre Leistung konstant behalten, dafür muss dann ein kleiner Mehraufwand in Form von Zeit beim Löschen in Kauf genommen werden?

Tschüs