Verfasst: 04.01.2024, 23:43
Hallo Uli,
hier ein paar Kommentare zur vorhergehenden Diskussion.
Im Deinem letzten Beitrag sehe ich, dass Du auf NTFS Dateisystemen (Windows) arbeitest. Ich erinnere mich, dass es ziemlich lange gedauert hatte, bis Linux die überhaupt lesen konnte und noch länger, bis darauf von Linux auch geschrieben werden konnte. Vielleicht liegt es auch an diesem Interface, dass Du so große Ausreißer beim Timing beobachtest (viel größer, als ich bei mir nachvollziehen kann - bei mir sind auf allen Datenträgern ext4 oder ext2 Dateisysteme).
Dein Schluss, dass nach Deinen Beobachtungen die highres-Timer in Linux Mist sind, ist nicht richtig. Dieses Thema hatten wir ja in diesem Thread schon früher diskutiert. Auf meinem Raspi 4 auf einem isolierten CPU Kern wachen fast alle nanosleeps mit (oft viel) weniger als 250ns Abweichung von der Zielzeit auf, und im Mittel über einige Sekunden mit 0ns. (Ich habe jetzt eine einfache Testschleife in 'highrestest' eingebaut, z.B. mit Argument '500' aufrufen.)
Die Version 0.3 Deines Programs hat das Problem, dass es von einem normalen Linux User nicht aufgerufen werden kann. Du setzt die Realtime (FIFO) Priorität, was normalerweise nur root erlaubt ist. So eine Priorität wird besser außerhalb des Programs gesetzt, die muss ja auch relativ zu anderen laufenden Prozessen gewählt werden. Ich mache das bei mir so, dass ich auf den Audiorechnern das SetUID Bit für 'chrt' setze (einmalig 'sudo chmod 4755 /bin/chrt'). Dann kann jeder User z.B. mit 'chrt -f 70 hrtfilecopy ....' Dein Programm starten. (-f 70 ist übrigens oft eine gute Wahl.)
Ich habe auch einen Hörvergleich, allerdings mit nur wenigen Dateien, gemacht. Dabei funktioniert 'hrtfilecopy' auch sehr gut, das Ergebnis ist ähnlich wie mit der bufhrt Version von vor Weihnachten. Einen großen Unterschied zwischen Version 0.1 und 0.3 konnte ich auf Anhieb nicht feststellen. Ach ja, der "match" ist auf meinem Notebook so 75-80% und auf dem Raspi 4 um die 90%
Viele Grüße,
Frank
hier ein paar Kommentare zur vorhergehenden Diskussion.
Im Deinem letzten Beitrag sehe ich, dass Du auf NTFS Dateisystemen (Windows) arbeitest. Ich erinnere mich, dass es ziemlich lange gedauert hatte, bis Linux die überhaupt lesen konnte und noch länger, bis darauf von Linux auch geschrieben werden konnte. Vielleicht liegt es auch an diesem Interface, dass Du so große Ausreißer beim Timing beobachtest (viel größer, als ich bei mir nachvollziehen kann - bei mir sind auf allen Datenträgern ext4 oder ext2 Dateisysteme).
Dein Schluss, dass nach Deinen Beobachtungen die highres-Timer in Linux Mist sind, ist nicht richtig. Dieses Thema hatten wir ja in diesem Thread schon früher diskutiert. Auf meinem Raspi 4 auf einem isolierten CPU Kern wachen fast alle nanosleeps mit (oft viel) weniger als 250ns Abweichung von der Zielzeit auf, und im Mittel über einige Sekunden mit 0ns. (Ich habe jetzt eine einfache Testschleife in 'highrestest' eingebaut, z.B. mit Argument '500' aufrufen.)
Die Version 0.3 Deines Programs hat das Problem, dass es von einem normalen Linux User nicht aufgerufen werden kann. Du setzt die Realtime (FIFO) Priorität, was normalerweise nur root erlaubt ist. So eine Priorität wird besser außerhalb des Programs gesetzt, die muss ja auch relativ zu anderen laufenden Prozessen gewählt werden. Ich mache das bei mir so, dass ich auf den Audiorechnern das SetUID Bit für 'chrt' setze (einmalig 'sudo chmod 4755 /bin/chrt'). Dann kann jeder User z.B. mit 'chrt -f 70 hrtfilecopy ....' Dein Programm starten. (-f 70 ist übrigens oft eine gute Wahl.)
Ich habe auch einen Hörvergleich, allerdings mit nur wenigen Dateien, gemacht. Dabei funktioniert 'hrtfilecopy' auch sehr gut, das Ergebnis ist ähnlich wie mit der bufhrt Version von vor Weihnachten. Einen großen Unterschied zwischen Version 0.1 und 0.3 konnte ich auf Anhieb nicht feststellen. Ach ja, der "match" ist auf meinem Notebook so 75-80% und auf dem Raspi 4 um die 90%
Viele Grüße,
Frank