Triller schrieb:
Habe zu deinen Ausführungen aber im Grunde nicht mehr viel zu sagen, bist hier im Forum eben der Theoretiker vor dem Herrn, meine ich aber nicht böse, diese Aussage!
Eine Theoretiker der aber 10 SSD von 5 Hersteller und 7 Modellen im Einsatz hat (hatte nachdem die OCZ Vertex2 tot ist sind es noch 6 Modellreihen von 4 Herstellern: Intel X-25V, Crucial C300/m4, Samsung 470/830 und Plextor M3). Ein bischen befasse ich mich auch praktisch mit den Dingern
Triller schrieb:
Dein zweiter Absatz ist aber echt wirres Zeug, was du da schreibst, vor allem klingt es sehr überheblich!
Sorry, aber das ist einmal die Erfahrung aus den Foren, wo es oft vorkommt, dass jemand ein Problem hat, welches mit der SSD überhaupt nichts zu tun hat. Hätte er eine HDD verbaut (bekannte Technik), so würde er dort nie das Problem vermuten. Nun hat er sich aber erstmals eine SSD gegönnt und plötzlich ist die erstmal für jedes Problem der Hauptverdachtige. Und sei es nur der Klassiker mit dem verschundenen Speicherplatz (Windows versteckte Dateien), der hier jede Woche mal auftaucht, obwohl es bei HDDs nicht anders ist.
Triller schrieb:
Ich habe auch öfter mal Renderfiles in Größen von 150 GB! Was meinst du, wie oft ich das Raid schon bis zum Anschlag voll gemacht habe, so dass nur noch ca. 1,5 GB frei waren und trotzdem passiert das alles nicht, wie du es in deinen Ausführungen beschreibst - ich schreibe bereits kurz nach dem Löschen der Daten wieder mit 370GB/s - ich wiederhole mich irgendwie und lasse es jetzt aber auch gut sein!
Auch das ist kein Wunder und auch kein heimliches TRIM. Lies mal in
Anandtechs Review der Plextor M5Pro die Seite "Performance Over Time & TRIM" durch. Da wird die zuerst mit HD Tach ganz beschrieben:
Das gibt die "vollen" Perfomance, wobei HD Tach wohl auch recht kleine Blockgrößen beim Schreiben verwendet, sonst wäre da mehr drin. Dann wurde die SSD nochmal seq. beschrieben und für 20 Minuten mit Random Schreibzugriffen belastet:
Dann hat er das ganze wiederholt aber die Random Zugriffe 60 Minuten lang gemacht, was dazu führt, dass die Zuordnung von LBA und Flashadressen noch mehr durcheinander gewürfelt sind.
Lagen vorher die zusammenhängenden LBAs auch in relativ gut zudsammenhängenden Flash Adressen, so sind die nun noch mehr für die Flashblöcke verstreut. Damit werden beim seq. Überschreiben einer Menge LBAs viel öfter nur wenige Pages in einem Block ungültig, was ja immer dann passiert, wenn ein LBA entweder überschrieben oder getrimmt wird, wobei TRIM im Test deaktiviert ist.
Die GC muss nun also laufend Blöcke zum Löschen auswählen, in denen noch viel mehr Pages gültige Daten enthalten als vorher, wo ja beim Überschreiben reihenweise Pages des gleichen Block ungültig wurden, weil die Zuordnung von LBAs zu Flashadressen nicht so konfus war. Damit müssen jetzt auch vor dem Löschen des Blocks viel mehr Daten intern kopiert werden, was einmal mehr Zeit kostet und zum anderen die vorher gelöschten Blöcke wieder viel stärker mit den alten Daten füllt, also das erneute und zeitraubende Löschen eines Block wieder viel früher, also nach viel weniger geschriebenen Daten erforderlich macht. Es können also nun weniger Daten schnell in den nun kleineren noch freien Teil eines vorher gelöschten Blocks geschrieben werden und es dauert länger bis der nächste Block gelöscht ist, weil mehr zu kopieren ist.
Aber auch das ist nicht das Ende vom Lied, denn eine gute FW, wie sie auch die Crucial m4 hat, erkennt die Situation und räumt die Daten wieder soweit als möglich auf.
Und wenn Du Dir nun hier den linken Teil der Kurve ansiehst, dann erkennst Du, dass die Schreibrate fast genau auf den 350MB/s wie am Anfang beginnt und für etwa 8 GB auch dort bleibt. Das ist der Freie Bereich, also der Unterschied zwischen den G
iB (1024^3 Byte) NAND Kapazität und den Gb (1000^3 Byte) Nutzkapazität abzüglich der Verwaltungsdaten. Diesen hat der Controller im Idle mehr oder weniger komplett freigeräumt und kann nun entsprechned viele GB auch wirklich schnell schreiben.
Das habe ich auch im zweiten Artikel gemeint und den Bereich kann man vergrößern, wenn man eben im Neuzustand (bzw. nach einem Secure Erease) einen Teil der Kapazität unpartioniert lässt. Außerdem sieht man hier auch, wie die Tiefpunkte der Schreibratenkurve immer mehr ansteigen, weil eben im dem zunehmenden Überschreiben der LBAs in den jeweils gelöschten Blöcken immer weniger Pages noch gültigen Daten enthalten. Es wird also weniger kopiert und damit weniger Kapazität der vorher gelöschten Blöcke wieder mit alten Daten belegt.
Lässt man nun 20GB unpartitioniert, so verschiebt sich der erste Abfall der Schreibrate auch um 20GB nach rechts und damit allen auch die Tiefpunkte weniger dramatisch aus. Hat man die SSD außerdem nur seq. gefüllt und dann wieder mit einer seq. Datei überschrieben, so wie es bei Dir der Fall ist, dann ist das ganze noch viel harmloser, wie man schon im Vergleich der beiden Kurven, also der nach 20 Minuten Randim und nach 60 min Random Schreiben auf der vollen SSD sieht. Das ist ein Unterschied von 169MB/s zu 49MB/s im Durschnitt!! Bei Dir sind es 0 Minuten Random und dazu kommt vermutlich noch Zeit für die GC, die das ganze nochmal so aufräumt, dass die ersten 5 bis 10GB sowieso mit voller Geschwindigkeit gehen! Dann sind 20 bis 30GB mit 370MB/s (die GB/s werte ich mal als Tippfehler, die schafft ja nicht einmal das RAM auf den schnellsten Grakas mit 512Bit Anbindung) auch kein Wunder für zwei SSD im RAID 0 die i.d.R. jede auf fast 200MB/s bei ASS-SSD kommen. Crucials Angabe von 170MB/s schreibend ist bekanntlich sehr zurückhaltend und Benchmarks mit 200MB/s bei der m4 128GB findest Du genug hier im Forum.
SSDs die in dem Test so eine Kurve zeigen, sind auch gut für den Einsatz ohne TRIM geeignet und die m4 ist seid der 009er FW sowieso eine der Besten davon (die Leserate ist übrigens schon am Limit von HD Tach, das ist halt kein Tool für SSDs):
Hier werden sogar direkt nach der Folter mit den 4k Radom Schreibzugriffen (auch wenn bei der 20 Minuten schon gereicht haben und Plextor erst nach 60 Minuten Folter am Boden war) auf die volle SSD der Abfall der Schreibrate erst nach einigen GB erfolgt, da ging die Plextor schon auf dem Zahnfleisch. Dann sieht man auch deutlich, wie die Schreibrate langsam aber stetig ansteigt. Da Anand den Test damals anders durchgeführt hat, fehlt der Vergleich nach einer halben Stunde im idle für die Idle-GC, aber bei einen zweiten seq. Schreiben sieht es so aus und man erkennt klar, dass seq. Schreiben wie weniger auf die Performance geht als wenn man die volle SSD mit Randim Schreibzugriffen belastet:
Aber ich kann nun wirklich nicht bei jedem Beitrag auf alle Details eingehen, sonst werden die alle so lang wie dieser, das liest dann kaum einer und die paar die es lesen, verstehen es wieder nicht.
Triller schrieb:
Musst wohl immer das letzte Wort haben, was Holt!
Nach klar doch
Nur weil Du die Theorie nicht verstehst, ist sie noch lange nicht falsch!
Vielmehr erklärt sie immer noch, was Du in der Praxis siehst.
Wer von sich selbst behauptet er kenne sich ebenfalls bestens aus, der sollte besser nicht solche dummen Sprüche klopfen, denn wenn einer in der Runde ist, der wirklich Ahnung hat (und den gibt es im Leben früher oder später immer), läuft er tierisch auf und danach glaubt ihm niemand mehr. Das ist jetzt nicht persönlich gemeint, wir sind ja hier unter uns und keiner weiß, wer wir wirklich sind, aber ich habe schon zu viele solcher Schlauberger kommen und schnell wieder gehen gesehen, denen keiner eine Träne nachgeweint hat. Anders sieht es dagegen bei denen aus, die sich bemüht haben zu verstehen, wie man die Theorie praktisch anwendet und im Zweifel auch mal klar sagen, wo ihre Grenzen sind statt Aufgaben zu übernehmen, denen sie nicht gewachsen sind und an denen sie dann scheitern. Aber das ist am Thema vorbei und nur mal so zum nachdenken!