AS SSD Benchmark [3]

[crackett]

...in meinen augen ein beweis das bei AS SSD irgendwas nicht passen kann

Das sehe ich seit einiger Zeit auch so. Deshalb orientiere ich mich zur Zeit an CDM. Hoffentlich bekommt nsa666 das in den Griff. Wäre wirklich schade um das Tool.

 

[pinki]

CDM ist für mich keine alternative da mit CDM echt zu viel schreibt

 

[crackett]

Wenn aber AS unzuverlässig ist, muß man alternativ gegenbenchen und da bleibt ja nur CDM. Dann hat man doppelt gebencht - auch keine Lösung. Ich benche auch immer nur die 4K, wenn ich wissen will, ob mein SSD noch ok ist.

 

[nsa666]

Da Stoppuhrmessung auch mit schwankt heisst es dass die gemessene Datenrate richtig ist. Samsung scheint nur nicht mit zu schnellen Befehlsfolgen klar zu kommen. Wenn man CPU-Takt drosselt oder alles auf einen Kern legt nimmt die Anzahl der Befehle ab und die Datenrate steigt. Da CDM und IOMeter IMMER nur mit einem Kern arbeiten tritt da der Fehler nicht auf(zumindest bei den aktuellen CPUs). Den Benchmark künstlich zu verlangsamen nur wegen Samsung SSDs kann auch nicht Sinn der Sache sein. Gibt es vielleicht ein FW-Update von Samsung?

 

[Spieluhr]

Den Benchmark künstlich zu verlangsamen nur wegen Samsung SSDs

Pinki, du hast ein Rentner-SSD.

 

[nsa666]

Ist halt ein anderes test-pattern als bei CDM. Schade dass die Samsung da schwankende Werte liefert, aber ich weiss nicht wie ich das beheben könnte ohne bei allen anderen SSDs die Werte einbrechen zu lassen. Wenn es wirklich ein Messfehler wär würden die (Stoppuhr-) Zeiten konstant bleiben.

 

[pinki]

hast den screen gesehen den mir AS SSD gestern abend brachte?
Da hatte ich trotz 2800 MHz vollkommen korrekte ergebnisse, mehrfach, aus irgend nem grund sind diese heute nichtmehr erreichbar, genauer genommen nach nem neustart schon nichtmehr.
Wie ist das zu erklären denn da waren die ergebnisse plötzlich nahezu übereinstimmend mit IOMeter und CDM.
Getestet wurde mit allen Kernen, normalen Takt usw, es wurde nichts verändert alles auf standard.

Ich habe ja bereits schonmal geschrieben, real, also bei tests die den täglichen umgang mit dem PC wiederspiegeln, Programmstarts, Windows Boot, kopieraktionen und und und, liegt die Samsung grundsätzlich vor einer Sandforce (auch bei raid0 liegt das Samsung gespann vor dem Sandforce gespann), denkst du nicht das es ja sein könnte das eben die test Pattern die du nutzt einfach ungünstig sind und zu weit weg sind von realen aufgaben?

PS:
FW ist die aktuellest drauf, keine der bisherigen FW´s hat an den ergebnissen im AS SSD etwas verändert, das einzige was derzeit komische ergebnisse liefert ist wenn ich den neusten Beta RST installiere, da sind dann die AS SSD Kopier Bench ergebnisse so weit weg von der realität wie das Weltall von nem flusskrebs

 

[nsa666]

Realitätsnähe der Pattern war schon immer ein Problem.
Neue nightly die Befehle etwas zeitlich veteilt (und zusätzlich genauigkeit der Messung bei 64er Tests weiter verbessert):
http://www.alex-is.de/progs/AS SSD Benchmark-nightly.zip

Kannst ja mal messen obs was bringt.

 

[pinki]

ich teste eben mal

Edit:

Nö, ergebnisse sind nicht wirklich anders, Read wie auch Write sind zu niedrig, Read verbessert sich zwar wieder durch niedrigeren takt, write ist und bleibt aber gut 15-20 MB/s hinter dem zu erwartenden ergebniss im 64-4k

PS:
Laut Task Manager arbeitet CDM bei mir mindestens mit 2 Kernen

Hier noch CDM Screens

Bild 1 Task Manager auslastung CDM... wie man sieht 2 kerne werden belastet (Screen bei 1157 MHz)
Bild 2 CDM mit 2800 MHz
Bild 3 CDM mit 1157 MHz

Schön zu sehen, egal welcher takt, absolut stabiele ergebnisse, ändert sich übrigends auch nicht mit zuweisung auf nur einen kern

 

[nsa666]

Wenn man in Quellcode von CDM guckt, sieht man dass es nur einen Kern nutzt(bzw. Windows die entscheidung überlässt)... Das es sich mit der Nightly nicht ändert ist aber eher seltsam. Noch eine Nightly:
http://www.alex-is.de/progs/AS SSD Benchmark-nightly.zip
Bei dieser sind alle befehle um 1ms gegeneinander versetzt im 64thrd test. Probiere mal aus.

Um genau wie CDM zu sein, anzahl threads auf 32 geändert (Nur testweise).
http://www.alex-is.de/progs/asssd32.rar

 

[pinki]

ähm... nö.. kontraproduktiv
2800 MHz nurnoch maximal 70 MB/s read 64-4k
1157 MHz immerhin noch 110 MB/s Read 64-4k
Writes bleiben unverändert niedrig (ca 15 MB/s hinter CDM und IOMeter)

Du bist dir sicher das ich dir nicht eine meiner 64 GB Samsung 470 für ne woche zuschicken soll, ich denk du würdest dir da am leichtesten tun dem grund auf die schliche zu kommen.
Is ja nun nicht so das ich nicht 1-2 wochen auf eine der beiden verzichten könnt und noch würde die gewährleistung ziehen wenn was abrauchen würde ^^

 

[Morpog]

Erzeugt CDM auch mehrere Threads oder wird es dort Windows bzw. dem AHCI Treiber überlassen die Anfragen zu organisieren?

@pinki
Wie siehts mit der 32Thrd Version aus?

 

[pinki]

bei IOMeter?
Gleiche ergebnisse wie beim 64Thrd

 

[nsa666]

CDM macht das einfach mit entsprechenden flag (FILE_FLAG_OVERLAPPED) für async-read/write. Wenn fertig macht Windows einen Callback.

@pinki Also sind 32Threads schlechter als 64Threads?

 

[pinki]

lol... ich versteh nur Bahnhof ^^

Kannst du mal, nur damit wir beruhigt sind, ne nightly mit 32-4k anstatt 64-4k machen?

 

[nsa666]

Habe ich doch. Hier:

http://www.alex-is.de/progs/asssd32.rar

Also halten wir mal fest: Verteilen von Operationen hilft nicht.

 

[pinki]

ups sorry hatte deinen edit nicht gesehen ^^
lol und ich wunder mich was Morpog meint mit 32 thrad ^^

Edit.
Bei 2800 MHz unverändert, ergebnisse zwischen 80 und 96 MB/s Read (die gewohnten schwankungen von test zu test), Write hat sich nen tick verbessert auf 59 MB/s
Bei 1157 MHz 113 MB/s Read, aber 62 MB/s write im 32-4k, schwankt aber enorm, hatte auch nen durchlauf mit 102 MB/s Read und 60 Write

Ist der 32-4k auch um 1ms versetzt? ds bringt nämlich eher nix, im gegenteil das verschlimmert es

 

[nsa666]

Ja der 32thread war auch versezt. Habe jetzt eine Version ohne versatz hochgeladen. (selber link). Meine Vertex2 hier zeigt sich übrigens von den ganzen bastellei unbeeindruckt..

 

[pinki]

ok hier jetzt ne verbesserung

2800 MHz bisher mit diesem takt unerrreichte 113 MB/s und Write 61 MB/s ergebniss des 2. durchlaufs, beim ersten durchlauf warens noch 102MB/s Read)
Schonmal besser als mit 64-4k
bei 1157 MHz sinds gut 120 MB/s (im test werden sogar 128 MB/s angezeit nur endergebniss ist dann 120 MB/s Read und 63 MB/s Write wobei auch hier erst am ende die 63 raus kommen während des tests werden 67 im schnitt angezeigt

 

[nsa666]

Wenns nicht wieder ein Zufall ist...

 

[pinki]

ich lass es jetzt 2-3 mal laufen, wie gesagt bei ersten durchlauf warens mit 2800 MHz auch nur 102 MB/s aber selbst die waren ja schon gut, beim 2. durchlauf warens dann 113, was für 2800 MHz bei der Samsung schon sehr gut ist beim ASS Bench.

Woran das liegt das die ergebnisse so schwanken kannst du mir wahrscheinlich auch nicht sagen

Achja.
Mein raid 0 aus 2 SF hat bei der 32 thrd version die selben ergebnisse wie bei der 64 thrd... es scheint also auch beim Raid egal zu sein, die 64 thrd werden selbst dort nicht ausgereitzt, da wird man also dann schon 4 oder 5 SSD´s im Raid0 haben müssen um die 64 Thrd ausnutzen zu können, seien wir ehrlich... wohl eher selten ^^

Edit:

OK also hab jetzt mehrfach den test mit 2800 MHz gemacht im schnitt bringt die 32 thrd version 105 MB/s read.
Das ist aber schon besser als mit der 64 Thrd version denn bei der hab ich im durchschnitt 90-95 MB/s im read bei 2800 MHz
Am wenigsten schwanken die ergebnisse bei 1157 MHz da sind die ergebnisse halbwegs konstant, wenn auch nicht vollkommen konstant

was aber komisch ist.. während dem test werden mir durchgehend höhere ergebnisse angezeigt als dann wenn der test vorbei ist.

Bei 1157 MHz zb habe ich durchgehen 127-128 MB/s, am ende spuckt er aber nur 119 MB/s aus

 

[tilla]

Man kann ja auch mal mit winsat gegenprüfen. Da wird im Vergleich auch wenig geschrieben.
Einfach in eine .bat hauen.

winsat disk -ran -read -drive c -count 1 -iocount 256 -ransize 4096
winsat disk -ran -write -drive c -count 1 -iocount 256 -ransize 4096
winsat disk -seq -read -drive c -count 1 -iocount 256 -seqsize 524288
winsat disk -seq -write -drive c -count 1 -iocount 256 -seqsize 524288
winsat disk -ran -read -drive c -count 1 -iocount 256 -ransize 16384
winsat disk -ran -write -drive c -count 1 -iocount 256 -ransize 16384
winsat disk -flush -drive c
Pause

@pinki
Läuft deine CPU mit Standard-FSB (bclk)?

 

[pinki]

Es wird beim runter takten nur der (altmodisch genannt) Multi gesenkt FSB (wieder so nen altmodisches wort) bleibt unverändert

 

[Palomino2000]

CDM ist für mich keine alternative da mit CDM echt zu viel schreibt

Eine größere Menge an Messpunkten ist immer besser für die Ergebnisqualität.*

* bezogen auf gleiche Messbedingungen
* sofern tatsächlich abhängige Größen gemessen werden

mfg

 

[pinki]

3,5 GB write zu 18 GB write sind mir aber ehrlichgesagt zu viel differenz das ich CDM öfter als nur ab und an mal benutze.

Schade das AS SSD nicht ähnlich zuverlässige ergebnisse liefert (hab immer schwankungen, mit Sandforce genauso wie mit Samsung vorallem bei den Raid0 davon abgesehen das AS SSD nicht mit jeder SSD reale ergebisse ausgeben will)

 

[nsa666]

Komischerweise funktioneirts bei mir zuverlässig. Es wäre gut herauszufinden woran das liegt. Und CDM schreibt um so mehr je schneller die SSD ist... Bei RAID wirds also nicht nur bei 18GB bleiben.

 

[pinki]

das ist ja genau das problem warum ich CDM nicht als alternative anerkenne, die writes sind mir definitiv zu hoch, im Raid hab ich je nachdem welchens Raid ich benche gleich mal 28 GB und mehr an writes

Edit

Hab grad nen kleinen test durchgespielt mit meinen SSD´s bzw SSD Arrays

Kopier test mit meinem Ordner "Programme (x86)"
Größe 2,32 GB
Inhalt 14918 dateien verteilt auf 1476 Ordner

Weil hoch und runter fahren des PC´s mit SSD so spass macht wurde zwischen jedem test der PC runter und hoch gefahren
um zu vermeiden das evtl. aus daten gemossen wird die sich im Ram befinden
(nicht lachen ich habs getestet, 2 mal hintereinander ohne neustart testen und die beiden ergnisse sind grund verschieden)

Kopiert wurde von:

von Samsung 128 GB auf Samsung Raid0 = 1,32 Minuten
Von Samsung 128 GB auf Sandforce Raid0 = 1,44 Minuten

Ein Raid0 als quelle scheint sich bei kleinen dateien schwerer zu tun

Von Samsung Raid0 auf Sandforce Raid0 = 2,05 Minuten
Von Sandforce Raid0 auf Samsung Raid0 = 1,55 Minuten

Von Samsung Raid0 auf Samsung 128 GB = 2,06 Minuten
Von Sandforce Raid0 auf Samsung 128 GB = 2,00 Minuten

Bitte bedenken das die Samsung 128 GB hier eine variable ist da sie beim tests als system SSD fungierte,
keine ahnung was und ob im hintergrund während dem test zugriffe auf der 128er waren, unterschiedliche ergebnisse von bis zu 10 sekunden (hab hier die tests 3 mal gemacht)
würden jedenfalls dafür sprechen, bei den anderen tests blieben die ergebnisse recht konstand, auch dort wo die Samsung mit 128 GB die quelle war (+- 1 sekunde),
abgesehen von nachvfolgendem internen kopier test, diesen hab ich jeweils nur einmal getestet.
Zum vergleich hergenommen wurden jeweils immer der erste test der vorgenommen wurde.

Internes kopieren (Kopieren auf selben laufwerk)

Samsung 128 GB = 2,30 Minuten
Samsung Raid0 = 2,00 Minuten
Sandforce Raid0 = 2,04 Minuten

PS:
NCQ scheint bei händischen kopieren nicht zu greifen, transverraten von 17-18 MB/s waren normal wenn kleine daten geschrieben oder besser gesagt kopiert wurden, egal bei welcher SSD (sind ja alle in dem bereich recht gleich schnell beim lesen der 4k)

 

[Holt]

Entschuldige bitte die späte Antwort.

@Holt Antwort auf die Profilnachricht(oder sollte es ein PM werden?):
Forum de Luxx - Profil ansehen: nsa666

Ab etwa 10 steigt die Leistung einer aktuellen einzel-SSD auch nicht mehr.

Was ja zumindest dann eine gute Nachricht ist, wenn man dann schon den seq. Transferraten nahe kommt. Wäre aber für uns User auch interessant testen zu können, wie sich eine spezielle SSD diesbezüglich verhält.

64 ist aber bei RAID-Systemen aber schon sinnvoll(da jeder Anschluss theoretisch QD32 verarbeiten kann). Da es kein Unterschied macht ob man 32 oder 64 misst habe ich auf die Einstellung verzichtet. Eine fallende Leistung mit steigender QD konnte ich nirgendwo beobachten.

Die 470er Samsung scheint dem hier geposteten Test zufolge dann die erste zu sein, da bei der die Werte von Crystal mit der 32er Queue so deutlich über den ASS Werten lag, dass man dies nicht mehr alleine mit den Unterschied zwischen Höchstwaert und Durchschnittswert mehrerer Messungen erklären kann.

4k Bezieht sich überhaupt nicht auf die SSD-Sektoren sondern auf die (Standard-)NTFS-Cluster. Es ist dem Benutzer recht egal wie die SSD intern organisiert ist. Sie muss aber unbedingt eine gute Leistung bei 4k-Read/Write erzielen damit der Nutzer auch was davon hat.

Das stimmt zwar einerseits zweifellos, aber so wie wohl kein User einer HDD mit "Advanced Format", also physikalischen 4k Sektoren die logisch als 512Byte Sektoren dargestellt werden, auf die Idee kommt diese mit 512Byte Sektoren zu formatieren, wäre es für User von SSDs die 8k Pages haben, möglicherweise interessant diese auch mit 8k Sektoren zu formatieren, wenn dadurch die Randomwerte deutlich steigen.
Bitte verstehe das nicht als Kritik sondern als Anregung, denn ich finde ASS derzeit den aussagekräftigsten Benchmark für SSD (und USB Sticks, die ja bei parallelen Zugriffen immer alle sehr einbrechen) und finde auch, dass die Entwicklung wie mit dem Kompressionstest in eine wichtige und auch die richtige Richtung geht. Dies möchte ich gerne unterstützen und da nun einmal der Trend in Richtung größerer Pages geht, wäre es doch sehr aufschlußreich zu wissen, wie sich solche SSDs ebene bei den für sie passenden Pagesgrößen gegenüber aktuellen SSDs mit 4k Pages schlagen. Wenn eine SSD mit 8k Pages bei Random Zugriffen auf 8k Daten nicht schlechter ausfällt als bei aktuellen Modelen mit ihren 4k Pages und diese dann deutlich günstiger sind, so daß die Verluste an nutzbarer Kapazität (pro Datei verliert man ja im Schnitt einen halben FS Sektor) kompensiert wird, dann hat der User ja keinen Nachteil, oder?

 

[nsa666]

Wenn die Datei nur 2k ist und es werden ganze 8k gelesen bringt dem Nutzer eine höhere Datenrate überhaupt nichts(da der Rest eh verworfen wird). Übrigens wurden Kleine Laufwerke durchaus mit 512Byte großen Clustern formatiert (ältere XP versionen) siehe: Standard-Clustergröße für FAT- und NTFS-Dateisysteme

8K Clustergrößen werden standardmäßig erst ab 16TB verwendet. http://support.microsoft.com/kb/140365/de

 

[tomsen78]

Ist das normal das man beim Ordner öffnen während dem Writetest kurze Hänger/Lags hat von ca. 1-2s?
Oder ist das SSD abhängig?

Bin gerade am testen, wenn ich meine Intels benche und dann irgendwas anklicke starte, ordner öffne, dann reagiert alles sofort, wenn ich meine C300 benche und irgendwas mache dann läggts ständig.