On 05/07/2012 02:06 PM, Kaj Ailomaa wrote:
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(?),
> if passing the threadirqs option to the kernel at boot, and having built
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:
> From my experience, I have not had any performance boost using the rtirq
There won't be any performance boost. In general performance decreases
(minimum and average latency increases) but reliability increases (max
> So, I'm wondering. What picture do others have of the benefit of the
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
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
That's only helpful to debug the rtirq script or its config. It does not
There's kernel tracers but most of these will interfere with the
measurement. There's also the rt-test-suite:
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.
Linux-audio-user mailing list