I filled all user addressible LBAs on the SSD 830, then proceeded to run our random write torture test on the now-dirty drive.[/URL]
Danach werden die SSD dann komplett seq. überschrieben:
Im
Review der 830er sieht das nach 20 Minuten Folter so aus:
Nach 60 min Folter dann aber so:
Wie man sieht, kann man die Frage, wie stark die Performance denn einbricht, so pauschal nicht beantworten, denn das hängt eben sehr stark von der Nutzung ab.
Das ist übrigens eine Kurve, die man so nicht bei einer SSD haben will, die ohne TRIM betrieben wird. Der Abfall erfolgt praktisch sofort nach Beginn des Beschreibens, man kann also prakitsch keine Daten mit voller Geschwindigkeit schreiben. Entweder hat Anand der SSD keine Pause für die Idle-GC gegönnt oder es lag an der frühen FW.
Andererseits haben auch die
840 Basic
und die
840 Pro
da nicht gut abgeschnitten. Wie es aussehen sollte, sieht man im
Test der Crucial m4 mit der 0009er FW:
Hier sieht man gut, wie die Schreibrate über ein paar GB hoch bleibt bevor sie abfällt. Der Controller hat den freien Bereich also im Idle aufgeräumt und somit etwas Platz geschaffen, der mit der vollen Performance beschrieben werden kann. Sobald ihm der ausgeht, bricht die Schreibrate zwangsläufig ein, denn nun muss der die Garbage Collection (GC) während des Schriebvorgangs ausführen, also den zu löschenden Block bestimmen (dabei das Wear-Leveling beachten), die Pages mit noch gültigen Daten darin kopieren, die denen zugeordneten LBAs neu mappen und dann den Block löschen. Diese GC hat jeder Flashsspeicher der mehr als einmal beschreibbar ist und das ist nicht mit der Idle-GC zu verwechseln, die zwar genau so etwas macht um freien Platz zu schaffen, aber eben wenn die SSD Idle ist.
Das klingt nach viel Arbeit und das ist es auch, weshalb die Schreibrate eben auch entsprechend abfällt. Das liegt u.a. daran, dass beim Kopieren der noch gültigen Daten der vorher gelöschte Block schon wieder zu einem guten Teil gefüllt wird. Da ohne TRIM Daten nur durch überschrieben der LBAs ungültig werden, nimmt im Laufe des Tests die Menge der Daten die zu kopieren sind immer mehr ab und daher steigt die Schreibrate auch langsam wieder an.
Sieht man so ein Verhalten, denn kann man auch Anands Erwartung teilen:
Hätte die m4 mehr freien Platz gehabt, so wäre der Abfall der Schreibrate auch erst später erfolgt, also nachdem entsprechend mehr Daten geschrieben wurden und dann natürlich auch nicht so massiv. Das ist wieder wie bei dem Test mit den Random Daten, nur dass bei 50% OP hier gar kein Abfall der Schreibrate mehr erfolgen sollte, weil der Controller dann ja immer soviel Platz aufräumen kann, wie man maximal nutzt. Das ist natürlich etwas extrem, da man ja nur die Hälfte der bezahlten Kapazität zur Verfügung hat und vermutlich auch total unnötig, denn wer beschreibt schon ständig die ganze Kapazität am Stück und braucht dabei auch immer die vollen Schreibrate? Also reicht es aus, soviel frei zu lassen, wie man eben am Stück schnell schreiben können möchte!
Hat man mit den Samsung denn nun die total falschen SSD für so ein Vorhaben? Vielleicht! Immerhin wurden die ja nicht mit der aktuellen FW getestet und Samsung hat da bei der Aufrechterhaltung der Performance ein Problem in der ersten FW der 830er gehabt, welche mit der aktuellen behoben wurde. Auch die
Crucial m4 war im ersten Review mit der 0001er FW noch alles andere als gut:
Auch hier erfolgte der Abfall der Schreibrate sofort. Vielleicht hat der gute Anand bei dem einen oder anderen Test dem Controller auch einfach nicht genug Zeit für die Idle-GC gegeben.
Jedenfalls sollte jetzt klar sein, worauf es ankommt: Wenn die Idle-GC in der Situation den freien Platz aufräumt, dann kann man sicher sein, dass dieser Controller mit mehr OP auch mehr aufräumt und man somit auch mehr Daten mit voller Performance schrieben kann, selbst ohne TRIM.
Bei den ganze Sadnforce funktioniert das so nicht, weil die einfach anders arbeiten und obendrein verschieden Zustände haben. Nach dem Schreiben einer bestimmten Datenmenge die etwa dem OP entspricht, gehen die z.B. in den Recovery Modus und schreiben langsamer:
Deshalb testet Anand das bei denen auch gar nicht und man kann die sowieso nicht einsetzen, wenn man eben eine bestimmte Mindestschreibrate über ein größeres Datenvolumen garantieren muss.
BlackWidowmaker schrieb:
Und ob es z.B. einen Sweep-Point gibt also eine Anzahl von SSDs die nötig sind um den Wegfall von Trimm überzukonpensieren.
Die schlechtest Schreibrate liegt bei der m4 und bei der 840 etwa so bei 20MB/s und mit 8 von denen solltest Du also nicht unter 160MB/s kommen.
BlackWidowmaker schrieb:
Eine SSD pusht das ganze System und alle Anwendungen. Für so einen noch unsinnigeren Test steht plötzlich ein Hexacore zur Verfügung, aber eine 840er Pro wird mit einem i3 getestet? Das ist übelster Hardware-Rassismus.
Sowas müssen wir als Leser wohl nicht verstehen. Das ist aber nicht exklusiv bei CB so, denn Anandtech hat tolle SSD Reviews, fast immer die neuen SSD als erster im Test und testen die Motherboads trotzdem mit einer Crucial C300:
Nicht das die C300 schlecht wäre, aber damit kann man eben das Limit der SATA 6Gb/s Ports nicht wirklich ausloten. Bei den letzten MoBo Review wurde auf den Test der SATA Performance auch gleich ganz verzichtet
BlackWidowmaker schrieb:
Könnte es sein, daß ein Performance-Fetischist dann unter anderem auch deshalb 1TB SSD-Platz haben will um Overprovisioning ohne Ende betreiben möchte? Um z.B. auch das allerletzte Quäntchen an Performance aus so einer Konfiguration rauszukitzeln?
Da sind wir aber wieder an dem Punkt, der eben für die meisten total irrelevant ist. Das allerletzte Quäntchen Performance wird extrem teuer erkauft und am Ende bringt so ein RAID dann nichts mehr, weil man einfach nicht die vielen langen Zugriffe oder so viele parallele Zugriffe hat, als dass man vom den höheren Potential des RAID auch nur noch etwa mehr nutzen kann, außer in Benchmarks. Die Mehrzahl der Zugriffe liegt imm Bereich von 4k bis 128k.
Das ist genau der Bereich, wo die 840er alle anderen übertrumpfen und deshalb gewinnt sie dann auch in den praxisnahen Benchmarks während die Vertex4 da einen echten Durchhänger hat und daher auch viel schlechter abschneidet:
Das Stripping des RAID sollte man so wählen, das man entweder mehr IOPS bekommt, dann nimmt man ein kurzes Stripping, oder man will möglichst hohe seq. Transferraten, dann sollte es nicht unter 128KB (besser noch bei 256kB, denn ohne die 4 Overlappiung I/O von ATTO würde man sehen, dass 128kB bei SSD noch nicht reichen die maximalen Transferraten auch nur annährend zu erreichen, man sieht das z.B. an den Ergebnissen mit IOMeter, wo Anand mit 128kB bencht) liegen. Dann hat man aber erst bei Zugriffen so ab einer Länge die dem Stripping mal der Anzahl der SSDs entspricht einen echten Vorteil und damit ist man aber schon fast aus dem Bereich raus, der im Alltag eine Rolle spielt. Bei 2 SSDs im RAID 0 sind das 256kB und bei 8 gibt es die maximal Performance erst bei Zugriffen von 1MB.
BlackWidowmaker schrieb:
Ich möchte wirklich nicht behaupten, daß die RAID-Option die sinnvollere ist, doch es ist auf jeden Fall eine Option die gar nicht so abwegig ist wie Du es manchmal abtust.
Dann schreib doch bitte, welche sinnvollen Anwendungen Dir da einfallen? Ich kennen nur wenige und noch weniger Leute dürfte diese wirklich nutzen. Außerdem sie die Ergebnisse auf dem Test der einzelnen SSDs doch übertragbar und CB bekommt von den Herstellern oder Händlern sicher nicht einen Berg nagelneuer SSD zugeschickt, nur um die gleich alle im RAID benchen zu können. Die müssen doch froh sein, eine möglichst zeitnah zum Erscheinungstermin zu bekommen.
BlackWidowmaker schrieb:
Wie sollen denn die Daten zur CPU gelangen? Per Beam-me-up-Scoty? Was von der CPU verarbeitet werden soll, muß erst in den RAM gelesen werden. Wenn nicht genug RAM da ist muß ausgelagert werden.
Die Daten kommen von der SSD ins RAM und genau die SSD will man doch hier testen und nicht das RAM. Das die den Weg übers RAM nehmen, ist schon klar, nur wäre die SSD doch unnötig, wenn man deren ganzen Inhalt gleich ins RAM kopiert, weil man deren Performance dann allenfalls für den Kopiervorgang erfasst aber hinterher nur das RAM bencht. Viel RAM wird von Windows nur als Cache verwendet und stört daher die Messung der Performance der SSD nur, weil man dann eben noch weniger Unterschiede sieht.
BlackWidowmaker schrieb:
Sobald aber ausgelagert wird gibt es einen großen Performanceeinbruch. Daher RAM bis zur Oberkante und weg mit dem Swapfile.
Das ist ja richtig, hat aber mit den Benchmarks nichts zu tun, denn da sollte nicht geswappt werden und das überwachen die Tester hier ja wohl hoffentlich. 4GB sollte doch wohl reichen um die Benchmarks darin unterzubringen. Mehr RAM wird dann nur als Cache genutzt und schadet der Sache daher, gerade weil es die Performance erhöht. Deswegen ist das für den Anwender natürlich trotzdem sinnvoll, für das Testsystem aber gerade nicht.
BlackWidowmaker schrieb:
Sorry aber auch hierbei bin ich beratungsresistent wenn Du so willst, oder Du bist es aus meiner Sicht. Mehr Speicher bedeutet aus meiner Sicht der Dinge, daß eine SSD überhaupt erst ohne eine Limitierung durch zuwenig Speicher ihr volles Potential entfalten kann.
Deine Beratungsresistenz ist mir da schon aufgefallen, aber reinprügeln kann sich Dir die Erkenntnis auch nicht. Mehr RAM als die Programme und Daten belegen, braucht man nicht. Den Rest nutzt Windows (und auch Linux) als Plattencache und da SSDs viel schneller als HDDs sind, bringt das damit sogar im vergleich weniger Vorteile. Man braucht also nicht möglichst viel RAM um seine SSD ohne Limitierung nutzen zu können.
BlackWidowmaker schrieb:
Einen Test mit ausgeschaltetem Datenträgercache halte ich für genauso sinnlos weil praxisfremd wie eine nicht komprimierte Rar-Datei. Und eigentlich ist es ja deine Argumentaionsschiene für besser gesagt gegen den SF-Controller, daß Daten die sich zu 100% stark komprimierbar sind, in der Praxis keine Relevanz haben.
Da hast Du was nicht verstanden. Daten die 100%ig komprimierbar sind, haben keine praxisrelevanz weil die keine Informationen enthalten, das ist richtig. Aber der Test mit dem unkomprimierten Archiv ist etwas anderes, da sind die Daten ja nicht 100%ig komprimierbar sondern nur das Archiv ist nicht komprimiert, weil sonst eben die CPU limitert. Je nach Algorithmus sogar die schnellste Hexa-Core. Es geht bei dem Test um das gleichzeitige Lesen und Schrieben auf der SSD und auch da ist viel RAM wieder kontraproduktiv, weil die Daten dann einfach alle im RAM gecacht und dann am Stück geschrieben werden können. Das ist zwar dann schön schnell, zeigt aber eben leider nicht mehr, wie die SSD mit der Situation klarkommt, wenn gleichzeitig gelesen und geschrieben wird.
Kann es sein, dass Du Benchmarks nur als Rekordjagd verstehst? Dann sind Deine Argumente nachvollziehbar. Benchmarks machen aber eigentlich viel mehr Sinn, wenn man sie einsetzt um die Eigenschaftes des Produktes zu verstehen. Dann kann man auch viel besser auf Rekordjagd sehen, weil man weiß, was geht.
ralle_h schrieb:
Daher hat CB hier meiner Meinung nach "strategisch" alles richtig gemacht.
Das sehen ich auch so! Mehr Tests wären sicher wünschenswert, aber man muss auch den Aufwand dahinter sehen.
ralle_h schrieb:
Ansonsten könnte man gleich nur noch den Controller, Leistungsabfall der Schreibeleistung usw. untersuchen und sämtliche normalen Leistungsmessungen weglassen, ganz nach dem Motto "sind eh alle gleich schnell".
Solche Messungen sind aber komplizierter, denn das macht kein Benchmark, denn man einfach mal so startet und dann laufen lassen kann. Damit steigt auch die Fehlerquelle und wenn Du diese ganze Monsterbeitrag gelesen hast, dann wirst Du verstehen, was ich meine. Schon bei anands TRIM Tests bin ich mir nicht sicher, wie genau reproduzierbar die Tests abgelaufen sind und schon eine kürzere oder längere Folter oder Wartezeit können eine Menge ändern.
ralle_h schrieb:
Das ist leider nicht optimal und auch nicht die Seriosität, die CB anstreben sollte. Englische Websites wie Anandtech sind da leider den deutschen Magazinen um einiges voraus, da hat Black Widowmaker durchaus recht.
Deswegen sollte man eben auch immer möglichst viele Reviews auf möglichst verschiedenen Webseiten lesen, denn nur auf einer Seite findet man garantiert nicht alles. Dabei muss man aber auch kritisch sein, denn sonst fällt man auf machen Mist oder beim Test gemacht Fehler und darauf gezogener Fehlschlüsse rein.
(soweit ich das persönlich bis jetzt erblicken konnte).
