AS SSD Benchmark [2]

[Eye-Q]

Bei mir ist das genauso.

Schlecht konfiguriertes System? Naja, nachdem ich die Firmware auf die 1916 aktualisiert habe, habe ich Windows komplett neu installiert und dabei nur die nötigsten (und aktuellsten) Treiber für Grafik, Soundkarte, LAN und Logitech Setpoint installiert. Wenn da irgendwas "schlecht konfiguriert" wäre, müsste das doch auch im Native IDE-Modus auftauchen, oder nicht?

Fehlende Treiber? Da andere Treiber außer die Windows-eigenen den TRIM-Befehl nicht weitergeben, muss ich zwangsweise mit diesen Treibern leben (was ich auch gut kann). Als ich auf AHCI umgestellt habe, stand im Benchmarkfenster auch dementsprechend MSAHCI anstatt PCIIDE, das dürfte also richtig sein.

Und ja, ich habe den Rechner nach dem Umstellen nicht nur ein Mal, sondern mehrere Male neu gestartet, damit sich alle Treiber installieren etc., daran kann es also auch nicht liegen.

Wie gesagt, auch mit dem PCIIDE-Treiber ist die Performance vollkommen ausreichend bzw. immer noch fühlbar schneller als mit der alten HDD, zumindest das Starten von Anwendungen und Spielen. Mehr will ich auch gar nicht.

 

[zomtec80]

SSD: Super Talent Ultradrive GX MLC 64GB (FTM64GX25H)
CPU: AMD Phenom II X3 720 @ 3,4Ghz
Mainboard: ASUS M2N32-SLI Deluxe
Chipsatz: nVidia nForce 590
Controller: Standard-Zweikanal-PCI-IDE-Controller
Treiber: PCIIDE umstellen auf ACHI geht im Bios nicht
BS: Win7 x64
Veröffentlichung: ja

Die Werte sehen wohl miserabel aus, oder?
Liegt wohl am Mainboard?
Kann man da bei dem System noch irgendwas Optimieren?

 

[Kiddinx]

Seit ein paar Stunden werkelt in meinem Rechner auch eine SSD (Intel X-25 Postville 80 GB).

Hier mal ein paar Benchmark Ergebnisse:





Ob die Werte jetzt gut sind oder nicht ist mir eigentlich egal.
Wichtig ist, was am Ende bei raus kommt und das ist einfach nur atemberaubend.
Ich komme aus dem Staunen nicht mehr heraus.
Was für ein Performancesprung ... Die 170 € haben sich mehr als gelohnt.

 

[nsa666]

@zomtec80: kannst probieren ahci einzuschalten. Ansonsten ja die nForce boards sind nicht so schnell wie die Intel.

@Kiddinx: Recht seltsame Werte. CDM scheint beim Schreiben überhaupt nicht zu stimmen. 4k 64Thrd test bei AS SSD ist beim lesen auch irgendwie seltsam hoch. Hats mit dem Benchmark sofort geklappt oder gabs sowas wie Timerfehler?

 

[Kiddinx]

@nsa666
Keine Timerfehler. Lief auf Anhieb ohne Probleme.

Habe noch mal zur Verifizierung zu einem späteren Zeitpunkt (nachdem mein System fertig aufgesetzt war) gebencht.
Das kam dabei heraus:
Klick mich sanft

Ich kann diese Werte nicht so recht einschätzen, aber wenn du sagst, dass irgendetwas nicht stimmt macht mir das schon sorgen.

 

[Iceman021]

Deine neuen Werte sind aber vollkommen ok und auch der normale Durchschnitt bei den Intel 80 GB, wenn man sich die Ergebnisse anderer User anschaut.

 

[nsa666]

Jetzt stimmt alles. Der Wert war ja nicht zu niedrig sondern zu hoch.

 

[Morpog]

@nsa666

Mit was für größen liest und schreibst du im sequentiellen Test eigentlich?
Gemeint ist nicht die Testgröße, die sollte ja 1GB sein.

16 oder 32KB? Oder größer?

 

[nsa666]

16MB Blöcke.

 

[Morpog]

16MB Blöcke.

Oha, doch so riesig.

Dann ist meine Theorie gerade in sich zusammengebrochen warum ATTO so hohe sequentielle Werte ausspuckt im Gegensatz zu fast AS SSD und CDM

Hast du da evtl. eine Idee? Bist ja sozusagen der Fachmann hier im Forum was solche synthetischen Tests angeht.

 

[[Chewbacca]]

SSD: G.Skill Falcon 128GB
CPU: I7 860 @ 3.3 GHz
Controller ICH10R
BS Win 7 X64



Sind die Werte im normal Bereich? Hab leider keinen Vergleich.

 

[Eggcake]

@Morpog

Meine Vermutung ist, dass schlicht mit einem merkwürdigern Pattern getestet wird. Zudem liegt die Queue Depth bei der Standardeinstellung bei 4.

Im Anhang:

ATTO Standard
ATTO QD2
ATTO Pattern "0000"
ATTO Pattern "FFFF"
ATTO Pattern "Random"


Für mich ists klar:
Atto testet in der Standardeinstellung (Overlapped I/O) mit dem "0000" Pattern. Die höhere Leserate im vergleich zu "I/O-Comparison" entsteht durch die höhere QueueDepth.
Dies zumindest meine Theorie.
Die Einstellung I/O Comparison & Random Test Pattern ist imho die realistischste.

 

[Morpog]

@Morpog

Meine Vermutung ist, dass schlicht mit einem merkwürdigern Pattern getestet wird. Zudem liegt die Queue Depth bei der Standardeinstellung bei 4.

Im Anhang:

ATTO Standard
ATTO QD2
ATTO Pattern "0000"
ATTO Pattern "FFFF"
ATTO Pattern "Random"


Für mich ists klar:
Atto testet in der Standardeinstellung (Overlapped I/O) mit dem "0000" Pattern. Die höhere Leserate im vergleich zu "I/O-Comparison" entsteht durch die höhere QueueDepth.
Dies zumindest meine Theorie.
Die Einstellung I/O Comparison & Random Test Pattern ist imho die realistischste.

Das scheint es tatsächlich zu sein. Interessant auch dass FFFFFFFF 20MB/s schneller ist als 00000000

Bei Random scheint in etwa das rauszukommen was AS SSD misst. Vermutlich benutzt nsa666 auch irgendein Pattern dass mit Zufallszahlen gefüllt ist.

 

[Eggcake]

Hier noch mein AS SSD Bench, um nicht ganz OT zu werden , nach frischer OS-Installation und immerhin rund 1 Jahr Nutzung der SSD (im Laptop natürlich, deshalb etwas schlechtere Werte - sind aber so gut wie immer bzw. besser als jemals zuvor) :



Sieht ziemlich ähnlich aus wie das Random Pattern. Ist aber wohl eben auch am realistischsten - denn wann hat man mit 000000 befüllte Daten?


Edit: Hm interessant dürfte das doch mit einer SandForce SSD mit Kompression sein

 

[nsa666]

@[Chewbacca]: Ja die werte sind OK. Siehe Alex Intelligent Software - Artikel: Typische AS SSD Ergebnisse

@Morpog: Ja bei meinem Benchmark wird immer Zufallspattern benutzt. Gerade weil SSDs bei FF oder 00 dazu neigen viel schneller zu sein. Es ist aber im Betrieb eher unrealisitisch, dass jemand nur Nullen oder Einsen liest.

 

[Morpog]

@Morpog: Ja bei meinem Benchmark wird immer Zufallspattern benutzt. Gerade weil SSDs bei FF oder 00 dazu neigen viel schneller zu sein. Es ist aber im Betrieb eher unrealisitisch, dass jemand nur Nullen oder Einsen liest.

Find ich ja gut so. Hat mich nur interessiert warum ATTO so dermaßen hohe Werte erzeugt.

Mit nem Sandforce Drive sollte man das mal austesten. Hast du da schon anpassungen vor am AS SSD wegen der Kompressionsproblematik?

Weil gerade die Sandforce zeigen ja im ATTO abnormal hohe Werte. Ist aber auch klar da ein 00000000 Pattern perfekt komprimiert werden kann.

 

[nsa666]

Noch habe ich keine zufriedenstellende Lösung für Kompressionsproblem fertig. Wenn man nebenbei Zufallszahlen erzeugt, verschlechtert es die Genauigkeit bei Einkernsystemen, wenn man es zwischen den Schreibversuchen macht hat die SSD unter Umständen zu viel Zeit um irgendwelche internen Sachen abzuschliessen. Davor richtig viele Zufallszahlen erzeugen braucht zu viel RAM . Und wenn es dann anfängt zu swappen
hat man auch keine korrekte Messung mehr.

Leider habe ich auch keine Sandforce-SSD da um es genau auszutesten. NTFS kompression ist dazu ja nicht wirklich vergleichbar, da es Dateiweise arbeitet. Sandforce arbeitet vermulich Blockweise.

 

[nicoc]

...

 

[nsa666]

Test: Preiswerte SSDs (Seite 3) - 01.04.2010 - ComputerBase

 

[mrmag]

80->105 sprung gabs doch mit der neuen Firmware für 160er intel SSDs, und 4kb bei 64thrd stimmt im AHCI Fall bei dem anderen Benchmark nicht, da NCQ ja an ist und Lesevorgänge in abhängigkeit von vorhandenen controllerkanälen(ich glaube das sind 10 beim Intel Controller) parallel stattfinden.

P.S.:Ja alle 4k werte sind bei dir irgendwie schlecht.

Hallo,

sorry für die etwas späte Antwort auf Deine Antwort, da ist mir der Osterurlaub dazwischengekommen.

Ich habe die Messung nochmal wiederholt -- diesmal deaktiviertem NCQ. Diesmal ist der Geschwindigkeitsvorteil der 64threaded Messung nicht so stark (weniger als Faktor 2). Das Ergebnis von Argus Monitor finde ich trotzdem plausibler, da nun wirklich kein Unterschied mehr feststellbar ist. Warum AS SSD Benchmark im Gegensatz zum Argus Monitor Benchmark eine so geringe sequentielle Schreibrate ermittelt, ist mir auch unklar.

Mit NCQ habe ich dann auch nochmal gemessen und wieder die gleichen Ergebnisse erhalten (das Posten der Bilder spare ich mir). Wieso AS SSD einen so großen Vorteil mit NCQ ausmachen will, ist mir nicht klar. Soweit ich mich informiert habe bringt doch NCQ nur ein Umsortieren der Zugriffe, was bei SSDs so gut wie nichts bringen dürfte. Im Idealfall (Seekzeit == 0) müßte doch mit und ohne NCQ exakt das gleiche Ergebnis rauskommen.!?

Selbst wenn der ICH10(R)-Controller 10 Kanäle hätte, würden die doch nur etwas bringen, wenn die SSD auch 10 parallele Zugriffe bearbeiten könnte; aber solange die am Ende wieder über das SATA-Interface serialisiert werden müssen, kann das nicht den 10fachen Geschwindigkeitsvorteil erklären.

 

[Morpog]

CDM 3 ermittelt ähnliche Werte wie AS SSD. Vor allem bei höherer QD unter 4K.
Die eigentliche Fragestellung wäre also: Warum misst ARGUS Monitor "falsch" unter höherer QD?

Die hohen sequentiellen Raten kann man sich erklären dass ARGUS vermutlich mit einem einfachen Pattern misst (00000000 zum Beispiel) ähnlich ATTO. Siehe weiter oben.

 

[nsa666]

Sata interface schafft ja 260MB/s... ein flash-kanal nur 20MB/s... Sogar 160MB/s ist noch nicht wirklich optimal. Nicht der ICH10R hat 10 kanäle sondern der SSD Controller also intern sind flash bausteine in gruppen mit jeweils 20MB/s an den Controller angebunden. Beim Sequentiellen schreiben werden diese Parallel genutzt. Genauso wenn NCQ an ist. Ohne NCQ wird hingegen gewartet bis Controller den Block fertig geschrieben hat, da die Flashbausteine auch nur Blockbasiert arbeiten kann der dafür maximal einen der Kanäle nutzen.

Was Seq-raten betrifft. Es kann sein dass Argus Benchmark mehr CPU verbraucht und somit CPU hochtakten(oder nur aus dem C1E-State aufwachen) lässt während AS SSD kaum was verbraucht und CPU unteraktet bleibt, was sich negativ auf SSD-Peformance auswirkt. Schalt mal C1E state (und andere CPU-Sparmodi) im BIOS ab und prüf nochmal... Oder es kann natürlich sein dass es einfach Nullen schreibt was auch viel schneller geht da controller es wegoptimieren kann.

 

[Eggcake]

NCQ bringt bei SSDs eben nicht nur ein Umsortieren der Zugriffe.
Ohne es lange erklären zu wollen (Edit: wurde doch länger ) : NCQ bedeutet, dass mehrere Blöcke gleichzeitig auf die SSD geschrieben/von ihr gelesen werden können. Der kleinste Block, den eine SSD lesen kann (spezifisch jetzt auf die Intel X25-M bezogen) ist 4kB. Wird ein grösserer Block gelesen (z.B. 40 kB, um eine runde Zahl zu haben) wird dieser (auch ohne NCQ) als ein Request an die SSD geschickt und vom Controller auf die 10 Kanäle aufgesplittet. Der Theorie nach (das kann man auch mit z.B. ATTO testen) erreicht die Intel beim sequenziellen lesen/schreiben also ab etwa 40kB das Maximum.


Das war der Fall, wo NCQ nicht bzw. kaum zum tragen kommt (oder wenn, dann nur was das "Umordnen" der Zugriffe angeht).
Im folgenden der Fall, wo sich NCQ massiv vom klassischen "Verständnis" von HDDs unterscheidet:

Ohne NCQ wird ein Request nach dem anderen von einer SSD verarbeitet. Der vorhin angesprochene Request (40kB Write) wird von der SSD empfangen, er wird aufgesplittet und verarbeitet. Der nächste wird empfangen, aufgesplittet und verarbeitet. Und so weiter.
Was passiert also wenn ein Request von nur 4kB empfangen wird?
Der 4kB Request kann nicht aufgesplittet werden, da der kleinste Block der SSD 4kB beträgt. Das heisst es kann nur 1 Kanal genutzt werden. Wie ich bereits gesagt habe: ohne NCQ, nur ein Block/Request aufs Mal.
Und genau hier kommt NCQ so massiv zum tragen. Mit NCQ kann die SSDs bis zu 10 4kB Blöcke gleichzeitig lesen. In der Theorie würde also ab einer Queue Depth von 10 die Intel ihr Maximum erreichen. Da natürlich auch der Controller mitspielt, ist die Skalierung bei weitem nicht perfekt und das Maximum liegt bei 140-160MB/s und wird erst bei einer noch höheren Queue Depth erreicht (da dann garantiert wird, dass zu jedem Zeitpunkt alle Kanäle gesättigt sind).


Hoffe konnte es mit meinem bescheidenen Verständnis einigermassen verständlich erklären...ist auch schon spät.

 

[nsa666]

Die neue SSD von Western Digital:
Western Digital SiliconEdge Blue 256GB SSD Review - AS SSD Benchmark - Legit Reviews

 

[sanic]

4k wieder mies

 

[mrmag]

@Morpog, @nsa666 und vor allem @Eggcake: tausend Dank für die sehr ausführlichen Informationen. Wieder was gelernt -- da hatte ich wohl ein falsches Bild von NCQ. Ich werde mal eine Supportanfrage bei bei den Argus Monitor-Leuten hinterlassen, vielleicht fixen sie ja ihren Bench.

Warum bei mir aber die 4k Werte so schlecht sind (wowohl in AS SSD Benchmark als auch bei Argus) muß ich aber trotzdem nochmal untersuchen.

 

[nsa666]

Update 1.5.3753.27631
* XML-Export

 

[ryu ko]

habs mal in den Thread zur Postville gepostet da passts ja eigtl. besser hin.

 

[mediaman]

hier nun auch mein bench:

 

[nsa666]

Sieht OK aus.

Wenn jemand noch Ergebnisse für Sandforce und C300 für Veröffentlichung auf
der Seite: Alex Intelligent Software - Artikel: Typische AS SSD Ergebnisse Posten würde, wäre es gut.

In der Form:

SSD: 80GB Intel® X25-M G2 Postville (SSDSA2MH080G2R5)
CPU: Intel Core i7 920
Controller: Intel 82801JR ICH10R
BS: Windows 7 x64
Veröffentlichung: JA
[SCREENSHOT]