You are here

rtirq

Hey,
I was told that rtirq depends on the kernel used!!
I'm using kernel26rt-2.6.26.5_rt9...

Forums: 
rncbc's picture

It's not quite whether it depends, but it only makes sense on a PREEMPT_RT patched kernel (a.k.a. realtime-preempt, Ingo Molnar's RT-patchset) which I think you have. Otherwise it just does nothing.

What was actually the question? :)

a guy at my distro's forum said that rtirq depends on the kernel version. I guess he didn't know if it was as long as it's patched with Molnar's RT-patchset which it is.
the reason I want to use rtirq is to speed up my system. I have an amd1.7bg cpu with 1gb ram yet when using jconv to run IR files larger that 100kb, I get crazy mad xruns and the system becomes unusable.
someone at linuxmusicians.com suggested that I try to put higher priority on the soundcard irq.

rncbc's picture

You can find the latest and original here (rtirq-20071012 ATTOW).

rtirq is a simple init script, which main purpose is about to setup IRQ service thread priorities in such a reasonable ordering for general audio workstation. That might be just what you're after, indeed.

The way it should be installed depends on your distro, although it tries to comply with LSB. If your distro packaging is RPM based, then you're lucky as me and it suffices to install the .rpm package, also available from here (rtirq-20071012-19.noarch.rpm ATTOW).

The main purpose is all about fixing the IRQ thread RT priorities (SCHED_FIFO) in some configurable but generic order (no magic hardwired numbers:).

Just check the installed configuration on /etc/sysconfig/rtirq (formerly rtirq.conf), and edit if you see fit. The default priority order goes as follows:

  • 90 - rtc - real-time clock (usually IRQ 8)
  • 80 - snd - ALSA PCI sound modules (usually IRQ 5, 17 and/or 22 ...)
  • 70 - usb - USB host controllers (usually IRQ 10, 16, 18, 19 and/or 23 ...)
  • 60 - i8042 - keyboard/ps2-mouse controllers (usually IRQ 1 and/or 12 ...)

This setup has proven to be quite stable and reliable, as long as jackd -R... runs with few or no xruns, near very low-latency (e.g. -p64) for most general and practical audio setups. It works for me, either on PCI or USB audio interfaces. Note that, if your sound device is firewire you'll need to inscribe ohci1394 in the main configuration line (see /etc/sysconfig/rtirq), like changing it from:
RTIRQ_NAME_LIST="rtc snd usb i8042"
to:
RTIRQ_NAME_LIST="rtc ohci1394 snd usb i8042"
there you'll have (all) firewire devices serviced with higher priority then all the rest.

Note that the main LSB script /etc/init.d/rtirq is originally packaged as rtirq.sh, and if your distro instructs you to place the configuration file somewhere else but the standard, you'll need to edit it and change the RTIRQ_CONFIG script variable accordingly.

Cheers.

You could use an UDEV rule to run the script? That way everytime a soundcard appears, the script is automatically run.

I think I was unclear when I posted that rtirq depended on what *kernel* you are running. What I meant was the config is dependent on the kernel and the patchset. Just for comparison can you guys post up the following please?

ps -e | grep timer <---- I suspect different patchsets will show different results here
cat /proc/interrupts <---Same here I think....is RTC depreciated now? Is there a *new* RTC system?
uname -a <----obvious :)

I'll post mine up when I get home from work.
Thanks for all your work Rui, we appreciate it!

(and hello funkmuscle heheh)

Ben

Here's the info on my hyperthreaded dual p4 box:

$uname -a
Linux h3apI 2.6.24-rt #1 SMP PREEMPT RT Fri Oct 24 20:05:28 PDT 2008 i686 Intel(R) XEON(TM) CPU 2.40GHz GenuineIntel GNU/Linux

That's patched with Ingos rt21 set.

$ps -e | grep timer
    4 ?        00:00:00 posix_cpu_timer
    6 ?        00:09:22 sirq-timer/0
   12 ?        00:00:00 sirq-hrtimer/0
   16 ?        00:00:00 posix_cpu_timer
   18 ?        00:09:47 sirq-timer/1
   24 ?        00:00:00 sirq-hrtimer/1
   28 ?        00:00:00 posix_cpu_timer
   30 ?        00:09:02 sirq-timer/2
   36 ?        00:00:00 sirq-hrtimer/2
   40 ?        00:00:00 posix_cpu_timer
   42 ?        00:08:36 sirq-timer/3
   48 ?        00:00:00 sirq-hrtimer/3

$cat /proc/interrupts 
           CPU0       CPU1       CPU2       CPU3       
  0:        494          0          0          0   IO-APIC-edge      timer
  1:      27921       6850          0       2513   IO-APIC-edge      i8042
  2:          0          0          0          0    XT-PIC-XT        cascade
  8:          0          0          0          0   IO-APIC-edge      rtc
 12:    1845583     322255      72671      33572   IO-APIC-edge      i8042
 14:     347395      23661       3632          0   IO-APIC-edge      ide0
 15:         88          0          0          0   IO-APIC-edge      ide1
 16:          0          0          0          0   IO-APIC-fasteoi   radeon@pci:                  0000:01:00.0
 18:   15703931   13593767      14182     639202   IO-APIC-fasteoi   ICE1712
 19:         30          0          0          0   IO-APIC-fasteoi   sym53c8xx
 21:    3945340    1262316     242087          0   IO-APIC-fasteoi   eth0
 23:      23850          0          0          0   IO-APIC-fasteoi   sym53c8xx
NMI:          0          0          0          0   Non-maskable interrupts
LOC:  252239131  252239065  252239045  252239024   Local timer interrupts
RES:   31462863   28528083   43355488   24139603   Rescheduling interrupts
CAL:     279909     280300     286130     292476   function call interrupts
TLB:      79244      68155      70767      75887   TLB shootdowns
TRM:          0          0          0          0   Thermal event interrupts
SPU:          0          0          0          0   Spurious interrupts
ERR:          0
MIS:          0

(I'm running Ubuntu 9.10 Karmic, but also tested this on Jaunty)

For some reason, the real time clock (on IRQ 8) only has its priority set to 50 when the settings are default, which is:
RTIRQ_NAME_LIST="rtc snd usb i8042"

rtc0 is how it shows up when running:
ps -eLo pid,cls,rtprio,pri,nice,cmd | grep -i "irq"
as instructed on the ffado wiki page.

If I change the settings to:
RTIRQ_NAME_LIST="rtc0 snd usb i8042"
Then it gets prioritized properly.

Should rtirq set things properly even when the 0 is omitted, or is it supposed to be necessary to say 'rtc0' instead of just 'rtc'?

Thanks,
trulan

rncbc's picture

You should update your rtirq script as this has been fixed some time ago already (see here for the most recent).

Cheers

Thanks. I'll file a bug on Launchpad for the Ubuntu guys in hopes that they update it for everybody.

trulan

This is a fantastic script - and the fact that the configuration now shows up in /etc/sysconfig in YaST is great! - but it's probably worth mentioning that you need to know the name of your sound-card.

I'd spent ages leaving the script alone with

RTIRQ_NAME_LIST="rtc0 snd usb i8042"

But of course if I do cat /proc/interrupts, snd is not listed at all. My sound-card is called "Intel 82801CA-ICH3", so I needed to enter

RTIRQ_NAME_LIST="rtc0 Intel usb i8042"

To set the IRQ appropriately.

Many thanks for all the work you do!

rncbc's picture

The "snd" particle is just one special and generic symbol that represents ANY or all of your internal sound-cards, in case you have more than one (I do have 3:). Of course you can now replace "snd" with your specific sound-card name (eg. "'HDA Intel'" or just "Intel") but take care that's only feasible on latest kernel-rt >= 2.6.31-rt and rtirq >= 20090920.

Cheers

Actually the snd service name does not work properly, because the soundcard name does not always match the interrupt name:

---- rtirq.sh
start :: snd :: M Audio Audiophile 24/96 :: 85 :: 20
start :: snd :: SB Live! 5.1 [SB0060] (rev.7, serial:0x80611102) :: 84 :: 19
start :: snd :: HDA Intel :: 83 :: 30
Setting IRQ priorities: start [HDA Intel] irq=30 pid=1649 prio=83: OK.
---- /proc/interrupts
19: ... IO-APIC-fasteoi uhci_hcd:usb5, EMU10K1, ide0, ide1
20: ... IO-APIC-fasteoi ICE1712
30: ... PCI-MSI-edge HDA Intel
----

So the device I actually care about, the ICE1712, doesn't get altered.

rncbc's picture

rtirq should touch all the 3 sound-cards you seem to have: "HDA Intel", "M Audio Audiophile 24/96" (ICE1712) and the "SB Live! 5.1" (EMU10K1), not necessarily in this order. However it looks like it's only the HDA Intel that gets honored. Is that true?

hny

Just leaving a message to say that rtirq really enhanced my audio production experience. With the help of this script I managed to further stabilize my systems and they're pretty rock solid now. So, many thanks!!

Best,

Jeremy

rncbc's picture

@AudioStatic

Way to go.

Now its your turn to give back and help the script :) You must have noticed the lack of a lousy README, ain't you? How about helping me putting one together? ;) Sure this uber-procrastinator of yours will give you (yet another) thankful and kind appreciation, indeed.

(No joking. someone should really put down a pen on this little tiny beast)

Cheers

Hello Rui,

I already wrote a simple Dutch howto for rtirq so an English README should be possible. But as I am in the middle of a renovation, about to become a father, playing in two bands, preparing a DJ set for New Year's Eve and writing/composing for myself I hope I can find the time to do so...

Jeremy

rncbc's picture

Awe! Happy new year, already!

Hello Rui, best wishes to you too! I'd like to donate to the rtirq script because it was the final step in gaining full control over my systems. What is the best way to do so? Otherwise I'll donate to Qtractor again and specify that it's actually about rtirq.

Best,

Jeremy

rncbc's picture

Your donation is perfectly welcome ntl, only if that doesn't compromise your accepted challenge ;)

Happy holidays!

No it won't :) And you too, happy holidays!

Jeremy

rncbc's picture

Thanks for donating. Best wishes and a happy New Year to y'all.

You're welcome, and as you can see on the Qtractor project page, my donation seriously screwed up some timelines and ended up somewhere in the past.

Jeremy

rncbc's picture

Indeed. somehow SF screw the donations listing, although they seem to be sorted correctly, still. Only that some lines are displayed as of zero unix epoch time. Oh wait... may that be the Y2K38 bug creeping already? bwahahahah

Cheers

Hi Rui,

What does this mean? RTIRQ_NON_THREADED

I don't fully understand the comment in the conf file. I have a modern kernel, 2.6.31-rt (linux-rt for karmic and lucid). I can see threads in htop.

Is it right to think that you should put in that variable the devices which are not sharing irq number with others and you should ommit the ones you see in /proc/interrupts with two or more "things" in the same irq number?
All of this as long you as have a modern rt-kernel, beginning from version number ...??
Am I missing something?

Thanks a lot for your work, Rui. You rock!

rncbc's picture

Back in the days of the voluntary preempt kernel patch, there was this option to let some of the soft-IRQ service routines non threaded. I fail to tell whether it's still applicable nowadays to the PREEMPT_VOLUNTARY and PREEMPT_DESKTOP kernel configurations, which are in fact the direct remnants from those days (4-5 years ago?).

Truth is, the rtirq.conf option in subject doesn't mean a thing on PREEMPT_RT kernels and never did, so you can just ignore its intent and original purpose anyhow.

Cheers

Thank you very much! Then I think I will comment that line out.

Cheers! Pablo

How useful rtirq script would be in the recent kernel (as in Lucid Lunx Ubuntu Studio PREEMPT (corresponds to config option config_preemtp ) ?
Or can someone do anything usefull for audio work stability on twiddling priorities ?

rncbc's picture

rtirq does its magic on PREEMPT_RT kernels only!

all else is pure noop

hth :)
cheers

AutoStatic's picture

Hello Teemu Kurki,

You need the 2.6.31-11-rt real-time kernel in order to be able to use rtirq. An apt-get install linux-rt should pull that in.

Best,

Jeremy

Hi !

I understand that rt-kernel is needed to get ultimate low audio latency, but I heard that there will be problems to use NVIDIA video cards, and related drivers simultaneously. Therefore I thought if the new PREEMPT_CONFIG could bet close to -rt if priorities are adjusted. I acknowledge that the current rtirq script is not able to handle the priority adjustements for that case. Reason being at least the different format of kernel process names.

Pages

Add new comment