Nächste(r) SSD-Test(s) - Was wollt ihr sehen?

[Merlin-.-]

Die einfachste Erklärung ist, dass anandtech das nicht weiß, weil sie nicht so viele und nicht so systematisch Praxistests durchgeführt haben...!?

 

[Moros]

Aber er benutzt Studien des IBM Research Institutes in Zürich? Naja, ich sollte mich unbedingt mal mit dem Mann unterhalten

 

[HisN]

@Moros
Ich seh gerade Du bist in Berlin, ich kann Dir gerne zum Testen für ne Stunde mein Acard9010 vorbeibringen^^. Oder sind nur Flash-SSDs gefragt?

 

[Eggcake]

Ja - bin jetzt fertig und ich finde den gesamten Artikel etwas naja...doch nicht wirklich aussagekräftig. Zumindest komme ich auch auf komplett andere Resultate - eine G2 soll keine/kaum Performance verlieren im Random Write - das stimmt einfach nicht...einerseits behauptet er, sie verliere keine Performance, andererseits sagt er auch, dass sie stärker einbricht bei stärkerer Beschreibung - irgendwie ein Widerspruch. Zudem fehlt mir eben doch die Aussagekraft der Tests. PCMark Vantage ist eigentlich das einzige, was wirklich getestet wurde und einige Synth Benches. Ansonsten hats wenig, was mich wirklich interessiert...

Zu guter letzt: man merkt deutlich, wer sein Sponsor ist

Die Einführung ist aber gut & verständlich, die ist sehr gut - nur nimmt die Aussagekraft des Artikels immer weiter ab, je weiter man liest :/

 

[Moros]

Die SuperTalent SSD(s) hat er in der Preisübersicht einfach vergessen

Ergänzung (31. August 2009)

@HisN
Geiles Teil.

 

[Eggcake]

Jop, ist mir auch aufgefallen - sonst könnte er ja auch keine Empfehlung für die Agility als "Preiskracher" ausgeben

Edit: Irgendwie witzig - den letzten Artikel von ihm habe ich noch hochgelobt - je mehr man sich aber selbst mit der Materie beschäftigt, desto mehr Ungereimtheiten fallen einem auf.

 

[Merlin-.-]

M.E. vernichtet Eggcakes "Postville Praxistest" die "Studien", die ich bisher gesehen hab zum Thema SSD.
Ich erinnere nur an die Methode, bei Spielen die Ladezeit bis zum Hauptmenü zu messen in der einen Studie... lol

 

[Eggcake]

Ich meine - auch Anand hat ja selbst den Test gemacht mit WoW, PS und FF nach dem Start - die Indilinx waren bei ihm wohl gleichschnell. Beim Photoshoptest stinkt die Intel ab.
Zum Schluss ist die Intel trotzdem am besten, weil er sein Fazit scheinbar nur auf den Synth. Benches und PCMark aufbaut.

Imho ist die Intel bei gewissen Applikationen auch messbar schneller, aber trotzdem sollte man sein Fazit nach den Resultaten seiner eigenen Tests halten und nicht nach den zu erwartenden o.ä...und es zeigt deutlich, wo sein Augenmerk liegt: nämlich eben in Synth. Benches. Beim letzten Test bzw. auch beim Test der alten Intel haben mir die Praxistests extrem gefallen, weshalb ich einige auch ähnlich wiederholt habe/modifiziert habe (Virenscan + Appstart z.B.), davon fehlt jetzt jede Spur...

 

[Moros]

Vertex mit 120 GB ist jetzt auch noch auf dem Weg für den Test. Ich will aber unbedingt noch eine Samsung und eine Indilinx mit 60 GB reinnehmen, die kann mir bloß keiner geben und meine eigene brauch ich eben...im Notfall wird am Ende die Partition auf eine andere SSD kopiert...mal sehen.

Zum eigentlichen Test:
Ich wollte für alle Tests zwei Szenarien verwenden:
1) HDDErase -> Image drauf kopieren -> Idle/Wiper -> Tests
2) mit IOMeter voll schreiben -> Image drauf kopieren -> Idle/Wiper -> Tests

Einwände oder Ergänzungen?

 

[Eggcake]

Wie schreibst du mit IOMeter eigentlich voll? Einfach übers gesamte Laufwerk Random Writes und paar Stunden warten?
Wollte das auch mal machen, aber hat nicht so gefruchtet

 

[Moros]

Ich nehm immer den Random Read Test (mit Partition) über das ganze Laufwerk. Um auf das gesamte Laufwerk auf Random Read testen zu können, schreibt IOMeter erst die gesamte SSD voll. Alternativ kann man natürlich auch große Dateien Kopieren und auf die SSD schreiben. Ich hab das z.B. mit dem Win7 RC Image gemacht. Einfach 10mal parallel auf die SSD kopieren/schreiben bis sie voll ist

 

[balla balla]

@Moros
Ich glaube seriell geht schneller als parallel (auch bei SSDs), oder?
Warum nimmst Du nicht einfach die Dummy-Dateien?

So, habe das 7Zip Archiv überarbeitet und die Dateien auf 50000 reduziert (die Schnapszahl vorher war übrigens Zufall),
der Inhalt ist jetzt 4,89GB groß und das doppelt 7Zipte Archiv hat nur noch 34kb.

Have Fun

PS:@mumpel
Geh ins Freibad, entspann Dich, mach Dir keinen Kopf, wir werden für jede Lösung das passende Problem finden.

 

[mumpel]

Ich meine - auch Anand hat ja selbst den Test gemacht mit WoW, PS und FF nach dem Start - die Indilinx waren bei ihm wohl gleichschnell. Beim Photoshoptest stinkt die Intel ab.
Zum Schluss ist die Intel trotzdem am besten, weil er sein Fazit scheinbar nur auf den Synth. Benches und PCMark aufbaut.

Muss nicht sein. Die Intel hat nun mal einen Mörder-Read und der Write ist bei kleine Dateien auch um Welten besser, als Indilinx. Seq. Write hin oder her ... für ein OS- oder alleinige SSD sind das die entscheidenden Kriterien. Außerdem hat er das Firmware-Hickhack bei Indilinx auch nicht gut gefunden. Kann ich absolut nachvollziehen und war auch mein Grund Pro Intel. Naja, und dann noch der Einbruch, bzw. der Nicht-Einbruch der Performance. Was willst du mehr? Und er sagt ja auch ganz klar, dass die Indilinx ganz dicht nach der Intel kommen und wenn's um's reine Preis/Leistungsverhältnis geht, dann ist die Indilinx die bessere Wahl.

Und dass das man gesponsert ist, glaub ich nicht. Schließlich steht er anscheinend im engeren Kontakt zu OCZ, als zu Intel. Und dass eure ST nicht extra genannt wird, ist auch nicht schlimm, weil ST einfach eine sehr kleine Firma ist. Und ob nun ST oder OCZ ... ist doch egal und das gleiche.

Grundsätzlich dürfte aber keinen einen Grund haben, sich groß zu beschweren. Der Typ nimmt sich einfach Zeit, die Sachen zu testen und schmeißt keinen Schnelltest zu den SSDs raus, bloß weil sie gerade auf den Markt kommen. Er fummelt so lange rum, bis er weiß, bis er versteht, was er da gemessen hat. Und das kann er dann auch noch halbwegs verständlich kommunizieren. Weiß gar nicht, wo's für euch Punkte gibt, hier rumzumaulen Viel schlimmer finde ich, dass Intel für die G1 kein TRIM rausbringen will! Und dass die Samsung so ein Reinfall ist


@ balla balla:
Hab schon eine: Nimm einfach ein paar große Programm-Installationen + Windows + ein ein paar Dokumente, Bilder, Audio, Filme und arbeite damit. Daten aus der Praxis sind per Definition besser als komplett synthetisch erzeugte Dateien. Das ist ein bisschen so, als wenn man das Reaktionsverhalten von Menschen testen will und sich dafür ein paar künstliche erzeugt. Versteh den Aufwand einfach nicht ... Selbst wenn es die Praxis 1:1 nachbildet, musst du eh erst beweisen, dass es die Praxis 1:1 abbildet.

 

[HisN]

@HisN
Geiles Teil.

War das jetzt: "Komm zum testen vorbei" oder eher "passt nicht mit rein"? *G*

 

[Moros]

@mumpel
Die Dummy-Dateien haben meiner Meinung nach zwei große Vorteile:
1) Sie verändern sich nicht. Das kann bei mehreren Programmordnern schon mal ohne gezielte Aktionen von allein passieren, auch ohne Netzwerkverbindung.
2) Jeder kann sie ausprobieren. Das ist wohl der entscheidende Faktor. Jeder Leser kann sich die Dummy-Dateien nehmen und diese mit seiner SSD testen. Das finde ich nicht schlecht.

Siehst du denn bei der Verwendung der Dummy-Dateien einen Nachteil, wodurch das Ergebnis verfälscht werden könnte? Ich könnte mir höchstens vorstellen, dass die Dummys nicht fragmentiert auf der SSD liegen und das ganze deshalb etwas schneller geht bzw. ein minimal anderes Ergebnis zu zufällig verteilten Daten wie Programmordnern oder C:/Windows erreicht wird.
Da stellt sich aber auch wieder die Frage, ob es ein reales Szenario gibt (also regelmäßig von vielen Usern praktiziert), welches eine große Menge zufällig verteilter bzw. fragmentierter Daten, bzw. das Kopieren derselben, beinhaltet.

@HisN
Leider letzteres

Grundsätzlich sind RAM-Drives ein spannendes Thema, aber es passt weder zeitlich noch inhaltlich zum nächsten Test.

Der nächste Test soll ganz unter dem Motto stehen: "Was kann ein User von einer erschwinglichen SSD erwarten (60-120 GB) und wie groß sind die realen Unterschiede."

 

[mumpel]

@ Moros:
1. Ich meine, man sucht sich einmal die Dateien zusammen (kopiert sie sich in einen Ordner) und verwendet das zum Testen. Dann ändern sich die Daten auch nicht. Es kann ja auch was weiß ich drin sein. Ist ja egal. Einfach ein bunter Haufen, aller möglicher Dateitypen und -Größen.

2. Vergleichbarkeit ist richtig. Die Frage ist nur, inwieweit jemand das macht, bzw. dass es DAS Kriterium ist? IMO geht es nur um Vergleichswerte für die SSD-Tests hier von Dir. Ein anderes System, mit anderer CPU, anderem Controller, anderem Füllstand ... lässt die Werte eh variieren. Es geht nur darum, dass du die immer gleiche Methode und Daten benutzt.

Was ich als Nachteil sehe, hab ich schon formuliert:

Mein größtes Problem damit sind die exakten Blockgrößen und die gleichen Inhalte. Das kann ggf. ein guter Cache-Algorithmus erkennen. Und die exakten Blockgrößen könnten die Performance (positiv) beeinträchtigen, weil die Pages komplett geschrieben werden können. Bei 82 KB braucht man z.B. 1,5 Blöcke, statt genau 1 oder 2. Das heißt, um den halben Block nachträglich zu beschreiben, muss man erst den anderen lesen und mit dem neuen zusammen schreiben. Das ist ein ganz anderes Bild als klinisch saubere Dateien zu schreiben.

Und natürlich die Angreifbarkeit des Tests durch synthetische Daten:

Daten aus der Praxis sind per Definition besser als komplett synthetisch erzeugte Dateien. Das ist ein bisschen so, als wenn man das Reaktionsverhalten von Menschen testen will und sich dafür ein paar künstliche erzeugt. Versteh den Aufwand einfach nicht ... Selbst wenn es die Praxis 1:1 nachbildet, musst du eh erst beweisen, dass es die Praxis 1:1 abbildet.

Da stellt sich aber auch wieder die Frage, ob es ein reales Szenario gibt (also regelmäßig von vielen Usern praktiziert), welches eine große Menge zufällig verteilter bzw. fragmentierter Daten, bzw. das Kopieren derselben, beinhaltet.

IMO wäre es sowieso angebracht, die Daten beim ersten Mal kopieren zu benchen (auf die neue SSD) und dann so lange, bis die SSD voll ist. Dann wieder ein paar Kopien und einzelne Verzeichnisse aus den Kopien löschen (so dass die SSD schön fragmentiert ist), um dann im letzten Durchgang, wieder das Kopieren auf eine fragmentierte SSD zu benchen. Man könnte auch mehrere Kopien gleichzeitig starten.

Der Vorteil ist, dass ständig unterschiedlich große Dateien geschrieben werden. Dadurch schwangt der Speed schön zwischen kleinen und großen Dateien. Die künstlichen Daten sind ja alle in exakter Bytegröße hintereinander und nicht gemischt. Im Anandtech-Artikel sieht man ja sehr schön, wie die Controller funktionieren. Eine große Datei wird auf 4 Controller aufgesplittet und gleichzeitig geschrieben. 4 kleine Dateien werden gesammelt und dann zusammen auf die 4 Controller-Channel verteilt. Was ist jetzt aber, wenn mal eine 5 Byte-Datei kommt, dananach eine 6 KB-Datei, dann eine 2 MB, vier 12 kb, dann wieder eine mit 750 Byte ... ? Auch würde eine zufällige Wahl von Dateien der Installationen mehr das Verhältnis zwischen kleinen und großen Dateien in der Realität widerspiegeln. So wie ich das auf den Screenshots von balla balla sehe, sind von jeder relevanten Dateigröße die gleiche Anzahl von Dateien da. Das ist ja schon mal nicht realistisch. Die synthetischen Dateien würden wunderbar die abstrahierte Darstellung von Anandtech wiedergeben. Das ist aber nicht die Praxis.

 

[Eggcake]

@Moros

Also dass die iometer-Datei die SSD vollschreibt bezweifle ich. Ich hab das selber getestet und ob IOMeter 30GB schreibt oder ob ich den Windowsordner 4x kopiere ist ein meilenweiter Unterschied. Bin da auch nicht 100%ig sicher, aber als ich used states testen wollte, klappte es mit der IOMeter-Datei überhaupt nicht.

@mumpel (bzgl. Anand)
Mag sein, dass Random Write bei der intel besser ist, doch wie man sieht hat sich das in seinen Praxistests nrigends ausgewirkt. Weder beim direkten Start von 3 Apps nach direkt nach dem Boot nonch sonstwo - ausser eben in synthetischen Tests. Solange Anand mir nicht zeigen kann, dass die hohen Random Writes der Intel in der Praxis auch sichtbar sind, solange bleib ich auch dabei, dass die Random Writes mir nichts bringen. Ich habe nichts dagegen, dass er die Intel empfiehlt - ich empfehle sie auch, da ich sie nach wie vor für am ausgereiftesten und schnellsten halte - nach meinen eigenen Tests. Aber wenn ich nach dem Test von Anand gehe, dann ist die Intel entweder "Nur" gleich schnell wie die Konkurrenz oder langsamer in der Praxis. Von daher verstehe ich einfach nicht, wie Anand auf ein solches Fazit kommt. Er reitet auf den synthetischen Benches herum, sagt die Samsung sei schlecht (erwähnt sie im Fazit nichtmal wirklich) aufgrund der schlechten Random Writes, und in der Praxis ist sie dann doch nicht so schlecht wie sich herausstellt....mir ist sein Test viel zu synthetisch und sein Fazit basiert auch darauf-

Bzgl. hohen Random Reads der Intel:
Was viele immerwieder vergessen: diese Tests werden meist mit hohen Outstanding IOs gemacht. Sei es mit 64 in ASS oder IOMeter (wo die Intel dominiert) oder "nur" mit 3 wie beim jetzigen Test von Anand: in der Praxis kommt man selten über 0 oder 1 Outstanding IO hinaus. Die Intel ist aber bei 0 Outstanding IO schlechter als die Konkurrenz! Das wird immer einfach ignoriert. Meine Intel kommt auf ca. 19 MB/s bei 0 Outstanding IO im 4k Random Read, die Indilinx auf 27. Das sollte endlich mal untersucht werden - denn ich bin mir sicher, dann käme man auch drauf, wieso die scheinbare theoretische Überlegenheit der Intel in der Praxis eher verpufft: weil sie bei 0 Outstanding nicht wirklich besser ist als der Rest.

@mumpel (bzgl. Kopierbenches) :

Ich stimme mit dir insofern überein, als dass ein solcher synthetischer Kopiertest erst "erlaubt" werden sollte, wenn zuvor überprüft wird, ob er tatsächlich auch das genau gleiche Resultat bringt wie bei richtigen Dateien. Das muss imho definitiv vorher getestet werden.

 

[mumpel]

Naja, dass die Random Writes in der Praxis weniger messbar sind, also hohe sequentielle Writes, ist doch auch klar. Sobald ich Dateien über 128 KB schreibe, limitiert die Intel auf 70-80 MB/s. So kleine Dateien kommen zwar häufiger vor, sind aber nicht wenig fühlbar. Ob mein 5-MB-Bild oder meine 15-MB-PDF aber mit 80 oder mit 180 MB/s geschrieben werden schon eher. Und selbst dann: Wenn ich eine 400-MB-Datei auf meine HDD kopiere, dauert das auch nicht so lange (4-6 Sekunden bei ~100 MB/s). Und für viel größere Dateien sind SSDs auch nicht groß genug (um z.B. ständig mit GB-großen Videodateien zu arbeiten) - bzw. ist das nicht der Durchschnittsuser.

Dass heißt, dass die gefühlte Performance bei einer SSD (als OS-Platte) eher durch Leseperformance und IOPS zustande kommt. Und ob nun Indilinx oder Intel wird blind sowieso keiner merken. Das ist nur messbar.

Bezüglich seines Fazit denke ich eher umgekehrt: Aus Gefühl empfiehlt er die Intel, weil ihre Write-Performance in der Praxis egal ist und man dafür "die ausgereifteste" - und schnellste - SSD bekommt. Das kann sein Testsetup aus synthetischen Tests nur bedingt wiedergeben. Ich denke, die "schlechteren" synthetischen Random Read-Werte, gepaart mit dem Firmware-Hickhack, sprechen dann aus seiner Sicht eher gegen die Indilinx. Laut den seinen Test macht die Indilinx aber den runderen Eindruck.

Bezüglich IOPS: IOPS sind doch die Input-Output-Operations pro Sekunde. Also wieviele gleichzeitige Instruktionen die SSD/HDD gleichzeitig verarbeiten kann. Sprich: Je geringer die IOPS, desto eher bricht die Multitasking-Performance ein. Oder? Das würde wiederum bedeuten, dass niedrigem Outstanding IO die "schlechtere" Performance der Indilinx keine Rolle spielt und deshalb in den Praxis-Tests auch nicht messbar ist, weil einfach zu wenig gleichzeitig verarbeitet werden soll. Würde man nochmal gleichzeitig machen, würden die Unterschiede aber größer werden. Oder?

 

[Eggcake]

Nochmals zu Anand, nur um zu zeigen was ich meine mit den Widersprüchen.

The benefit however is that the G2 doesn't drop in performance when used...at all. Yep, you read that right. In the most strenuous case for any SSD, the new G2 doesn't even break a sweat. That's...just...awesome.

Paar Absätze weiter unten:

Because it can more or less rely on being able to TRIM invalid data, the G2 firmware is noticeably different from what's used in the G1. In fact, if we slightly modify the way I tested in the Anthology I can actually get the G1 to outperform the G2 even in PCMark Vantage. In the Anthology, to test the used state of a drive I would first fill the drive then restore my test image onto it. The restore process helped to fragment the drive and make sure the spare-area got some use as well. If we take the same approach but instead of imaging the drive we perform a clean Windows install on it, we end up with a much more fragmented state; it's not a situation you should ever encounter since a fresh install of Windows should be performed on a clean, secure erased drive

[...]

Something definitely changed with the way the G2 handles fragmentation, it doesn't deal with it as elegantly as the G1 did.

http://www.anandtech.com/storage/showdoc.aspx?i=3631&p=11

Also - er benutzt zwei verschiedene "Used" States, wobei der eine, laut seinen Aussagen niemals erreicht wird. Sorry, aber...1x Drive befüllen und Windows installieren...? Geht man einige Seiten zurück, findet man diese Aussage:

My personal desktop saw about 100GB worth of writes (whether from the OS or elsewhere) to my SSD and my data drive over the past 14 days. That’s a bit over 7GB per day of writes.

Also in zwei Wochen wäre dieser "State" bei ihm bereits erreicht. Ist aber ein kurzes "Niemals"!


Edit:@Mumpel

Das meine ich doch: die Auswirkungen Random Writes sind in der Praxis nichtmal wirklich messbar, weshalb sie eben auch kaum eine Rolle spielen - jedoch zielt sein ganzer Test extrem stark auf diese Random Writes ab, weil eben zu wenig sehr schlecht sind (wie wir von JMicron gelernt haben). Ich sage nicht, dass sie egal sind, aber es muss mir erstmal bewiesen werden, dass die Intel durch die Random Writes soviel toller wird. Und ja - die Praxis interessiert mich, IOMeter nunmal wirklich weniger. Das ist das Äquivalent zum 3DMark bei GPUs: "Ich spiele kein 3DMark!".

I/Os/s ist nichts anderes als eine andere Angabe für MB/s. Ist die Filegrösse bekannt, unter der gebencht wurde kann das ganz einfach umgerechnet werden. IO/s sagen also im Prinzip nicht mehr aus als MB/s (unter der Annahme, dass die Filegrösse bekannt ist). Bzw. hohe I/O/s deuten darauf hin, dass vor allem kleine Dateien gelesen/geschrieben werden. Das ist aber nur eine Tendenz - ohne Angabe der Dateigrössen sagt's nach wie vor wenig aus.

Ich war unter derselben Annahme wie du, dass bei Multitasking viele Outstanding I/Os entstehen und die Intel dadurch auch in der Praxis dominiert. Doch nach den Tests von Moros, und auch meinen eigenen, komme ich zu dem Schluss, dass in der Praxis selten über 1 Outstanding I/O entstehen. Moros hat das selbst nachgetestet mit dem Performance Monitor: selbst bei Multistart von Apps mit einem Batch-Script kam man nicht über 3 Outstanding IO/s hinaus. Mit ASS SSD Bench und meist auch mti IOMeter wird mit ganzen 64 Outstanding I/Os gebencht. Das hat mit der Realität nicht im entferntesten was zu tun.

 

[mumpel]

Interessant. Ich dachte immer, dass die IOPS letztlich für die Performance entscheidend sind, nicht aber die Messung der Performance selbst. Also ich kann mit 10 Fingern schreiben. Das führt erstmal zu einer hohen Schreibperformance, sagt aber nichts darüber aus, wie schnell ich die 10 Finger bewegen kann. Andere Leute können nur mit 4 Finger schreiben und sind deswegen sicherlich langsamer - aber nicht zwangsweise. Gibt es aber jemanden, der so schnell schreiben kann, wie ich, aber 20 Finger hat, dann ist er noch mal schneller. - Oder 4 GHz Single-Core vs. 2 GHz Octa-Core: Kann ich die CPU-Kerne voll auslasten, dann ist ist der Octacore 4x schneller als der Single-Core. Kann ich aber nicht parallel arbeiten, dann sind 1x 4 GHz schneller als 1x 2 GHz mit 7 Cores wartend. Got me?

Dann sind diese IOPS nur für Extrem-Anwendungen, wie z.B. Datenbanken interessant. Ich bin immer davon ausgegangen, dass IOPS und damit Random Reads für die miese Performance der JMicron verantwortlichen waren.