Ich habe mich die Tage mal ein bisschen intensiver mit dem improvefile beschäftigt. Dazu dann mal auf meinem Raspberry Pi4 das DietPi installiert und mit der letzten Version 0.9 gespielt. Nun habe ich am Pi4 keine SSD, also testweise einen USB-Stick verwendet. Was direkt dazu geführt hat, dass das improvefile-Skript, das ich als DAU noch mit verbose habe laufen lassen, nur noch lauter delay block Meldungen herausgeworfen hat. Nun gut, dann verringern wir also entsprechend Anweisung das loopspersec. Und das muss ich dann bis auf 1 !! reduzieren, damit es keine solche Meldung gibt.
Das ist also weit weg von den 100 loopspersec und noch viel weiter weg von den 2000 loopspersec in Version 0.8. Warum, weshalb, wieso?
Also habe ich mal in das bufhrt reingeschaut und versucht zu verstehen was da nun genau passiert. Letztlich gibt der Anwender da ja die loopspersec und die bytespersec vor. Und nun bin ich überzeugt, dass das nicht der richtige Ansatz ist, zumindest dann, wenn der Rechner nicht passt und der Anwender keine Ahnung hat, was er tut sondern nur nachmacht.
Zur Erläuterung ein bisschen Prosa:
Stellen wir uns vor wir arbeiten jeden Tag, unser Chef möchte das Ergebnis des Vortags an jedem Morgen pünktlich um 9 Uhr sehen. Es sei immer diesselbe Arbeit, deren Verrichtung eine gewisse Zeit braucht, z.B. 8 Stunden. Dann kann ich also jeden Tag nach dem Treffen mit dem Chef beginnen und bin um 17 Uhr fertig. Anschliessend habe ich frei, kann irgendwas anderes tun. Zuletzt geh ich schlafen und stell mir den Wecker, so dass ich punktgenau um 9 Uhr am nächsten Tag das Ergebnis übermittle.
Es sollte klar sein, es ist völlig egal, wann ich nach 9 Uhr mit der Arbeit beginne und wann ich damit fertig bin. Ich könnte jede Stunde eine halbe Stunde Pause machen. Oder zwischendurch einkaufen oder was auch immer. Ich könnte auch um 1 Uhr nachts erst mit der Arbeit beginnen. Mein Wecker erinnert mich immer daran, wann 9 Uhr ist und ich übermittle das Arbeitsergebnis.
Also sowas wie der Übergang von einer total geregelten Arbeitszeit zum Homeoffice.
Nun kommt aber die beste Ehefrau von allen und will dass ich was Wichtigeres tue. Ich werde also mit meiner eigentlichen Arbeit gebremst und damit langsamer ... vieeel langsamer. Plötzlich hat der Tag nur noch 5 Stunden für die Arbeit übrig und ich schaffe das 8-Stunden-Pensum nicht mehr.
LOGISCH: es hilft nix mehr, ich kann den Wecker stellen so viel wie ich will, es klappt nicht.
Und dann hilft es auch nicht, wenn mir der Chef vorgibt ich solle schneller schaffen (= Hochsetzen loopspersec oder bytespersec), ich kann ja nur das was ich eben kann. Möglicherweise kirege ich dann die Kündigung und der Chef stellt jemand anderen ein (sprich er nimmt einen schnelleren Rechner).
Und was dann, wenn der Chef keine Ahnung hat (= DAU) und unsinning mit loopspersec und bytespersec rumspielt?
Irgendwie erinnert mich das auch an das Bürokratie-Monster, welches immer größer wird und trotzdem nie das schafft, was es schaffen soll.
Mein Fazit:
Das Pferd muss andersherum aufgezäumt werden.
Ich habe einen beliebigen Rechner mit irgendeiner Rechenleistung. Der soll effektiv Daten wegschreiben und das zeitlich im genauen Raster. Direkt und ohne Zwischenspeichern (Cache). Das geht am besten, wenn ich die Paketgröße verwende, die er naturgemäß selbst anwendet. Bei Datenträgern aller Art sind das heute 4096 Bytes, Wikipedia weiss dazu einiges. Es gibt eine Reihe von Linuxkommandos, die das anzeigen, z.B. stat /dev/sda etc. In Linux heisst das üblicherweise Block. Theoretisch ergibt bytespersec/loopspersec die Blockgröße, in der Version 0.8 waren das 614400/2000 = 3072 Bytes. Was nicht zur nativen Blockgröße passt.
Also definiere ich eine Chunksize, die sinnvollerweise ein geradzahliges Vielfaches der Blockgröße von 4096 sein sollte. Z.B. 4096, 8192, 16384, ...
Oder auch 5 * 4096 = 20480. Letzteres bewirkt also ein 5-maliges Schreiben eines Blocks, auf keinen Fall aber ein Zwischenpuffern, um aus 3072 Bytes brauchbare Blockgrößen zusammenzuflicken.
Damit wird also schon einmal effektiv gearbeitet.
Um nun zu wissen, was der Rechner kann, gibt es eine einfache Lösung: der Rechner ermittelt das selbst, indem er misst. Mache ich 100 loops und messe die Zeit, ist die Zeit für einen loop das Ergebnis geteilt durch 100. Dann braucht der Anwender die Zeit dafür oder den Kehrwert = loopspersec nicht mehr vorzugeben.
Nun benutzen wir ja ein Multitasking-Betriebssystem und dieses funkt ja dazwischen wie die liebe Ehefrau. Also addiere ich auf die gemessene looptime noch eine sinnvollen sleeptime-Wert und schon habe ich die Vorgabe für die repetierende Weckzeit.
Und nun? Am Ende bin ich in die Linux-Welt eingetaucht und habe das bufhrt umgeschrieben. Alles rausgeworfen, was nicht gebraucht wird. Variablen so benamst, dass man verstehen kann, wofür sie geschaffen sind. Dazu, sofern gewünscht, Bildschirmausgaben erzeugt, die den Anwender aufklären, was da passiert und was die CPU leistet.
Und wenn Ihr mögt, könnt Ihr Euch die Version herunterladen und installieren. Das Programm heisst
hrtfilecopy und das Beispielskript
ulifileopt.
Das Projekt gibt es hier. Nicht per git, ich habe davon nicht wirklich Ahnung. Aber es läuft genauso unter Linux, wie bufhrt. Das Makefile ist entsprechend angepasst.
Wer dann mal ins Programm reinschaut bzw. es ohne Parameter aufruft, findet dann noch einige zusätzliche neue Parameter. Was wir derzeit sicher wissen ist, dass das kopierte File bitidentisch ist. Was weiterhin berichtet wurde ist, dass es besser klingen soll. Was bisher keiner erklärt hat, warum. Laut Frank klingt es bei ihm besser, obwohl die Datei als flac noch entpackt, in der Abtastrate gewandelt und anschliessend noch gefiltert wird. Demzufolge scheint die Verbesserung recht robust zu sein. Wird die Datei aber mit einem standard-copy einfach auf ein anderes Laufwerk umkopiert, soll die Verbesserung ja futsch zu sein. Es gibt also noch logisch Unerforschtes. Mit den neuen Parametern kann der Anwender, so sie gesetzt sind, das memclean, das nanosleep, das memoryrefresh und das direkte Schreiben auf die Festplatte einzeln oder in Kombination abschalten und so herausfinden, was denn eigentlich von den Maßnahmen den wichtigen Anteil an Verbesserung bewirkt. Ich fände es spannend, wenn es da Ergebnisse gibt.
Und falls es Verbesserungsvorschläge gibt, natürlich immer her damit.
Einen guten Rutsch und alles Gute für ein gesundes, erfolgreiches und friedliches Neues Jahr 2024 !
Uli
PS: natürlich läuft es mit einem richtigen PC und mit SSD wesentlich effektiver als mit einem Raspberry Pi. Meine AMD-CPU erreicht dann ca. 700 loops bei 4096 Bytes chunksize. Bei 16384 Bytes wird es noch viel schneller. Bei Vorgabe einer buffersitz von 512 MByte passt eine übliche wav-Datei ganz in den Puffer, man könnte den dann theroetisch und auch praktisch in einem Rutsch rausschreiben = kürzeste Bearbeitungszeit. Allerdings braucht dann der Wecker nur einmal zu klingeln und ich weiss nicht ob das dann noch dem Gedanken des Nanosekunden-Timings einzelner Pakete entspricht.
