Software-Experimente mit Linux

[Buschel]

Moin,

Was ich mich immer wieder frage: Überschreibt der automatisch laufende RAM refresh nicht sowieso alle Speicherzellen neu bevor die Bits an USB- oder Ethernet-Controller weitergegeben werden?

Ein weiterer Gedanke dazu: ich habe hier oft gelesen, dass kleinere Puffer am Ausgangstreiber bevorzugt werden. Bei kleineren Puffern von <32 ms (oder 64 ms, je nach Speicherchip) würden anteilig mehr Speicherzellen vor dem RAM refresh weitergegeben werden -- also im Originalzustand.

Beispiel: Bei einem Puffer von 4 ms werden alle im Schnitt 32 ms 4 ms Daten "RAM refreshed". Die anderen 28 ms Daten bleiben unangetastet.

Morgendliche Grüße,
Andree

[uli.brueggemann]

Ich habe nun die Version 0.3 von hrtfilecopy auf den Server hochgeladen (Download).
Damit bin ich vorerst mal fertig. Wie berichtet spuckt das Betriebssystem gern dazwischen und ändert damit das gewünschte Timing.
Insofern ist das Prinzip etwas geändert bzw. angepasst. Wenn also das Programm aufs Linux warten muss ist damit die aktuelle Looptime überschritten. Da kannste nix mehr tun als es eben zu akzeptieren. Der Sleeptimer wird dann aber entsprechend angepasst und es kann wie gewünscht weitergehen.
Zusätzlich läuft ein Zähler, der mitzählt, wie oft es denn doch passt.
Am Ende bekomme ich damit meistens um 99.7% richtige Looptimes für das Schreiben der Daten auf die Disk.
Das heisst bei enem Track mit 12000 Chunks á 4096 Bytes (46 MB), dass 11964 Chunks richtig "getimed" wurden und 36 Chunks eben nicht.

Nichsdestotrotz, das ist klar besser als die ominösen 42% delayed blocks welche von Frank berichtet wurden.

Natürlich wären Erfahrungsberichte prima.

Grüsse
Uli

[Trinnov]

Hallo Uli,

reicht es wenn man hrtfilecopy austauscht und kompiliert?

Viele Grüße
Horst

[Trinnov]

Nichsdestotrotz, das ist klar besser als die ominösen 42% delayed blocks welche von Frank berichtet wurden.

Es wäre gut, wenn deine Software die Info ausgeben würde, sobald ein delayed block entsteht, also ein Block nicht im richtigen Timing ist.
Frank hatte es testweise doch auch in deine SW eingebaut. Also ist es möglich.

Steht jetzt bei der Nutzung der 0.3 Version im Header beim Improven version 0.3 oder 0.2 ?

Viele Grüße
Horst

[uli.brueggemann]

Hallo Horst,

im Header steht 0.3 wenn in der Datei version.h und im Makefile beim Compilieren ebenfalls 0.3 angegeben ist. Das hrtfilecopy besorgt sich die Info genau von da.

Wo genau Frank das mit den delayed block in hertfilecopy eingebaut hat, hat er nicht angegeben, ich will da auch nicht rumraten.
Es ist mir ein bisschen egal, was hift es wenn da x-mal eine Ausgabe a, Bildschirm erfolgt. Und wie Frank die 42% ermittelt hat, hat er ja auch nicht gesagt, er hat bestimmt nicht die Ausgaben am Bildschirm mitgezählt.

Und so gibt hrtfilecoy am Ende eben einen match-Wert aus, z.B. 99.7%. Aus den 0.3% und der Anzahl der Chunks weisst Du ebenfalls die delayed blocks, was für mich dann Blöcke sind, die das Betriebssystem und nicht das Programm verzögert hat.

Grüsse
Uli

[Bernd Peter]

match: 99,7%

Hoffe, das ist kein Festwert, Uli, Du Spaßvogel?

[uli.brueggemann]

match: 99,7%

Hoffe, das ist kein Festwert, Uli, Du Spaßvogel?

Guck doch rein ins Programm Wer lesen kann ist deutlich im Vorteil.

Grüsse
Uli

[Bernd Peter]

Hallo Uli,

time/loops (ms) schwanken recht stark zwischen 1.837052 und 3.181855 bei insgesamt 8 improveden Musikfiles.

Klanglich eine auf den ersten Eindruck hin sehr gute Performance schon bei 1xImproven.

Schlage hier Michael Jacksons "Thriller" als Testtitel vor, gleich zu Beginn geht da eine Tür knärzend auf.

Es grüßt

Bernd Peter

[uli.brueggemann]

Es wird am Anfang mit einem Test über 20 Chunks gemessen und gemittelt. Je nachdem was sich da gerade ergibt schwankt insofern die looptime.
Du kannst das nun aber ja bei mehreren Dateien erkennen, was sich dann beim Testlauf ergeben hat und ob z.B. bei dem kleineren Wert von 1.8 ms ein niedrigerer Match ergibt. Falls nicht, änderst Du den Aufruf im Skript passend dazu mit dem Parameter z.B. --looptime=1.8
Dann wird ab dann immer 1.8 ms verwendet und der Testlauf erst gar nicht ausgeführt.
Mir war es letztlich wichtig, dass jemand ohne irgendeine Erfahrung das Prog verwenden kann und es nicht unsinnige Parameter verwendet. Die kannst Du natürlich auch immer noch angeben, wenn Du möchtest

Zumindest prima, dass Du schon mal eine positive Performance berichtest.

Grüsse
Uli

[Bernd Peter]

Hallo Uli,

Mir war es letztlich wichtig, dass jemand ohne irgendeine Erfahrung das Prog verwenden kann und es nicht unsinnige Parameter verwendet.

das ist natürlich eine echte Hilfe, kann man das noch verfeinern?

Es grüßt

Bernd Peter

[Trinnov]

Da du es jetzt auch erwähnst, möchte ich Uli dazu anspornen den Timing Test zu verfeinern.

Gehen wir mal beispielhaft davon aus, dass bei einem 44.1/16 Track bei einer Blockgröße von 4096 Bytes ungefähr 10.000 Blöcke zu schreiben sind.
Macht man einen Timing Test mit nur 10 oder 20 Blöcken, dann sind das nur 0,1 bzw. 0,2% aller zu schreibenden Blöcke.
Bei meinen Versuchen mit einem langsamen USB Stick, habe ich durchgehend nur einen Match von 93 - 95%
Die gemessene Loop time entspricht dabei auch mit Sicherheitszuschlag nie der in "results" ausgegebenen tatsächlichen loop time.
Wenn das bei sagen wir mal 100 Tracks immer so daneben ist, sollte man die Auslegung des Timing Tests überdenken.
Ich hatte tatsächlich einen Durchlauf dabei, bei dem der per Timing Test geschätzte Wert annähernd dem tatsächlichen Wert entsprach.
Somit hatte ich eine Match Ausgabe von 100%

Zwei Schritte schlage ich vor.
Um hier weiter zu kommen, benötige ich für die nächsten Tests zwei Versionen von hrtfilecopy und zwar mit 100 Chunks und mit 500 Chunks, statt 10 oder 20 Chunks default Wert. Gerne auch erst mal per Mail.
Somit werde ich hoffentlich sehr oft auf Match 100% kommen. Es muss also gleichzeitig das Match Ausgabeformat angepasst werden. Bitte eine oder besser zwei Stellen mehr, damit z.B. tatsächliche 99,95% nicht auf 100% aufgerundet werden.

Da ich mittlerweile Haralds (nihil.sine.causa) extrem nützliches Multi-Improve Bedien-Script auf das ulifileopt Script angepasst habe, kann ich sehr elegant die Anzahl der Improve Durchläufe sowie Chunk Size und Buffer Size für Ulis Software und Script in Haralds Bedien-Script festlegen und ein Mehrfach Improve (freie Anzahl-Eingabe bis 10-fach) von großen Ordnern mit einem einzigen Befehl starten.
Da Haralds Script beim Mehrfach Improve temporäre Files schreibt und auch zeitnah wieder löscht sobald nicht mehr benötigt, verbraucht das Mehrfach Improve kaum zusätzlichen Speicherplatz. Es muss für die zu schreibenden Temp Dateien nur genau einmal die Größe des größten zu improvenden Audio Files auf der SSD zusätzlich frei sein.
Der so optimierte Workflow muss auch unbedingt zum Standard werden, damit das Improven vom Ablauf her auf Dauer wirklich frustfrei abläuft.
Ein Aufruf von Haralds nscn.sh bewirkt also nscn.sh -> ulifileopt -> hrtfilecopy

Uli, herzlichen Dank im Voraus!


Viele Grüße
Horst

[uli.brueggemann]

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.

[Trinnov]

Hallo Uli,

laut meiner aktuellen Tests es nicht möglich mit dem in der Software eingesetzten Timing Test die loop time (ms) zu ermitteln, die tatsächlich benötigt wird um keine delayed blocks zu erzeugen. Selbst mit man mit 5000 Chunks testet, wird das nichts.
Aber ich wollte es ja wissen, daher war die testweise Verlängerung der Testschleife für mich wichtig.

Somit habe ich nun die die Automatik durch Eingabe einer festen Loop time verlassen.
Allerdings benötigt man eine sehr hohe Loop time, die so ca. Faktor 10 höher liegt, als das was die Automatik ermittelt hatte.
Damit bekomme ich dann bei jedem Durchgang sichere 100,000% (= zero delayed blocks). Kein Aufrunden !

Interessanterweise entspricht die Anzahl der Loops per Second ziemlich genau dem was ich bei Franks Software einstellen muss, um delayed blocks zu vermeiden, also im geforderten Timing zu bleiben.

Die Kehrseite der Medaille ist die dann bei deiner Software jedoch sehr lange total loop time. Sogar bei einem 44.1/16 Track ist die Wartezeit bei einem langsamen USB-Stick extrem. Ich komme mit einer 89 MB großem Track selbst bei 16384 Chunk Size auf 489 Sekunden.


Viele Grüße
Horst

[Trinnov]

So schauen die beiden Durchgänge des Double Improve aus.

1.jpg (159.79 KiB) 3871 mal betrachtet

2.jpg (156.28 KiB) 3871 mal betrachtet

Viele Grüße
Horst

[Trinnov]

Hallo Uli,

das Ergebnis gefällt mir erstmals bei deiner Software klanglich extrem gut.
Sehr saubere und ruhige Bühnenabbildung. Möglicherweise das beste double Improve, das ich bislang gehört habe. Aber vielleicht lohnt da die lange Durchlaufzeit (= kleiner "Bytes per second" Wert). Das müssen wir noch herausfinden.
Verglichen mit dem Original verwischt da jetzt nichts mehr. Sehr gute Präzision und Abbildungsruhe. Das Hören ist somit auch noch langzeittauglicher, einfacher.
Allerdings aktuell nur über den Büro-PC beurteilt. Die große Anlage ist noch eine zeitlang außer Betrieb.

Uli, jetzt musst du noch die Möglichkeit einbauen die "Bytes per Second" im ulifileopt Script festzulegen.
Von Franks Software wissen wir schon eine Weile, dass je nach möglicher Transferrate des Datenträgers eine gewisser maximal möglicher Wert bei den "loops per second" beachtet werden muss, um "delayed blocks" vollständig zu vermeiden. Je nach tolerierter Improve Zeit pro Track muss nun der "bytes per second" Wert festgelegt werden. Ein kleiner Wert bedeutet logischerweise eine lange Durchlaufzeit pro Track.
Aber mehr Bytes per second erhöhen nicht die Anzahl der "delayed blocks" und das ist das erfreuliche dabei. Zumindest ist das bei Franks Version so.
Das müssten wir nun auch bei deiner Software prüfen.


Viele Grüße
Horst