Hi Kaj, On 05/07/2012 02:06 PM, Kaj Ailomaa wrote: > I understand that the rtirq script is designed to raise rtprio for audio > devices, It is designed to prioritize tasklet threads (here: the bottom half of any IRQ handler). By default rtirq increases the priority of timer and audio-device irq-handlers, but it can be configured to do favor any device. > which is made possible on the vanilla kernel since 2.6.39(?), yes. 2.6.39. > if passing the threadirqs option to the kernel at boot, and having built > it with the CONFIG_FORCE_THREADIRQ. Correct for vanilla Linux. With linux >= 3.0 and the preemt-RT patch, you don't need the 'threadirq' option with CONFIG_FORCE_THREADIRQ=y: http://anonscm.debian.org/viewvc/kernel/dists/trunk/linux-2.6/debian/patches/features/all/rt/genirq-force-threading.patch?revision=18299&view=markup > From my experience, I have not had any performance boost using the rtirq > script, but I have read about it helping those who are getting xruns due > to irq sharing. There won't be any performance boost. In general performance decreases (minimum and average latency increases) but reliability increases (max latency decreases). > So, I'm wondering. What picture do others have of the benefit of the > rtirq script? Rui's rtirq script is great: a simple tool to tune your system for reliable audio work. > ..and are there other ways to measure improvement for audio operation > other than spotting xruns at different latency settings, Not really. The overall complexity of the system is vast. unit-testing is not really an option for sound. Put some load your system and do some usual [audio] work, keep the system running for a few hours/days and see if there are still no x-runs.. > and reading the > rtprio for various devices using the 'ps' command? That's only helpful to debug the rtirq script or its config. It does not measure anything. There's kernel tracers but most of these will interfere with the measurement. There's also the rt-test-suite: https://github.com/clrkwllms/rt-tests cyclictest -t1 -p 80 -n -i 1000 -l 10000 -m will benchmark min, max and avg latency of your system, although you should probably run it longer than 10000 iterations (here 10sec: 10000 iterations * 1000 us). It that does not directly relate to IRQ priority. HTH, robin _______________________________________________ Linux-audio-user mailing list Linux-audio-user@xxxxxxxxxxxxxxxxxxxx http://lists.linuxaudio.org/listinfo/linux-audio-user
