[LAU] rtirq - what does it improve, and how can I measure it?

Robin Gareus robin at gareus.org
Mon May 7 12:54:57 UTC 2012

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

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

  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.


More information about the Linux-audio-user mailing list