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.
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).
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!
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.tar.gz).
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).
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.
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: 0Post new comment