Bytemuster zum testen der Laufwerksgeschwindigkeit

  • 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. 8)

    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):

  • 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) ;):

    Gruß Musashi

    86598-musashi-c64-png

    "Am Anfang wurde das Universum erschaffen. Das machte viele Leute sehr wütend und wurde allenthalben als Schritt in die falsche Richtung angesehen."


  • 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)

  • 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.

  • 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

    86598-musashi-c64-png

    "Am Anfang wurde das Universum erschaffen. Das machte viele Leute sehr wütend und wurde allenthalben als Schritt in die falsche Richtung angesehen."


  • 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.


    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.

  • 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

    86598-musashi-c64-png

    "Am Anfang wurde das Universum erschaffen. Das machte viele Leute sehr wütend und wurde allenthalben als Schritt in die falsche Richtung angesehen."


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


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


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

  • 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).

  • 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

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

    Sicher, dass die nicht in einem USB2 Port stecken ;)?


    Gruß Musashi

    86598-musashi-c64-png

    "Am Anfang wurde das Universum erschaffen. Das machte viele Leute sehr wütend und wurde allenthalben als Schritt in die falsche Richtung angesehen."


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

    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:

  • 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).

  • 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.

  • 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)



    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.


    Es gibt sehr viele Leute, die glauben. Aber aus Aberglauben.
    - Blaise Pascal

  • 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.

  • 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):

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

  • 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).

  • 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.

    Es gibt sehr viele Leute, die glauben. Aber aus Aberglauben.
    - Blaise Pascal