Bei #AutoIt3Wrapper_UseX64=y erhalte ich (Konsole) :
!>15:00:38 AutoIt3.exe ended.rc:255
Ja, der 64-Bit-Modus funktioniert bei dem Script nicht!
Das hat damit zu tun, dass die Assembler-Routinen nur 32-bittig sind.
Deswegen habe ich ja die Vermutung, dass bei autoBert die Scripte standardmäßig im 64-Bit-Modus ausgeführt werden.
In beiden Fällen wird noch der Ordner Flashtest erstellt und eine Datei 000001.ft mit 0 Byte angelegt.
Hmm... "-1073741819" oder hexadezimal "C000000" ist ein ACCESS_VIOLATION.
Startet AutoIt bei Dir den 64-Bit-Modus?
Mist, ich habe am Anfang das hier vergessen: #AutoIt3Wrapper_UseX64=n ; 32Bit-Modus
Kannst Du das mal als erste Zeile einfügen und nochmal testen?
Es gibt eine neue Version (siehe Post #1).
Und wieso löscht du deinen Beitrag?
Ich habe ihn wiederhergestellt.
Code4Fun: Es ist unhöflich, sowas zu tun. Damit machst Du den Thread unbrauchbar.
Die Lücken im Testverlauf entstehen, wenn man mit der Maus auf den Titel des Fensters klickt, oder es verschiebt. Das dürfte aber normal sein, da dies den Testprozess unterbricht.
Stimmt! Ich hatte vergessen, darauf hinzuweisen, dass man während des Tests das Fenster nicht verschieben darf (Titelleiste anklicken).
Da AutoIt keine Threads unterstützt, müsste ich den IO-Teil in einen eigenen Prozess auslagern.
Für diejenigen, die sich über das schwarze xD8 in der Konsole bei Schreib-/Leserate wundern sollten :
Ups!
Na gut, die Ausgabe soll später eh nicht mehr in der Console stattfinden, aber bei mir wird das Zeichen trotzdem korrekt angezeigt:
Bei diesem Script handelt es sich um ein Programm, zum testen von Flash-RAM (USB-Sticks, SD-Karten, SSDs), aber auch von Festplatten.
Wichtiger Hinweis:
Das Fenster kann während des Tests nicht bewegt werden! Während der Bewegung würde die Ausführung des Scripts blockiert werden und somit zu falschen Messwerten führen.
Auch sonst sollte während des Tests nicht so viel im Hintergrund laufen. Mein Programm läuft zwar mit Priorität "Hoch", aber gleichzeitige Zugriffe auf das zu testende Laufwerk führen zu falschen Messwerten.
21.12.2018 Neu! Version 1.0.0,0 (als Anhang)
Die erste richtige Version ist jetzt fertig (keine Beta-Version mehr)!
Das Projekt besteht jetzt aus zwei Programmen ("FlashTest" und "FlashTest-Viewer"). Beide als 32- und als 64-Bit-Version.
"FlashTest" ist das eigentliche Programm zum testen der Laufwerke. "FlashTest-Viewer" zeigt das Test-Ergebnis an und kann das Ergebnis als "Text", als "HTML" oder als "HTML + Grafik" speichern. Die Grafik kann dabei in der Größe frei gewählt werden.
Weil es jetzt eine 32 und eine 64-Bit-Version gibt, deren Testdateien nicht miteinander kompatibel sind, werden die Testdateien mit unterschiedlichen Dateiendungen benannt (.ft32 und .ft64). Das Testergebnis wird mit der Dateiendung ".ftr" gespeichert (im "results"-Unterverzeichnis).
Es gibt jetzt am unteren Fensterrand eine CPU-Auslastung und eine RAM-Belegung, damit man in etwa abschätzen kann, ob das Ergebnis plausibel ist. Wenn die CPU-Auslastung und/oder die RAM-Belegung dauernd bei 100% sind, dann werden die Messwerte für das Laufwerk nicht korrekt sein.
Während der Test läuft, kann man das Fenster jetzt nicht verschieben (habe ich blockiert, es erscheint dann ein Warnhinweis), damit die Ausführung des Scripts nicht angehalten wird.
29.12.2018 Neu! Version 1.1.0.0 (als Anhang)
Diese Version ist jetzt eine Multiprozessing-Version. Das Hauptprogramm startet ein Slave-Programm, welches dann die Schreib-/Leseoperationen durchführt.
Da führte kein Weg drumherum, weil die Schreib-/Leseoperationen das übrige Script ausgebremst haben. Bei schnellen Testlaufwerken (>64 MB/s) hat man das nicht so gemerkt, aber bei langsamen Laufwerken ruckelte die CPU-Anzeige und es erschien oft die Windows-Sanduhr, weil das Programm quasi "hing".
Ein kleinerer Buffer hatte das Problem zwar auch verringert, aber dann sank auch die Transferrate.
Jedenfalls übernimmt nun ein zweiter Prozess das Ganze. Ich habe viel herumexperimentiert, wie ich die Interprozesskommunikation löse. Unsichtbare Edits, TCP und NamedPipe, alles lief nicht richtig rund, weil der eine Prozess auf den Anderen warten musste.
Bis ich auf die MailSlot-UDF von "trancexx" stieß. Damit war es dann ganz einfach.
Somit gibt es jetzt drei Programme (das Hauptprogramm "FLashTest.exe", das Slaveprogramm "Flashtest-Slave.exe", sowie das Auswerteprogramm "FlashTest-Viewer.exe") und diese drei Programme nochmal als x64-Variante.
06.02.2020 Neu! Version 1.2.0.0 (als Anhang)
Es gibt nur eine kleine Änderung. Beim auswählen des Laufwerks wird jetzt zusätzlich die Modellbezeichnung ausgelesen und mit angezeigt.
Das ist hilfreich, wenn man z.B. mehrere USB-Sticks mit gleicher Größe hat. Dann kann man anhand der Modellbezeichnung diese unterscheiden.
07.02.2020 Neu! Version 1.3.0.0 (als Anhang)
Bug behoben: Der Bustyp wurde bei neueren Laufwerken (die z.B. mit NVMe angeschlossen sind) zwar ausgelesen, aber die Einträge gab es im Array nicht, sodass ein Zugriff auf ein nicht existierendes Array-Element erfolgte, was in einem Absturz des Programms endete.
Vielen Dank an UEZ für die Hilfe bei der Beseitigung des Fehlers!
08.02.2020 Neu! Version 1.4.0.0 (als Anhang)
Ok, wenn ich das Programm schonmal wieder neu bearbeite, dann werden noch ein paar Kleinigkeiten bereinigt:
- Beschriftung für den Speicherplatz geändert in: "Speicherplatz für den Schreibtest"
- Beim Button "Nur Lesetest" steht jetzt die Größe der Testdaten dahinter
- Die CPU-Prozentanzeige etwas "beruhigt" (Mittelwert von drei Messungen)
- RAM-Belegung auf 1 MB gerundet, damit die Anzeige nicht so oft neu gezeichnet wird
- Das einlesen vom Laufwerksmodell geht jetzt viel schneller (keine Wartesekunde mehr beim umschalten des Laufwerks)
- Es gibt jetzt einen Button "Viewer starten", mit dem man den FlashTest-Viewer starten kann
15.02.2020 Neu! Version 1.5.0.0 (als Anhang)
- Die Berechnung der Werte für die Schreib-/Leserate waren nicht ganz korrekt. Ich hatte die Zeit für die Assembler-Routinen nicht rausgerechnet. Behoben!
Anleitung:
Mit der Combobox oben links wählt man das zu testende Laufwerk aus. Es werden dann einige Laufwerksinformationen angezeigt (rechts).
Bei "Test-Speicherplatz" kann man auswählen, ob der gesamte freie Speicher (nur volle GigaByte) oder nur eine bestimmte Anzahl an GigaByte getestet werden sollen.
Es gibt jetzt zwei Start-Buttons. Einmal "Schreib-/Lesetest" und einmal "Nur Lesetest". Der Button "Nur Lesetest" ist nur dann aktiviert, wenn sich auf dem Laufwerk bereits Testdateien befinden.
Man kann damit dann die vorhandenen Dateien ein weiteres Mal testen.
Links davon wird der Fortschritt angezeigt und unten eine Grafik über den Testverlauf. Rechts neben der Grafik wird noch der Maximal-, der Durchschnitts- und der Minimalwert angezeigt.
Beim Schreiben werden immer 1 GB große Dateien auf dem Laufwerk geschrieben. Diese Dateien enthalten bestimmte Bytefolgen, die beim auslesen überprüft werden.
Achtung! Sollten dabei Fehler auftreten, ist entweder der Datenträger defekt oder es handelt sich um eine Fälschung (die Kapazitätsangabe ist größer als das tatsächlich vorhandene Flash-RAM).
Ganz rechts befindet sich der "Testbericht". Dort wird eine Zusammenfassung der Meldungen des Scripts angezeigt. Dieser Testbericht wird am Ende des Tests gespeichert und zwar in einem Unterverzeichnis ("results") von dem Scriptverzeichnis.
Der Testbericht bekommt als Dateinamen das Datum und die Uhrzeit im Format: "yyyy_mm_dd__HH_MM_SS.ft" zugewiesen.
Screenshots:
FlashTest1.pngFlashTest2.pngFlashTest3.png
Frage zum externen USB3-Gehäuse :
Ist es das 'Kalea Informatique USB-Stick Gehäuse für SSD M2 auf USB3 (USB 3.0 SuperSpeed) ?
Nee, sieht aber so ähnlich aus: https://www.amazon.de/dp/B07D35BLC7/…5740101_TE_item
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.
Ja, diese Überlegung hatte ich auch schon.
Aber dann habe ich gesehen, dass die M.2 SSDs recht günstig geworden sind (die WD Green 120 GB kostet bei Amazon 24.90€). Das externe USB3-Gehäuse gibt es für 14.85€, sodass ich für ca. 40€ einen richtig schnellen USB-Stick habe.
Von der Größe her ist das zwar mehr als die MicroSD-Card plus Reader, aber mit 10x3 cm durchaus auch noch hosentaschentauglich. 
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).
Jetzt habe ich die Hintergrunde mit eingebaut.
Nur mal so als Hinweis:
Bitte poste nicht xxx Versionen von Deinem Programm, wenn es nicht für das Problem unausweichlich ist.
Im Allgemeinen machen wir das so, dass die jeweils aktuelle Version in Post#1 gepostet wird (Beitrag bearbeiten, altes Programm löschen, neues Programm hochladen).
Du kannst dann gern noch einen Beitrag hintendran schreiben, damit der Thread als neu gekennzeichnet wird.
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):
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/sAber wie kriege ich es jetzt hin, dass mein AutoIt-Script den Windows-Puffer "umgeht"?
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.
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.
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).
Perfomance Unterschied bei ca. 100 Dateien
Copy&Delete 3:12 Minuten
Move 2,9 Sekunden!
Das gilt aber nur, wenn Quelle und Ziel auf der gleichen Partition liegen.
Anderenfalls:
If the source and destination paths are on different volumes a copy and delete operation is performed rather than a move.
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.
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.
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):
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/sInt() ist nötig, weil wir ja keine Zahl mit Nachkommastellen wollen.
Ich habe das jetzt nicht komplett verfolgt, aber hattet ihr nicht Stringformat für die Ausgabe benutzt?
Oscar hat deinen Wunsch umgesetzt.
Nur bedingt!
Wenn Quelle und Ziel auf der gleichen Partition liegen ist Copy und Delete sehr langsam im Vergleich zu FileMove.
Das habe ich bei der UDF (noch) nicht berücksichtigt.
