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.
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.
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:
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.
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!
(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'?
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
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.
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?
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!!
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)
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...
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.
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
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?
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.
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 ?
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.
Re: rtirq
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
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.
Re: rtirq usage
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(formerlyrtirq.conf), and edit if you see fit. The default priority order goes as follows:rtc- real-time clock (usually IRQ 8)snd- ALSA PCI sound modules (usually IRQ 5, 17 and/or 22 ...)usb- USB host controllers (usually IRQ 10, 16, 18, 19 and/or 23 ...)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 inscribeohci1394in 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/rtirqis originally packaged asrtirq.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 theRTIRQ_CONFIGscript variable accordingly.Cheers.
Use an UDEV rule to run the script?
You could use an UDEV rule to run the script? That way everytime a soundcard appears, the script is automatically run.
I think I am the source of confusion here :)
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
Here's the info on my hyperthreaded dual p4 box:
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: 0rtirq on Ubuntu Studio - rtc vs. rtc0
(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
Re: rtirq on Ubuntu Studio - rtc vs. rtc0
You should update your rtirq script as this has been fixed some time ago already (see here for the most recent).
Cheers
OK
Thanks. I'll file a bug on Launchpad for the Ubuntu guys in hopes that they update it for everybody.
trulan
Know your sound-card!
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!
Re: Know your sound-card!
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
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.
Re: snd service name
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
rtirq saved my day!
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
Re: rtirq saved my day!
@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
Challenge accepted!
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
Re: Challenge accepted!
Awe! Happy new year, already!
Best wishes too!
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
Re: Best wishes too!
Your donation is perfectly welcome ntl, only if that doesn't compromise your accepted challenge ;)
Happy holidays!
No worries
No it won't :) And you too, happy holidays!
Jeremy
Re: No worries
Thanks for donating. Best wishes and a happy New Year to y'all.
Donation issues
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
Re: Donation issues
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
RTIRQ_NON_THREADED
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!
Re: RTIRQ_NON_THREADED
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
Re: Re: RTIRQ_NON_THREADED
Thank you very much! Then I think I will comment that line out.
Cheers! Pablo
rtirq usage in PREEMPT kernel ?
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 ?
Re: rtirq usage in PREEMPT kernel ?
rtirq does its magic on PREEMPT_RT kernels only!
all else is pure noop
hth :)
cheers
2.6.31-11-rt kernel
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
Perhaps more generally...
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