Der eigentliche Vorteil eines hochauflösenden Digitalsignals mit hohen Abtastraten liegt nicht primär in der Erweiterung des Übertragungsbereichs, sondern erst ein sekundärer Effekt bringt den entscheidenden Vorteil. Je höher die Übertragungsbandbreite eines technischen Übertragungssystems, desto b...

Hallo Frank, 1. da ich mit Windows arbeite habe ich nun mal NTFS-Laufwerke. Soweit ich weiss verwendet Hort zumindes exFAT, ist vielleicht aber auch nicht Linux kompatibel. 2. wenn ich mit isolcpus das Programm auf einem Kern laufen lasse, ich habe darüber berichtet, muss ich ja das Programm per tas...

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

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

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

Bernd Peter hat geschrieben: ↑03.01.2024, 17:01 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

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

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

Mmh, ich stelle derzeit fest, dass wir da mit dem Hochpräzisions-Nanosekunden-Timer zwar eine nette Genauigkeit vortäuschen, in Wirklichkeit aber sowas wie ein Glücksrittertum betreiben. Das Messen der Loops auf meinem NUC ergibt ein durchschnittliches Timing von 1.5 ms pro Loop. Nun kann ich da noc...

Das tut es ja auch, es dauert länger.
16384 Bytes in einem Block werden in 2.8 ms weggeschrieben
16384 Bytes in vier Blöcken á 4096 Bytes dauern 4 * 2.3 ms = 9.2 ms

Grüsse
Uli

Nein,

das liegt daran, dass der Overhead zum Schreiben der Bytes (also das was im Linuxsystem selbst passiert) viel größer ist als das Schreiben der Bytes selbst.
Wenn man viele kleine Pakete packt braucht es zum Einwickeln ins Packpapier länger als bei einem größeren Paket.

Grüsse
Uli

Hallo Horst, wenn die vom mir anhand des Beispiels von Frank aufgezeigte Laufzeitverlängerung von ca. 10 ms bei 32.7 s Gesamtlaufzeit schädlich ist, dann gibt es diese Möglichkeit: es wird ja auch beim Beispiel angezeigt, dass die automatische Messung 1.63 ms je Loop braucht. Da wurde dann inkl. Sle...

Hallo Frank, da es hier beim improvefile um Dateien geht und ich das Programm dann selbst auch hrtfilecopy genannt habe war zumindest für mich der Rauswurf aller nicht benötigten Codezeilen eine klare Sache. Das Problem bei der Vorgabe von bytespersec und loopspersec: spätestens mit den delayed bloc...

Hallo Horst,

bitte nochmal herunterladen. Es sollte nun klappen.

Grüsse
Uli

Danke für den Hinweis. Ja klar, die kopierte Musikdatei ist bitidentisch. Das Programm definitiv nicht. Vielleicht kann die Moderation das korrigieren. Oder? [Erbsenzählermodus on] Das hrtfilecopy ist nicht bitidentisch zu bufhrt. Wenn man aber das Programm hrtfilecopy oder auch bufhrt mit dem Progr...