Hallo Horst,
wie tel. besprochen kannst Du die Anzahl der Testloops selbst im Prog editieren und dann kompilieren.
Es zeigt sich für mich dass das gleichmäßige Beschreiben der Datei eher ein frommer Wunschgedanke bleiben wird. Ich habe mal mit dem Kernelparameter isolcpus=3 einen Kern reserviert, er wird für das System nicht mehr beim Taskscheduler verwendet. Dann starte ich das Programm mit taskset -c 3, d.h. das hrtfilecopy rennt nur auf dem für ihn reservierten CPU-Kern und wird selbst nicht mehr durch andere Progs gestört. Weiterhin hebt sich das hrtfilecopy die Priorität auf realtime-prio hoch. Was dann z.B. bei top entsprechend auch so gelistet wird.
Ergebnis: weiterhin Schwankungen der Loopzeit, sie werden auch nicht kleiner.
Man erkennt dann mit top, dass zusätzlich der Kerneltreiber mount.ntfs eine höhere CPU-Belastung bekommt, wobei er ja noch mit einem der verbliebenen Kerne läuft. Und seine Priorität steht bei top auf 20, also nicht realtime. Was ja auch für Treiber dieser Art nicht üblich ist. Und man kann hier die prio auch nicht umsetzen. Beim Dietpi wird der Disk-Treiber zusätzlich so gestartet, dass er eigentlich keine 4K-Chunks ausschreibt. Das kann man ändern, aber es bringt ebenfalls nichts. Wenn da nicht noch jemand was Schlaues weiss fürchte ich, dass das Schreiben einer kompletten Datei mit konstanten Zeitabschnitten nur ein frommer Wunsch bleibt.
Grüsse
Uli
PS: in meiner letzten Spielversion
https://www.audiovero.de/freedownload/i ... filecopy.c gibt es 100 Testdurchläufe, das Setzen der Priorität ist auskommentiert und es wird bei den Loops durch Ausgabe eines Punkts angezeigt wenn die Looptime überschritten ist. Dann kann man schön mitbeobachten wann und wie unregelmäßig das auftritt. Bei einer chunksize von 16384 oder 65536 (> 4096) wird es ein bisschen weniger. Ob es besser klingt kann ja berichtet werden.