• Offizieller Beitrag

    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:



  • Hi Oscar !

    Ein hoffentlich irgendwie nützliches Feedback ^^ :

    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.

    Für diejenigen, die sich über das schwarze xD8 in der Konsole bei Schreib-/Leserate wundern sollten :

    -> GUICtrlRead($idSpeedAvg) liefert Ø ....... MS/s zurück. Das Unicodezeichen Ø (Hex=xD8, Dec=216) wird in der Konsolenanzeige als xD8 dargestellt.

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

    • Offizieller Beitrag

    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:

  • Ups!

    Na gut, die Ausgabe soll später eh nicht mehr in der Console stattfinden, aber bei mir wird das Zeichen trotzdem korrekt angezeigt:

    An meinen SciTE-Einstellungen/meiner SciTE-Version liegt es aber offenbar nicht, denn

    Code
    ; Testzeichen :
    ; Unicode xD8/Dec216 = @ , Unicode x40/Dec40  = ø
    Global $sUnicode = '@ ø'
    ConsoleWrite('Schreibe Unicode xD8 und x40 = ' & $sUnicode & @CRLF)

    zeigt korrekt Schreibe Unicode xD8 und x40 = @ ø an. Egal, die Konsole wird ja nur in der Beta verwendet. Kein Grund also, hier viel Zeit darauf zu verschwenden ;).

    EDIT : Oscar

    Irgendwie läßt mir das Thema keine Ruhe :rolleyes:.

    Könntest Du mir, falls es nicht nervt, bitte aus Deiner SciTEGlobal.properties diesen Bereich posten :

    Code
    # Internationalisation
    #NewFileEncoding=CodePage/UTF8BOM/UTF8/UTF16BE/UTF16LE         # Only available in SciTE4AutoIt3 version
    # Japanese input code page 932 and ShiftJIS character set 128
    #code.page=932
    #character.set=128
    # Unicode
    #code.page=65001
    code.page=0
    # character.set=204

    Damit Dein Thread hier nicht mit Nebensächlichkeiten vollgestopft wird, ggf. als Konversation.

    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 editiert, zuletzt von Musashi (9. Dezember 2018 um 20:33)

  • Stelle mal in den Eigenschaften der Eingabeaufforderung eine Schriftart ein, die UTF-8-Zeichen beinhaltet - z.B. DejaVu Sans Mono.

    Interessantes Verhalten :

    1.

    Eingabeaufforderung (Win 7) geöffnet. -> Eigenschaften ->Schriftart :

    Auf Schriftart 'Lucida Console' (TrueType) geändert -> OK

    2.

    In SciTE (echte Vollversion) die .au3 von Oscar laufen lassen ('Go').

    In der Console von SciTE wird das Zeichen ø korrekt angezeigt.

    Beende ich die Anwendung von Oscar (bin aber immer noch im Editor), dann springt in der bereits vorhandenen Console das Zeichen zurück auf das schwarze xD8.

    Bitnugger :

    Erst mal 'Danke' für den Tipp.

    Ich werde das noch etwas eroieren und mache ggf. einen eigenen Thread dazu auf.

    Mit Oscar's Projekt hier hat das ja nur sehr am Rande zu tun ^^.

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

  • Hallo Oscar,

    ich bekomme beim Testen einer mit exFat formatierten Speicherkarte folgende Konsolenausgabe:

    Code
    --> Press Ctrl+Alt+Break to Restart or Ctrl+Break to Stop
    FillBuffer-ASM-Code-Size: 34 Bytes
    CheckBuffer-ASM-Code-Size: 50 Bytes
    IOBuffer-Size: 64,0 MB
    
    @@ Debug(222) : $g_bReadWrite = True
    >Error code: 0
    !>11:22:30 AutoIt3.exe ended.rc:-1073741819
    +>11:22:30 AutoIt3Wrapper Finished.
    >Exit code: 3221225477    Time: 67.76

    Habe ich etwas überlesen und das Tool funktioniert nur mit NTFS formatierten Datenträgern?

    Passiert auch auf meiner Festplatte:

    Code
    --> Press Ctrl+Alt+Break to Restart or Ctrl+Break to Stop
    FillBuffer-ASM-Code-Size: 34 Bytes
    CheckBuffer-ASM-Code-Size: 50 Bytes
    IOBuffer-Size: 64,0 MB
    
    @@ Debug(222) : $g_bReadWrite = True
    >Error code: 0
    !>11:28:42 AutoIt3.exe ended.rc:-1073741819
    +>11:28:42 AutoIt3Wrapper Finished.
    >Exit code: 3221225477    Time: 21.26

    Win 10 Home 64 Bit 1803

    In beiden Fällen wird noch der Ordner Flashtest erstellt und eine Datei 000001.ft mit 0 Byte angelegt.

    mfg (auto)Bert

    Einmal editiert, zuletzt von autoBert (12. Dezember 2018 um 11:39)

    • Offizieller Beitrag

    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?

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

    Bei #AutoIt3Wrapper_UseX64=y erhalte ich (Konsole) :

    !>15:00:38 AutoIt3.exe ended.rc:255

    Bei #AutoIt3Wrapper_UseX64=n läuft alles ok !

    System : Win 7 SP1 Pro 64

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

    • Offizieller Beitrag

    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.

  • Deswegen habe ich ja die Vermutung, dass bei autoBert die Scripte standardmäßig im 64-Bit-Modus ausgeführt werden.

    Korrekt, im 32-Bit modus funktioniert es auch bei mir:

    warum die Speicherkarte im Lesen schlechtere Werte hat als beim Schreiben verstehe ich nicht. Beim Schreiben ermittelt dein Skript ~ gleichen Wert wie h2testw.

    • Offizieller Beitrag

    Korrekt, im 32-Bit modus funktioniert es auch bei mir:

    Ah! Gut, dann lag es nur daran.

    warum die Speicherkarte im Lesen schlechtere Werte hat als beim Schreiben verstehe ich nicht.

    Bei nur 1 GB Test-Speicherplatz ist das nicht so aussagekräftig. Versuch's mal mit 8 oder 12 GB.

  • Hi,

    zunächst einmal: Super Script!

    Bei ersten Tests bekomme ich zwar teilweise gravierende Unterschiede in den Datenraten bei mehrmaligem Tests nacheinander, aber da vermute ich eher die Kombination AutoIt/Windows.

    Ja, der 64-Bit-Modus funktioniert bei dem Script nicht!

    Das hat damit zu tun, dass die Assembler-Routinen nur 32-bittig sind.

    Naja, dem lässt sich ja abhelfen...:D

    Ein 64-Bit-Modus würde gut zum Programm passen!

    AssembleIt bzw FASM und auch die FASM.dll assemblieren ja 64-Bit-Code auch auf 32-Bit-Systemen.

    Der eigentliche "Programmcode" kann ja bleiben, es müsste nur die Aufrufkonvention angepasst werden.

    Obwohl, dann kann man auch die Handvoll Zeilen direkt anpassen, sieht dann beim disassembeln auch "besser" aus :o)

    • Offizieller Beitrag

    zunächst einmal: Super Script!

    Danke!

    Ein 64-Bit-Modus würde gut zum Programm passen!

    AssembleIt bzw FASM und auch die FASM.dll assemblieren ja 64-Bit-Code auch auf 32-Bit-Systemen.

    Naja, aber damit wäre das Script dann nur auf x64-Rechnern lauffähig.

    Ich benutze hier die Assembler-Routinen ja hauptsächlich, weil das füllen/testen des Buffers mit AutoIt zu lange dauern würde.

    Mein, nicht optimierter, Assembler-Code ist bereits ein paar tausend Mal schneller als AutoIt das schaffen würde. Eine weitere Optimierung des Assembler-Codes bringt nicht viel, weil das in Relation zu dem übrigen AutoIt-Code nur noch ein paar Mikrosekunden sind.

    Bei Messwerten von MegaByte pro Sekunde (mit nur 2 Nachkommastellen) geht das in der Messgenauigkeit unter. Mal abgesehen von dem "Windows-Einfluss".

    Obwohl, dann kann man auch die Handvoll Zeilen direkt anpassen, sieht dann beim disassembeln auch "besser" aus

    Du musst nicht disassembeln. Im Thread "https://autoit.de/index.php?thread/86236-bytemuster-zum-testen-der-laufwerksgeschwindigkeit/&postID=692725#post692725" hatte ich den Assembler-Code bereits gepostet.

    Hier nochmal direkt:

  • Naja, aber damit wäre das Script dann nur auf x64-Rechnern lauffähig.

    Naja, selektiv je nach @AutoItX64 benutzt du den 32- bzw. 64-Bit Code....

    Einmal am Anfang des Scripts zugewiesen, Problem gelöst.

    Hab zzt bissl Stress im Job und bin schlagskaputt abends, aber am Wochenende sollte ich dazu kommen, die 64-Bit-Version deines ASM-Codes zu erstellen.

  • so, hier mal die 32- und 64-Bitversion

    es war nicht viel umzuschreiben (eigentlich nur die ASM-Codes und die DllCallAddress() ), dank Oscars TOP-Programmierung!

    //EDIT

    bereinigte Version

    FlashTest64.au3

    ciao
    Andy


    "Schlechtes Benehmen halten die Leute doch nur deswegen für eine Art Vorrecht, weil keiner ihnen aufs Maul haut." Klaus Kinski
    "Hint: Write comments after each line. So you can (better) see what your program does and what it not does. And we can see what you're thinking what your program does and we can point to the missunderstandings." A-Jay

    Wie man Fragen richtig stellt... Tutorial: Wie man Script-Fehler findet und beseitigt...X-Y-Problem

    2 Mal editiert, zuletzt von Andy (15. Dezember 2018 um 14:20)

    • Offizieller Beitrag

    es war nicht viel umzuschreiben (eigentlich nur die ASM-Codes und die DllCallAddress() ),

    Ich danke Dir für Deine Mühe! :klatschen:

    So kann es dann auch eine 64-Bit-Version geben.

    Im Moment arbeite ich gerade an der Ausgabe-Grafik. Es soll ja nicht wirklich diese Zahlenwüste gespeichert werden. ;)

    Ich habe schon mit GDI+ eine schöne Grafik mit den beiden Testabläufen (schreiben/lesen) erstellt. Ich kann die auch beliebig skalieren.

    Jetzt bin ich mir nur noch nicht sicher, wie das am Ende aussehen soll:

    - als Text- und Grafikdatei (.txt und .png)

    - als HTML- und Grafikdatei (.html und .png)

    - als PDF-Datei (.pdf)

    Ich tendiere zur PDF-Datei (schaue mir gerade die "MPDF_UDF.au3" an).

    Was meint ihr? Welche Ausgabe bevorzugt ihr? Und in welcher Auflösung soll die Grafik sein?

  • bzgl. "Scriptunterbrechung", wenn bspw. das Fenster verschoben wird

    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.

    Hmm, das geht auch ohne "Multitasking/threading", so wie du es bei deiner Digitaluhr schon umgesetzt hast, per _Timer_SetTimer($hMainGui, 100, '_ClockUpdate')

    Da das "anfassen" des Fensters sowieso alle Ergebnisse verfälscht, würde ich den Aufwand betreiben....

    Was meint ihr? Welche Ausgabe bevorzugt ihr? Und in welcher Auflösung soll die Grafik sein?

    Ich finde eine Historie gut, da kann man dann je nach Konfiguration die besseren/schlechteren Ergebnisse sehen. Hat mir bspw. bei Verwendung des Samsung SSD- Magician-Programms weitergeholfen. Und dort bräuchte ich nur die profane Schreib/Leserate ohne Grafik.

    Im vorliegenden Programm finde ich die Grafik schon gut! Ggf. Schreib/Leserate in zwei Fenstern nebeneinander. Die X-Achse sollte den gesamten ausgewählten Speicherplatz abbilden, dann wird das Fensterchen auch immer schön voll^^

    ciao
    Andy


    "Schlechtes Benehmen halten die Leute doch nur deswegen für eine Art Vorrecht, weil keiner ihnen aufs Maul haut." Klaus Kinski
    "Hint: Write comments after each line. So you can (better) see what your program does and what it not does. And we can see what you're thinking what your program does and we can point to the missunderstandings." A-Jay

    Wie man Fragen richtig stellt... Tutorial: Wie man Script-Fehler findet und beseitigt...X-Y-Problem

    Einmal editiert, zuletzt von Andy (15. Dezember 2018 um 22:35)

    • Offizieller Beitrag

    Hmm, das geht auch ohne "Multitasking/threading", so wie du es bei deiner Digitaluhr schon umgesetzt hast, per _Timer_SetTimer($hMainGui, 100, '_ClockUpdate')

    Mit der Timer-UDF habe ich das schonmal getestet. Die Timer-Funktion sollte die Anzeige übernehmen, aber das klappte nicht stabil.

    Wenn ich die Aufrufzeit zu hoch gesetzt habe, passte die Anzeige nicht mehr (es muss dann ja eine Zeitskala sein) und wenn ich die Aufrufzeit niedriger gesetzt habe, dann schaffte die Funktion das nicht rechtzeitig.

    Das Ganze war extrem zeitkritisch und ich will mir gar nicht vorstellen, wie das auf langsameren Systemen aussieht.

    Ich werde wohl noch ein Multiprozessing einbauen. Zwei Prozesse: einer für die Anzeige und einer für das Schreiben/Lesen.

    Wobei ich da noch testen muss, ob das mit der Interprozesskommunikation (IPC) auch klappt. Ein erster Test mit einem versteckten Edit-Control war nicht erfolgreich. Da holte der eine Prozess gerade etwas ab, während der zweite Prozess in das Edit-Control schrieb.

    Ich werde da doch mal Tests mit NamedPipes machen. BTW: Weiß jemand, ob NamedPipes einen Schreib-/Lesepuffer benutzen? Wenn nicht, wird das auch schon wieder kritisch...

    Im vorliegenden Programm finde ich die Grafik schon gut! Ggf. Schreib/Leserate in zwei Fenstern nebeneinander. Die X-Achse sollte den gesamten ausgewählten Speicherplatz abbilden, dann wird das Fensterchen auch immer schön voll^^

    Die Fortschritt-Grafik sollte nur einen ersten Überblick verschaffen.

    Bei der Auswerte-Grafik (die ich momentan in Arbeit habe) werden beide Wertetabellen als Linien auf einer Grafik dargestellt. Das sieht schon ganz gut aus.

    Ich skaliere dann die Werte auf die volle Breite. Das ist kein Problem!

    Woran ich momentan noch hänge, sind zu viele Werte.

    Solange die Anzahl der Werte die Pixel auf der X-Achse nicht überschreitet, ist ja noch alles ok, aber wenn es mehr Werte sind, als ich Pixel auf der X-Achse zur Verfügung habe, male ich quasi mehrmals auf der Stelle.

    Da muss ich wohl mehrere Werte zu Einem reduzieren (Mittelwert bilden)...