Bytemuster zum testen der Laufwerksgeschwindigkeit

**Oscar**

Ihr kennt vielleicht das Tool "h2testw" vom Heise-Verlag zum testen von USB-Sticks bzw. überhaupt von Laufwerken.

Jetzt dachte ich mir, dass ich sowas mal mit AutoIt schreibe.

Doch schnell stellte sich raus, dass AutoIt zu langsam ist, um den Schreibpuffer schnell genug mit Daten zu füllen. Ich hatte einen Schreibpuffer von 8 MB im Sinn und eine Dateigröße von jeweils 1 GB.

Nun will ich aber nicht einen 8 MB-Speicher im vorraus füllen und den dann immer wieder in die Datei schreiben, sondern die 1 GB Daten sollen schon unterschiedlich sein und das schafft AutoIt nicht schnell genug.

Also habe ich mal wieder etwas in Assembler geschrieben. Das ist dann so ca. 3000 mal schneller.

Im Moment ist das erstmal nur ein Script (ohne GUI): siehe Anhang.

Edit 06.12.2018: Neue Version!

Jetzt mit Schreib- und Leseroutine.

Auch die Leseroutine benutzt eine Assemblerroutine zum testen des Lesepuffers.

Das untenstehende Problem habe ich lösen können (Google sei Dank): _WinAPI_CreateFileEx() mit $FILE_FLAG_NO_BUFFERING

Das "Problem" ist jetzt, dass ich nicht weiß, warum das Lesen so schnell geht. Ich habe schon TimerInit und TimerDiff durch _WinAPI_GetTickCount() ersetzt, weil ich dachte, dass da irgendwas mit dem Timer nicht stimmt, aber daran lag es nicht.

Dann habe ich mit HxD (externer Hexeditor) in der dritten 1-GB-Datei ein einzelnes DWORD geändert, um zu testen, ob meine Assemblerfunktion richtig arbeitet. Aber auch dieses eine geänderte DWORD wird korrekt erkannt und angezeigt.

Meine Leseroutine muss also wirklich die Daten einlesen, aber mit über 2000 MB/s? Da muss irgendein Cache seine Finger im Spiel haben. Aber ein 4 GB großer Cache? Laut Taskmanager hat mein Arbeitsspeicher nur eine Auslastung von 2.71 GB.

Jetzt liefert das Script realistische Werte. Hier mal die Werte von meiner neuen "M.2 SSD im USB3-Gehäuse" (habe ich mir als USB-Stick-Ersatz gegönnt):

Code

FillBuffer-ASM-Code-Size:    34 Bytes
CheckBuffer-ASM-Code-Size:    50 Bytes

Schreibe Datei: "s:\temp\0001.ft"
Zeit: 13.213 s
Schreibrate: 77.5 MB/s

Schreibe Datei: "s:\temp\0002.ft"
Zeit: 13.198 s
Schreibrate: 77.6 MB/s

Schreibe Datei: "s:\temp\0003.ft"
Zeit: 13.088 s
Schreibrate: 78.2 MB/s

Schreibe Datei: "s:\temp\0004.ft"
Zeit: 13.869 s
Schreibrate: 73.8 MB/s

Lese Datei: "s:\temp\0001.ft"
Zeit: 4.165 s
Leserate: 245.9 MB/s

Lese Datei: "s:\temp\0002.ft"
Zeit: 4.196 s
Leserate: 244.0 MB/s

Lese Datei: "s:\temp\0003.ft"
Zeit: 4.134 s
Leserate: 247.7 MB/s

Lese Datei: "s:\temp\0004.ft"
Zeit: 4.041 s
Leserate: 253.4 MB/s

Alles anzeigen

**Musashi**

Zitat von Oscar

Meine Fragen sind nun:

- Ob das bei euch auch realistische Werte ausgibt?

Dies wären z.B. meine Werte (ob sie 'realistisch' sind, musst Du beurteilen) :

Code

ASM-Code-Size:    34 Bytes

Schreibe Datei: "C:\BS_AutoIt\Projekte\Testprogramme\temp\0001.ft"
Zeit: 853 ms
Schreibrate: 1257.7 MB/s

Schreibe Datei: "C:\BS_AutoIt\Projekte\Testprogramme\temp\0002.ft"
Zeit: 1022 ms
Schreibrate: 1050.4 MB/s

Schreibe Datei: "C:\BS_AutoIt\Projekte\Testprogramme\temp\0003.ft"
Zeit: 6790 ms
Schreibrate: 158.1 MB/s

Schreibe Datei: "C:\BS_AutoIt\Projekte\Testprogramme\temp\0004.ft"
Zeit: 7138 ms
Schreibrate: 150.4 MB/s

+>16:22:21 AutoIt3.exe ended.rc:0

Alles anzeigen

Gruß Musashi

**alpines**

Was versuchst du denn hier zu messen? Laufwerke haben unterschiedliche Performancedaten. Sequentiell, Random 4K, IOPs.

CrystalDiskMark gibt mir ganz andere Werte aus (500+ für Seq, und 280/290 für Random 4K)

Code

ASM-Code-Size:    34 Bytes

Schreibe Datei: "c:\temp\0001.ft"
Zeit: 444 ms
Schreibrate: 2416.7 MB/s

Schreibe Datei: "c:\temp\0002.ft"
Zeit: 2124 ms
Schreibrate: 505.4 MB/s

Schreibe Datei: "c:\temp\0003.ft"
Zeit: 3514 ms
Schreibrate: 305.5 MB/s

Schreibe Datei: "c:\temp\0004.ft"
Zeit: 3339 ms
Schreibrate: 321.6 MB/s

Alles anzeigen

**Oscar**

Zitat von alpines

Was versuchst du denn hier zu messen?

Mir geht es um die Dauerschreibleistung. Also wenn man viele (große) Dateien schreibt. Das gibt "h2testw" auch aus.

Das was CrystalDiskMark ausgibt finde ich wenig hilfreich im praktischen Einsatz. Da werden hauptsächlich die Werte des Laufwerkspuffers berücksichtigt.

Ich habe mir gerade zwei USB 3-Sticks gekauft und musste feststellen, dass die Dauerschreibleistung bei dem "SanDisk Ultra" nur bei rund 8 MB/s liegt. Mit "Speed up to 100 MB/s" beworben.

Der "Patriot SuperSonic Rage USB 3.1 Gen1" mit "Read up to 180 MB/s" beworben, schafft gerade mal 17 MB/s.

Eure Werte sind typische SSDs, wobei die von Musashi wohl einen sehr großen Puffer besitzt. So hohe Werte bei der zweiten GB-Datei sind schon ungewöhnlich.

**Musashi**

Zitat von Oscar

Eure Werte sind typische SSDs, wobei die von Musashi wohl einen sehr großen Puffer besitzt. So hohe Werte bei der zweiten GB-Datei sind schon ungewöhnlich.

Nur zur Info :

Meine Platte ist die : Seagate Desktop ST1000DX001 SSHD 1TB Interne Hybrid-Festplatte ((3,5 Zoll) 7200rpm, 64MB Cache, SATA III)

Zu : 'Und ob das verwendete Bytemuster so ausreicht ?'

Frage : Hätte ein anderes Bytemuster denn Einfluss auf die Geschwindigkeitsmessung ?

Gruß Musashi

**Oscar**

Zitat von Musashi

Seagate Desktop ST1000DX001 SSHD 1TB Interne Hybrid-Festplatte ((3,5 Zoll) 7200rpm, 64MB Cache, SATA III)

Ah, ok da dient die SSD als Puffer!

Bei den 150 MB/s für die 3. und 4. Datei dachte ich, dass es eine langsame SSD ist mit großen Cache.

Aber für eine Festplatte sind die 150 MB/s natürlich ein guter Wert.

Zitat von Musashi

Hätte ein anderes Bytemuster denn Einfluss auf die Geschwindigkeitsmessung ?

Da bin ich mir eben nicht ganz sicher. Ich weiß nicht, inwieweit die Laufwerke intern eine Datenkomprimierung bei der Übertragung verwenden.

Deswegen dachte ich, dass es nicht so sinnvoll ist, immer gleiche Werte zu verwenden, weil die dann besser komprimiert werden können und somit die Messwerte "geschönt" werden.

Die Messwerte von meinem Programm sollen (halbwegs) realistische Werte liefern, wenn man auf die Laufwerke viele Dateien (MP3s, Filme, CD-/DVD-Images etc.) schreibt.

Da sind Dateigrößen von 1 GB ganz passend.

**Musashi**

Zitat von Oscar

Ich weiß nicht, inwieweit die Laufwerke intern eine Datenkomprimierung bei der Übertragung verwenden.

So etwas in dieser Art hatte ich vermutet.

Ein pragmatischer Ansatz :

Lege 3 bis 4 Bytemuster, von supersimpel bis komplex, fest, und wir testen das einfach auf verschiedenen Platten/Sticks mal durch. Ob eine interne Komprimierung stattfindet, könnte man damit zumindest abschätzen.

Gruß Musashi

**chesstiger**

Einmal die SSD, eine Samsung 850 EVO M.2:

Code

ASM-Code-Size:	34 Bytes


Schreibe Datei: "c:\temp\0001.ft"
Zeit: 1823 ms
Schreibrate: 588.9 MB/s


Schreibe Datei: "c:\temp\0002.ft"
Zeit: 2186 ms
Schreibrate: 491.1 MB/s


Schreibe Datei: "c:\temp\0003.ft"
Zeit: 2281 ms
Schreibrate: 470.6 MB/s


Schreibe Datei: "c:\temp\0004.ft"
Zeit: 3766 ms
Schreibrate: 285.1 MB/s

Alles anzeigen

Und einmal die Hybridplatte Seagate FireCuda 2TB über SATA (ST2000LX001):

Code

ASM-Code-Size:	34 Bytes


Schreibe Datei: "d:\temp\0001.ft"
Zeit: 9067 ms
Schreibrate: 118.4 MB/s


Schreibe Datei: "d:\temp\0002.ft"
Zeit: 14395 ms
Schreibrate: 74.6 MB/s


Schreibe Datei: "d:\temp\0003.ft"
Zeit: 16070 ms
Schreibrate: 66.8 MB/s


Schreibe Datei: "d:\temp\0004.ft"
Zeit: 18653 ms
Schreibrate: 57.6 MB/s

Alles anzeigen

Mit den verschieden komplexen Bytemustern würde mich jetzt auch interessieren.

**Oscar**

Zitat von chesstiger

Mit den verschieden komplexen Bytemustern würde mich jetzt auch interessieren.

Ich habe gerade mal einige Testläufe gemacht.

Mit einem 8 MB großen, komplett aus Nullen bestehenden Puffer, mit einem 8 MB großen JPG-Bild (läßt sich nur schlecht weiter komprimieren) und dem von mir oben verwendeten Puffer (mit Nummerierung und invertierter Nummerierung).

Die Werte schwanken sowieso schon von Durchlauf zu Durchlauf (vermutlich aufgrund von Prozessorauslastung und RAM-Belegung), aber keiner der verwendeten Puffer hatte gravierende Vor-/Nachteile gegenüber den anderen.

Das heißt wohl, dass bei der Übertragung keine Komprimierung der Daten verwendet wird. Der Null-Puffer müsste sonst extreme Werte aufweisen.

Damit werde ich bei meiner Variante mit der (invertierten) Nummerierung bleiben, denn ich brauche eindeutige Werte zum überprüfen, ob die Daten korrekt geschrieben wurden (Test auf Flash-RAM-Fälschungen).

**Musashi**

Zitat von Oscar

Ich habe mir gerade zwei USB 3-Sticks gekauft und musste feststellen, dass die Dauerschreibleistung bei dem "SanDisk Ultra" nur bei rund 8 MB/s liegt. Mit "Speed up to 100 MB/s" beworben.

Der "Patriot SuperSonic Rage USB 3.1 Gen1" mit "Read up to 180 MB/s" beworben, schafft gerade mal 17 MB/s.

Hier zum Vergleich ein Test auf einem TrekStor USB-Stick CS, 32 GB, USB 2.0

Code

ASM-Code-Size:    34 Bytes

Schreibe Datei: "G:\Bytetest\0001.ft"
Zeit: 65538 ms
Schreibrate: 16.4 MB/s

Schreibe Datei: "G:\Bytetest\0002.ft"
Zeit: 54045 ms
Schreibrate: 19.9 MB/s

Schreibe Datei: "G:\Bytetest\0003.ft"
Zeit: 58664 ms
Schreibrate: 18.3 MB/s

Schreibe Datei: "G:\Bytetest\0004.ft"
Zeit: 61963 ms
Schreibrate: 17.3 MB/s

+>09:06:21 AutoIt3.exe ended.rc:0

Alles anzeigen

Mein USB2 Stick ist ja schneller als die von Dir o.a. USB3-Sticks .

Sicher, dass die nicht in einem USB2 Port stecken ?

Gruß Musashi

**alpines**

Zitat von Musashi

Mein USB2 Stick ist ja schneller als die von Dir o.a. USB3-Sticks .

Sicher, dass die nicht in einem USB2 Port stecken ?

Das dachte ich mir auch, ein USB 3.1 Stick der auf 17 MB/s läuft ist einfach, sofern er von einer vernünftigen Firma hergestellt wurde, nur denkbar, wenn man viele kleine Dateien schreibt.

Aber nicht bei wenigen großen, da hab ich auf meinem 3.0 Stick ja wesentlich mehr.

Mein 3.0 Stick:

Code

Schreibe Datei: "d:\temp\0001.ft"
Zeit: 54819 ms
Schreibrate: 19.6 MB/s

Schreibe Datei: "d:\temp\0002.ft"
Zeit: 40053 ms
Schreibrate: 26.8 MB/s

Schreibe Datei: "d:\temp\0003.ft"
Zeit: 25294 ms
Schreibrate: 42.4 MB/s

Schreibe Datei: "d:\temp\0004.ft"
Zeit: 25300 ms
Schreibrate: 42.4 MB/s

Alles anzeigen

**BugFix**

Mal am Rande:

Ich habe die Erfahrung gemacht, dass USB 3.0 eher selten funktioniert.

Trotz installierter 3.0 Treiber und sichtbarem 3.0 Hub im Gerätemanager werden die Laufwerke / Sticks nicht als 3.0 erkannt und laufen auf dem 3.0 Port langsamer als am 2.0 Port. Den Effekt habe ich auf verschiedenen PC mit Windows 7 / 10.

Die verwendeten Laufwerke / Sticks sind allesamt hochwertige Produkte (SanDisk, WD, Samsung).

**autoiter**

Zitat von BugFix

Die verwendeten Laufwerke / Sticks sind allesamt hochwertige Produkte (SanDisk, WD, Samsung).

Und hoffentlich nicht bei wish gekauft.. ?

**BugFix**

Zitat

Und hoffentlich nicht bei wish gekauft.. ?

Nee, bei "Ich bin doch nicht blöd" und "Pluto"

**Oscar**

Nee, die beiden USB-Sticks steckten an einem aktiven USB 3 Hub. Der ist auch heile und funktioniert bei anderen USB 3 Geräten einwandfrei.

Ich habe hier einen USB 3 Cardreader von Transcend (TS-RDF8K), der mit einer 64 GB SD-Card von Transcend auch sehr gute Werte liefert.

Oder eine 1 TB Seagate Festplatte im USB 3.0 Gehäuse, die eine Schreibrate von über 70 MB/s hat.

Der "Patriot SuperSonic Rage USB 3.1 Gen1" hat an dem Hub auch eine Leserate von über 180 MB/s. Das würde bei einem USB 2 Gerät gar nicht funktionieren.

Ich beschwere mich ja auch nicht über die Leserate, die ist super, aber die Schreibrate bei vielen dieser "ach so tollen" USB 3 Sticks ist oftmals schlechter als bei alten USB 2 Sticks.

Der 32 GB SanDisk-Stick hat übrigens ca. 10€ gekostet. Der 64 GB von Patriot hat ca. 23€ gekostet. Scheinbar muss man bei USB3 Sticks doch mindestens das Doppelte davon ausgeben, wenn man eine vernünftige Schreibrate (>30 MB/s) haben will.

**Xorianator**

Habe mir auch einmal dein Tool zu Gemüte geführt. Es sind je 2 Tests gemacht worden.

Zwei mal die interne SSD meines Surface Book 2 (15", 256 GB)

Code

ASM-Code-Size:    34 Bytes


Schreibe Datei: "c:\temp\0001.ft"
Zeit: 451 ms
Schreibrate: 2376.6 MB/s


Schreibe Datei: "c:\temp\0002.ft"
Zeit: 2966 ms
Schreibrate: 361.9 MB/s


Schreibe Datei: "c:\temp\0003.ft"
Zeit: 3157 ms
Schreibrate: 340.0 MB/s


Schreibe Datei: "c:\temp\0004.ft"
Zeit: 3203 ms
Schreibrate: 335.2 MB/s


ASM-Code-Size:    34 Bytes


Schreibe Datei: "c:\temp\0001.ft"
Zeit: 514 ms
Schreibrate: 2085.4 MB/s


Schreibe Datei: "c:\temp\0002.ft"
Zeit: 3129 ms
Schreibrate: 343.1 MB/s


Schreibe Datei: "c:\temp\0003.ft"
Zeit: 3142 ms
Schreibrate: 341.7 MB/s


Schreibe Datei: "c:\temp\0004.ft"
Zeit: 3234 ms
Schreibrate: 331.9 MB/s

Alles anzeigen

Und zwei mal eine 256 SD Karte von Samsung, diese hier. Bin mit dieser MicroSD übrigens super zufrieden, habe dort sogar einige Steam Spiele drauf gehabt (u.a. Rainbow Six Siege, PUBG) und es lief immer absolut einwandfrei, die Ladezeiten waren mehr als hinnehmbar.

Code

ASM-Code-Size:    34 Bytes


Schreibe Datei: "d:\temp\0001.ft"
Zeit: 21337 ms
Schreibrate: 50.3 MB/s


Schreibe Datei: "d:\temp\0002.ft"
Zeit: 12665 ms
Schreibrate: 84.8 MB/s


Schreibe Datei: "d:\temp\0003.ft"
Zeit: 15346 ms
Schreibrate: 70.0 MB/s


ASM-Code-Size:    34 Bytes


Schreibe Datei: "d:\temp\0001.ft"
Zeit: 17673 ms
Schreibrate: 60.8 MB/s


Schreibe Datei: "d:\temp\0002.ft"
Zeit: 15209 ms
Schreibrate: 70.6 MB/s


Schreibe Datei: "d:\temp\0003.ft"
Zeit: 14828 ms
Schreibrate: 72.4 MB/s

Alles anzeigen

**Oscar**

Ich habe mein Testprogramm mal um eine Leseroutine erweitert. Siehe Post#1.

Das "Problem" ist jetzt, dass ich nicht weiß, warum das Lesen so schnell geht. Ich habe schon TimerInit und TimerDiff durch _WinAPI_GetTickCount() ersetzt, weil ich dachte, dass da irgendwas mit dem Timer nicht stimmt, aber daran lag es nicht.

Dann habe ich mit HxD (externer Hexeditor) in der dritten 1-GB-Datei ein einzelnes DWORD geändert, um zu testen, ob meine Assemblerfunktion richtig arbeitet. Aber auch dieses eine geänderte DWORD wird korrekt erkannt und angezeigt.

Meine Leseroutine muss also wirklich die Daten einlesen, aber mit über 2000 MB/s? Da muss irgendein Cache seine Finger im Spiel haben. Aber ein 4 GB großer Cache? Laut Taskmanager hat mein Arbeitsspeicher nur eine Auslastung von 2.71 GB.

**Oscar**

Ok, Windows muss da wirklich einen Cache benutzen. Ich habe zwischendurch mal ein anderes Laufwerk getestet und dann wieder das Alte ("e:", inzwischen mit 5 manipulierten DWORDs).

Jetzt bekomme ich diese Werte (das sieht schon realistischer aus):

Code

FillBuffer-ASM-Code-Size:    34 Bytes
CheckBuffer-ASM-Code-Size:    50 Bytes

Lese Datei: "e:\temp\0001.ft"
Zeit: 6.147 s
Leserate: 166.6 MB/s

Lese Datei: "e:\temp\0002.ft"
Zeit: 5.959 s
Leserate: 171.8 MB/s

Lese Datei: "e:\temp\0003.ft"
Fehler: "Fehlerhaftes DWORD an Adresse: 0A3280D8"
Achtung! Das deutet auf einen defekten Datenträger hin!
Fehler: "Fehlerhaftes DWORD an Adresse: 133AA938"
Achtung! Das deutet auf einen defekten Datenträger hin!
Fehler: "Fehlerhaftes DWORD an Adresse: 1CBF2120"
Achtung! Das deutet auf einen defekten Datenträger hin!
Fehler: "Fehlerhaftes DWORD an Adresse: 264398DC"
Achtung! Das deutet auf einen defekten Datenträger hin!
Fehler: "Fehlerhaftes DWORD an Adresse: 2D0FEE58"
Achtung! Das deutet auf einen defekten Datenträger hin!
Zeit: 6.053 s
Leserate: 169.2 MB/s

Lese Datei: "e:\temp\0004.ft"
Zeit: 5.975 s
Leserate: 171.4 MB/s

Alles anzeigen

Aber wie kriege ich es jetzt hin, dass mein AutoIt-Script den Windows-Puffer "umgeht"?

**Oscar**

So, jetzt weiß ich auch, wie man den Windows-Cache umgehen kann: _WinAPI_CreateFileEx() mit $FILE_FLAG_NO_BUFFERING ist die Lösung.

Ich habe das Script jetzt soweit angepasst, dass ein Schreib-/Lesetest gemacht wird (neue Version in Post#1).

Heute ist auch mein neuer "USB3-Stick" angekommen. Statt noch mehr von diesen USB3-Sticks zu testen, habe ich mir jetzt eine M.2 SSD (WD Green, 120 GB) und ein externes USB3-Gehäuse gekauft. Die hat wenigstens vernünftige Schreibraten (> 70 MB/s).

**Xorianator**

Ich weiß nicht, ob es bei USB Sticks so etwas gibt, aber auf jeden Fall MicroSD Karten haben nicht nur eine Klasse zur Beschreibung der maximalen Geschwindigkeit, sondern auch zur minimalen.

Wenn du nun einen USB Kartenleser + eine MicroSD mit U3 (garantiert mindestens 30 MB/s Schreibgeschwindigkeit) kaufst, dann hast du einen wirklichen Stick und der ist zudem auch noch schnell.