AS SSD Benchmark [3]

[Lutz81]

okay nochmal im abgesicherten Modus...der Virenscanner bremst schon krass

 

[sonny2]

Habe seit Samstag auch die Crucial MX100 mit 512gb. Habe direkt das Firmwareupdate (MU02) installiert:

liegen die niedrigen werte vielleicht an der neuen firmware? kommen mir im vergleich mit anderen viel zu langsam vor.
system ist frisch aufgesetzt. abgesicherter modus bringt so gut wie keine verbesserung. CPU läuft logischerweise auf maxtakt. bin ratlos :X
mit meiner 840 evo vorher hatte ich das nicht.

hd tune ist auch merkwürdig:

das sieht immer so aus :/

 

[Holt]

Das ist normal, HD Tune ist wie alle Low-Level Benchmarks einfach für SSDs komplett ungeeignet, weil HDDs LBAs fest auf Kopf, Zylinder und Sektor umrechnen und diese dann einfach auslesen, SSDs aber mappen die LBAs auf immer wieder wechselnde Speicherbereiche. Da kann nichts ausgelesen werden, wenn eine LBA noch nie beschrieben oder getrimmt wurde und damit nicht gemappt ist, der Controller liefert dann einfach irgendwas zurück. Obendrein wird mit der Standardeinstellung immer nur alle paar MB mit 64k Zugriffen gemessen, aber 64k sind zu wenig für eine SSD um die maximalen seq. Leseraten auch nur annähernd zu erreichen. Außerdem führen SSDs ein Schattenfilesystem und verteilt die Daten entsprechend so zusammenhängend, wie sie geschrieben wurden. Bei einem Low-Level Benchmarks funktioniert das nicht, weil da die eben direkt aufeinander folgende LBAs gelesen werden und damit Zusammenhang mit dem Filesystem besteht. Liegen dort große Dateien ist die Performance besser als wenn dort viele kleine Dateien stehen.

behardware hat das hier im Rahmen eines Tests auch mal geschrieben.

Da wo die SSD belegt ist, sieht Du also die schlechte Leserate, bei den unbelegten LBAs dann die maixmal über das Interface mögliche Leserate.

 

[Dusel007]

Ist das normal das ich mit dem Marvel Treiber 1.2.0.1045 bessere Werte hab als mit msahci? Sind ueberhaupt die Werte akzeptabel?

 

[Holt]

Du solltest beim Marvelltreiber prüfen ob TRIM auch wirklich funktioniert. Das kann man nur mit dem Tool TrimCheck prüfen, man lässt es zweimal laufen, beim ersten mal wird die Testdatei erzeugt und gelöscht, beim zweiten mal wird geschaut ob TRIM funktioniert hat. Dazwischen sollte man nichts am Rechner machen und ein paar Minuten warten. Wurde TRIM nicht als funktionierend erkannt, kann man es auch erneut laufen lassen und es prüft die Daten noch einmal. TrimCheck muss auf der SSD liegen, wenn es ausgeführt wird, der User muss in dem Verzeichnis Schreibrechte haben und es darf weder verschlüsselt noch komprimiert sein.

 

[Dusel007]

Ah Ok danke Werde es mal schnell testen.
Eigentlich sollte es aktiviert sein mal schauen.
Na toll is not working ;( schade

 

[webmi]

als vergleich

2x 256GB Samsung 840 Pro @ RAID 0

 

[nsa666]

Update:

Version 1.8.5608.20474

Neue Funktionen: Einstellen der Testgröße möglich.

Download wie immer: HIER

 

[Holt]

Wird eigentlich bei der Ermittlung der Zugriffszeit Lesend darauf geachtet, dass die gelesenen LBAs überhaupt belegt sind? Wenn ich die Werte bei leeren und fast komplett vollen SSDs sehen und diese mit den 4k Lesend vergleiche, dann scheint mir das eher nicht der Fall zu sein, da die Zugriffszeit lesend extrem viel höher ist und die 4k Lesend praktisch gleich bleibt. Wenn man LBAs liest die nicht belegte (nie beschrieben oder wieder getrimmt) sind, dann liest der Controller nichts aus dem NAND, aus welche NAND Adresse auch? Dann gibt der Controller gewöhnlich einfach 00 zurück und das geht halt deutlich schneller als wirklich Daten zu lesen.

Wenn das nicht berücksichtigt ist, rüste das nach oder besser noch: Entferne diese Messung der Zugriffszeiten ganz, denn die aktuellen SSDs sind nicht mehr auf Performance bei 512 Byte Zugriffen ausgelegt, sondern auf 4k Zugriffe bei korrektem Alignment.

 

[nsa666]

Nö. Es wird nicht geprüft ob der Sektor auch belegt ist. Und es soll die mittlere Antwortszeit des Controllers gemessen werden. 512 Bytes ist nur als kleinste ansprechbare Größe gewählt.

 

[Holt]

Das habe ich mir gedacht, deshalb ist der Wert aber leider total wertlos, weil eben die Reaktionszeit sehr davon abhängt ob der gelesene LBA nun wirklich auf eine Flashadresse gemappt ist und wirklich etwas aus dem NAND gelesen werden muss oder nicht. Das ist natürlich umso häufiger der Fall je voller die SSD ist. Die wirkliche Antwortzeit kann man so auch nicht ernsthaft ermitteln.

 

[pinki]

äh... ja ne, is klar
Kann es sein das da was verbugt ist?

macht man 5 oder 10 GB testgröße werden die Ergebnisse entsprechend größer, sprich das reale ergebniss mal 3, 5 oder 10.

is ja ansich ein nettes Feature, damit is man dann der ober Guru bei den bench Freaks aber ich denke das ist nicht im sinne des Erfinders

 

[webmi]

dachte mir auch sofort, das kann ja eigtl nur ein fehler sein...

 

[nsa666]

Mist. Ein Bug. Schnell beheben.

 

[pinki]

überprüfe auch 4k write, da habe ich während des benches teilweise - (minus) Ergebnisse in der anzeige.
Beispiel -55,56 MB/s

 

[nsa666]

Update

1.8.5608.42992
+Bugfix falsche Ergebnisse bei mehr als 1GB Testgröße.

 

[pinki]

dann teste ich mal

 

[nsa666]

ja das mit den negativen Werten hing auch damit zusammen.

 

[pinki]

Komme wohl erst morgen zum testen, Internet zickt grad irgendwie, komm nicht auf deine HP, was wohl weniger deiner HP geschuldet ist als meinem scheiss Internet

Edit:
Hat doch noch geklappt.
Jetzt scheint alles in Ordnung zu sein mit deinem Bench

Frage:
Was sollen die einstellbare testgröße überhaupt bringen?

 

[nsa666]

Die neue Intel 750 hat 2,5GB DRAM-Cache. Da ist testen mit 1GB recht sinnlos.

 

[pinki]

ok das leuchtet ein

 

[webmi]

Die neue Intel 750 hat 2,5GB DRAM-Cache. Da ist testen mit 1GB recht sinnlos.

als besitzer einer Intel 750 bin ich der meinung, dass sich da nicht viel bis garnichts ändert, egal ob 1GB oder 10GB test. es ist bereits bei meinem 10GB test mit dem noch fehlerhaften tool schon eine tendenz zu sehen. gerne teste ich heute abend sowohl 1GB als auch 10GB für den direkten vergleich. mein alter und erster 1GB bench noch mit dem alten tool ist für den vergleich nicht mehr ganz tauglich, da lief die 750 noch als secondary bzw non system drive. als system drive kann sie diese benchmark ergebnisse nun nicht mehr ganz halten, da das system im hintergrund wohl ständig zugriffe fährt und die ssd so nicht mehr auf ihre vollen benchmark ergebnisse kommt. jedoch sind die seq 2.3gb/s read und die 1.3gb/s write etwa gleich geblieben und zeigen schon, dass sich 1GB von 10GB nicht wirklich unterscheiden. die zugriffszeiten gehen als systemdrive halt etwas hoch. aber ein benchmark bzw vergleich unter selben bedingungen dann heute abend.

 

[Holt]

Nochmal, wenn bei den Zugriffszeiten lesend nicht darauf geachtet wird, dass die gelesenen LBAs entweder alle belegt oder alle unbelegt (bei ganz voller SSDs und ohne TRIM sowieso nicht zu realisieren) sind, dann sind die Ergebnisse totaler Blödsinn und steigen bei einer vollen SSD schon deswegen an, weil eben die Wahrscheinlichkeit einen zufällig belegten LBA zu lesen auch steigt. Beim Lesen von belegten LBAs muss wirklich etwas aus dem NAND gelesen werden und bei unbelegten LBAs kann das gar nicht vorkommen, da ja der LBA auf keine NAND Adresse gemappt ist, der Controller gibt einfach 00 zurück, wie auch Trimcheck anzeigt.

Daher noch mal die Bitte den Test entweder zu entfernen oder so zu gestalten, dann immer garantiert belegte LBAs, eben z.B. die LBAs auf denen das/die Testfiles liegen, gelesen werden. Dann kann man auch gleich mal eine Anzeige einfügen, in wie viele Fragmente das Testfile beim seq. Benchmark aufgeteilt ist, denn die Fragmentierung führt natürlich auch bei einer SSD dazu, dass es statt weniger langer seq. Zugriffe mehr kürzere Randomzugriffe gibt, die im Prinzip immer geringere Transferraten zur Folge haben. Bei firsch formatierten Filesystem ist das kein Problem, aber nach einigen Jahren als Systemlaufwerk führt das dann teilsweis schon zu sichtbaren Verringerung der Benchmarkwerte und da kann die SSD einfach gar nichts dafür, so wie eine HDD bei Fragmentierung auch nichts für die praktisch spürbaren Leistungseinbrüche kann.

Nur weil sich keine Köpfe bewegen müssen, bedeutet das eben nicht, dass Fragmentierung überhaupt keinen Einfluss auf die Performance hat, er ist nur weitaus geringer und daher wird gerne pauschal behauptet er wäre nicht vorhanden. Nur da er sich eben gerade in den Benchmarks zeigt, wäre es gut doch auch eine Anzeige dafür zu haben, was sehr bei der Diagnose von scheinbar nachlassender Performance im Alter helfen würde, was seid der 840 Evo ja ein großes Thema ist welches viele User besorgt.

 

[webmi]

liegts an mir? der 1GB test ist durchgelaufen

 

[pinki]

ne die Meldung hatte ich auch

 

[webmi]

zugriffszeit im 10gb write leider durch diesen error total kaputt... unbrauchbar so. mir werden statt 0.018ns aus dem 1gb test hier 0.218ms angezeigt und das erscheint mir als fehlerhaft. read hingegen normal.

auch augefallen. der 4k lesen im 10gb laeuft verhaeltnismaessig sehr lange. also wirklich laaaaaaang. wenn der da 10gb durchjagen muss mit 40mb muss man etwas zeit mitbringen.

nur 1gb und 10gb getestet. ob die anderen fehlerfrei laufen kann ich nicht sagen.

 

[pinki]

das 4k Read lang dauert ist ja klar, 10 GB mit 40 MB/s lesen dauert nunmal
Die Fehlermeldung hingegen ist wie du richtig erkannt hast offensichtlich ein Bug, hatte im übrigen die selbe Zugriffszeit im Write

 

[webmi]

den einfluss durch die 2.5gb ram der 750 im 1gb vs 10gb test muessen wir jedenfalls verschieben

 

[Holt]

zugriffszeit im 10gb write leider durch diesen error total kaputt... unbrauchbar so. mir werden statt 0.018ns aus dem 1gb test hier 0.218ms angezeigt und das erscheint mir als fehlerhaft. read hingegen normal.

Das glaube ich nicht, bei Write muss ja im Bereich des Testfiles geschrieben werden, sonst würden ja wild irgendwelche Dateien zerstört werden, das wird ja auch nicht auf Low-Level Ebene getestet, bei Lesen kann das schon passen.

Die Fehlermeldung hingegen ist wie du richtig erkannt hast offensichtlich ein Bug, hatte im übrigen die selbe Zugriffszeit im Write

Das ist wohl vom Fortschrittsbalken, da wird wohl ein Wert jenseits von MAX gesetzt, denn kommt typischerweise diese Fehlermeldung.

den einfluss durch die 2.5gb ram der 750 im 1gb vs 10gb test muessen wir jedenfalls verschieben

Wieso? Erstens sind es nur 2GB, es sind zwar 5 512MB Chips, aber das ist eben ECC RAM und dem hat Intel daher einen Chip mehr spendiert:

The DRAM memory is Micron DDR3 operating at 1066MHz. The 400GB model has 1GB of DRAM while the 1.2TB has 2GB.

Und der Einfluss könnte durchaus bei der Zugriffszeit Schreibend zu finden sein, obwohl sich auch die 4k Schreibend bei 10GB schlechter sein dürften, aber zumindest die Intel DC 3700 ist ja bei Zugriffen unter 4k sehr schwach weil extrem auf Zugriffe ab 4k optimiert.

- - - Updated - - -

Hier hat webmi auch einen Benchmark von HD Tune seiner 750, wie man sieht kommt sie bei belegten LBAs nur knapp über 1000MB/s, bei unbelegten LBAs knapp auf 2000MB/s, weil HD Tune ja standardmäßig mit 64k Zugriffen bencht. Das zeigt auch gut, warum das Ermitteln der Zugriffszeit durch zufälliges Lesen von LBAs über den ganzen Adressbereich so komplett sinnfrei und irreführend ist.

- - - Updated - - -

nsa666, wie Du die LBAs ermittels, kannst Du dem Quellcode von Trimcheck oder eben der Microsoftdokumentation entnehmen. Die werden gerade bei einer vollen Sandforce dann besser sein, weil die Sandforce beim Benchen über einen kleineren Adressbereich besser sein als bei einer vollen SSD über den vollen Adressbereich, da die dann mehr IOPS bieten, was man den alten Datenblättern von SF-SSD, z.B. von OCZ damals, auch entnehmen kann. OCZ hat damals die IOPS über 8GB und über 80 oder 85% ermittelt und da waren die Unterschied teils recht deutlich. Der SF hat ja nur ein fixes SRAM als Cache und kein externes DRAM welches entsprechend der Kapazität größer ausgelegt werden kann.

 

[webmi]

du meinst, die 10GB ergebnisse - welche ja eigtl absolut identisch zu den 1GB ergebnissen sind, sieht man von den write zugriffszeiten ab - sind - trotz des errors und samt den stark erhöhten 10GB write zugriffszeiten - normal und der fehler lediglich "kosmetischer" natur ?