29 Oct
2015
29 Oct
'15
6:28 a.m.
On Debian/Ubuntu systems, the irqbalance package which tries to push
interrupts across all your CPU's fairly, has been part of the base
system for a long time. On Gentoo, it's an available package, but not
installed by default.
Is irqbalance recommended for RT audio? Deprecated? Doesn't matter?
12 Nov
12 Nov
6:30 a.m.
2015-10-29 6:28 GMT+01:00 Brent Busby <brent(a)keycorner.org>rg>:
On Debian/Ubuntu systems, the irqbalance package which
tries to push
interrupts across all your CPU's fairly, has been part of the base
system for a long time. On Gentoo, it's an available package, but not
installed by default.
Is irqbalance recommended for RT audio? Deprecated? Doesn't matter?
Why not just use rtirq?
http://alsa.opensrc.org/Rtirq
21 Nov
21 Nov
11:32 a.m.
On 11/12/2015 06:30 AM, Raffaele Morelli wrote:
2015-10-29 6:28 GMT+01:00 Brent Busby
<brent(a)keycorner.org>rg>:
rtirq and irqbalance are different things. rtirq allows one to assign
priorities to softirqs while irqbalance balances IRQ requests between
CPU's. On a Linux audio system you would need both.
Jeremy
On Debian/Ubuntu systems, the irqbalance package
which tries to push
interrupts across all your CPU's fairly, has been part of the base
system for a long time. On Gentoo, it's an available package, but not
installed by default.
Is irqbalance recommended for RT audio? Deprecated? Doesn't matter?
Why not just use rtirq?
http://alsa.opensrc.org/Rtirq
11:30 a.m.
On 10/29/2015 06:28 AM, Brent Busby wrote:
On Debian/Ubuntu systems, the irqbalance package which
tries to push
interrupts across all your CPU's fairly, has been part of the base
system for a long time. On Gentoo, it's an available package, but not
installed by default.
Is irqbalance recommended for RT audio? Deprecated? Doesn't matter?
From what I know of irqbalance I would recommend using it in all cases
on a multi-core system. If you don't use it all IRQ request will be
handled by cpu0 which degrades performance of your system. When you use
CPU pinning you don't need it of course but I've never encountered
anyone using this on his desktop system.
Jeremy
11:42 a.m.
Am 21.11.2015 um 11:30 schrieb Jeremy Jongepier:
On 10/29/2015 06:28 AM, Brent Busby wrote:
I prefer to not use irqbalance and have de-installed it.
As a reference read here:
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_MRG/1.3/ht…
On Debian/Ubuntu systems, the irqbalance package
which tries to push
interrupts across all your CPU's fairly, has been part of the base
system for a long time. On Gentoo, it's an available package, but not
installed by default.
Is irqbalance recommended for RT audio? Deprecated? Doesn't matter?
From
what I know of irqbalance I would recommend using it in all cases
on a multi-core system. If you don't use it all IRQ request will be
handled by cpu0 which degrades performance of your system. When you use
CPU pinning you don't need it of course but I've never encountered
anyone using this on his desktop system.
Jeremy
11:57 a.m.
On 11/21/2015 11:42 AM, Hermann Meyer wrote:
I prefer to not use irqbalance and have de-installed
it.
As a reference read here:
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_MRG/1.3/ht…
But doesn't that mean all IRQ requests are being handled by the first
CPU? Or is this handled by NUMA? I know close to nothing about NUMA :(
Jeremy
12:09 p.m.
Am 21.11.2015 um 11:57 schrieb Jeremy Jongepier:
But doesn't that mean all IRQ requests are being
handled by the first
CPU?
I'm not a expert in this, but here, without irqbalance, interrupts get
handled by all 4 CPU's, while the sound-card interrupt get handled only
by CPU1, the USB1 get handled by CPU0, eth0 get handled by CPU3, . . .
12:22 p.m.
On 11/21/2015 12:09 PM, Hermann Meyer wrote:
Am 21.11.2015 um 11:57 schrieb Jeremy Jongepier:
Ah ok, so the IRQ requests are still being spread over all cores. If I
were to believe this answer on Serverfault though you should only
disable irqbalance if you're pinning applications or IRQ's to specific
cores:
http://serverfault.com/questions/513807/is-there-still-a-use-for-irqbalance…
And as far as I know this is not advisable to do in a desktop context
but usually applies to systems that are built for specific, single tasks.
Jeremy
But doesn't that mean all IRQ requests are
being handled by the first
CPU?
I'm not a expert in this, but here, without irqbalance, interrupts get
handled by all 4 CPU's, while the sound-card interrupt get handled only
by CPU1, the USB1 get handled by CPU0, eth0 get handled by CPU3, . . . 
2:40 p.m.
New subject: Isolating/dedicating Interrupts (was: irqbalance)?
Following the discussion about irq_balance, I was having a look at my
interrupts, I figured that my most important devices all share a single one:
cat /proc/interrupts:
20: <CPU List> IR-IO-APIC 20-fasteoi ohci_hcd:usb9, snd_rme9652,
vfio-intx(0000:07:00.0)
So some USB, my passed-through parallel card and my soundcard are all
sharing interrupt #20.
Now I wonder, is there a way to force the system to use a dedicated
interrupt just for the soundcard? So that the other ones shall use a
different one (and keep sharing, if the are happy there)?
Links are welcome, too, of course. So far I just found info on setting
interrupt CPU affinity, but not about configuring an exclusive interrupt
for a given PCI device.
2:56 p.m.
New subject: Isolating/dedicating Interrupts
On 11/21/2015 02:40 PM, Ede Wolf wrote:
Following the discussion about irq_balance, I was
having a look at my
interrupts, I figured that my most important devices all share a single
one:
cat /proc/interrupts:
20: <CPU List> IR-IO-APIC 20-fasteoi ohci_hcd:usb9, snd_rme9652,
vfio-intx(0000:07:00.0)
So some USB, my passed-through parallel card and my soundcard are all
sharing interrupt #20.
Now I wonder, is there a way to force the system to use a dedicated
interrupt just for the soundcard?
No, unless the system supports MSI (Message Signaled Interrupts) and the
sound card could use that. It's been a while since I had to use that so
I have no links at hand :(
You could also use rtirq for this and make sure the IRQ thread for
snd_rme9652 gets the highest prio:
http://wiki.linuxaudio.org/wiki/system_configuration#rtirq
Another option would be to stick the RME in a different PCI(e) slot if
possible.
Jeremy
2:59 p.m.
New subject: Isolating/dedicating Interrupts
On Sat, Nov 21, 2015 at 8:56 AM, Jeremy Jongepier <jeremy(a)autostatic.com>
wrote:
On 11/21/2015 02:40 PM, Ede Wolf wrote:
Actually, it depends on the BIOS in your motherboard.
In general, most laptops and many newer motherboards do not allow
interrupt/slot assignment to be controlled.
Most older desktop-y motherboards and a few contemporary ones do.
If you can't find it in the BIOS setup stuff, then it probably isn't there.
Following the discussion about irq_balance, I was
having a look at my
interrupts, I figured that my most important devices all share a single
one:
cat /proc/interrupts:
20: <CPU List> IR-IO-APIC 20-fasteoi ohci_hcd:usb9, snd_rme9652,
vfio-intx(0000:07:00.0)
So some USB, my passed-through parallel card and my soundcard are all
sharing interrupt #20.
Now I wonder, is there a way to force the system to use a dedicated
interrupt just for the soundcard?
No, unless the system supports MSI (Message Signaled Interrupts) and the
sound card could use that. It's been a while since I had to use that so
I have no links at hand :(
3:31 p.m.
New subject: Isolating/dedicating Interrupts (was: irqbalance)?
Hi Ede,
20: <CPU List> IR-IO-APIC 20-fasteoi ohci_hcd:usb9, snd_rme9652,
vfio-intx(0000:07:00.0)
Have you tried plugging the device into a different USB port? Sometimes
this makes a difference for the USB interrupt.
So some USB, my passed-through parallel card and my soundcard are all
sharing interrupt #20.
Do you *use* the parrrallel port? If not, you can remove the kernel module
with rmmod, and then the interrupt won't fire..
And finally you could set the CPU affinity for each interrupt, so at least
they're going to be handled by a different CPU
than the one that's going to
handle the audio interrupt.
Some details about latency tuning, CPU affinities and tuning here:
http://openavproductions.com/real-time-latency-tuning/
Cheers, -Harry
--
http://www.openavproductions.com
3:54 p.m.
New subject: Isolating/dedicating Interrupts (was: irqbalance)?
On Sat, 21 Nov 2015 14:31:54 +0000, Harry van Haaren wrote:
Have you tried plugging the device into a different USB
port? Sometimes
this makes a difference for the USB interrupt.
And in addition unbind the unused USB port.
http://wiki.linuxaudio.org/wiki/system_configuration#solve_irq_conflicts_by…
$ grep nbind /usr/local/sbin/tuning
### Unbinding devices
echo -n "0000:00:13.2" > /sys/bus/pci/drivers/ohci_hcd/unbind
echo -n "0000:00:13.4" > /sys/bus/pci/drivers/ohci_hcd/unbind
With very old kernels my graphics shares the IRQ with my PCIe audio
card, with newer kernels it doesn't, but that still isn't a help,
I guess the 2 PCIe slots and the integrated graphics share one PCIe bus
that is split into 2 slots + the bus for the on-board graphics. I might
be mistaken, but something still seems to be shared, it doesn't matter
what slot I use for the audio card and using a graphics card instead of
the integrated doesn't improve it either.
Regards,
Ralf
3:47 p.m.
New subject: Isolating/dedicating Interrupts
Am 21.11.2015 um 14:40 schrieb Ede Wolf:
Following the discussion about irq_balance, I was
having a look at my
interrupts, I figured that my most important devices all share a
single one:
on thing which helps me was to disable the interrupt for the i2c_i801
module by edit/create
/etc/modprobe.d/modesetting.conf
with
|options i2c_i801 disable_features=0x10
||
|this free up one interrupt and leads to a new distribution of the
existing interrupts on reboot. ||
6:54 p.m.
New subject: Isolating/dedicating Interrupts (was: irqbalance)?
On Sat, 21 Nov 2015, Ede Wolf wrote:
Following the discussion about irq_balance, I was
having a look at my
interrupts, I figured that my most important devices all share a single one:
cat /proc/interrupts:
20: <CPU List> IR-IO-APIC 20-fasteoi ohci_hcd:usb9, snd_rme9652,
vfio-intx(0000:07:00.0)
So some USB, my passed-through parallel card and my soundcard are all sharing
interrupt #20.
Now I wonder, is there a way to force the system to use a dedicated interrupt
just for the soundcard? So that the other ones shall use a different one (and
keep sharing, if the are happy there)?
Links are welcome, too, of course. So far I just found info on setting
interrupt CPU affinity, but not about configuring an exclusive interrupt for
a given PCI device.
Move the card to a different physical slot. Buy a mother board with as
many slots of the kind you want to use as possible. In my case I picked a
MB with 3 PCI slots because I need two and normally there is at least one
that shares a lot. Also, it may help to move another pci(e) card as well.
USB audio cards: Try all the USB plugs checking which IRQ they use. Often
it is possible to find one plug that has a free irq. Make sure not to use
another plug that ends up being the same USB port. In rtirq, use USB2, USB
to give USB2 a higher priority that all the other USB ports. It is the
same with more that one PCI snd driver, Sometimes changing the order
helps.
PC MBs are not designed for audio. If it is intended to use a PC for
audio, it is worth while being picky about the MB choice. Often a cheaper
MB is better than a more pricey version that has options you don't need or
worse will interfere with the audio performance. I still choose a CPU that
does not have hyper threading (4 core i5 over a 4 core i7 for example) by
default. I would probably turn HT off anyway and the i5 runs cooler
(=quieter BTW with similar cooling setup) If I wanted more speed, I would
look at a xeon with no HT or an i7 and turn ht off in BIOS if I could.
That is I would add more cores rather than HT.
Throughput performance != lowlatency performance. Speed helps, but it
isn't everything.
--
Len Ovens
www.ovenwerks.net
22 Nov
22 Nov
10:32 a.m.
New subject: Isolating/dedicating Interrupts (was: irqbalance)?
* Len Ovens <len(a)ovenwerks.net> [2015-11-21 18:55]:
[...]
I would probably turn HT off anyway and the i5 runs
cooler
(=quieter BTW with similar cooling setup) If I wanted more speed, I would
look at a xeon with no HT or an i7 and turn ht off in BIOS if I could. That
is I would add more cores rather than HT.
Interesting, Len, why do you recommend to
disable HyperThreading? What
problems / disadvantages wrt. audio could it cause?
2:42 p.m.
New subject: Isolating/dedicating Interrupts
On 11/22/2015 10:34 AM, Peter P. wrote:
* Len Ovens <len(a)ovenwerks.net> [2015-11-21
18:55]:
[...]
> I would probably turn HT off anyway and the i5 runs cooler
> (=quieter BTW with similar cooling setup) If I wanted more speed, I would
> look at a xeon with no HT or an i7 and turn ht off in BIOS if I could. That
> is I would add more cores rather than HT.
You can also tell the kernel with 'noht' to not use hyperthread features
of the CPU, or disable processors at runtime.
Interesting, Len, why do you recommend to disable
HyperThreading? What
problems / disadvantages wrt. audio could it cause?
There is anecdotal evidence that HT increases processing latency.
In short: Hyper-threading is one-CPU core that can run two threads.
Some of the *basic* CPU infrastructure is duplicated for every core, but
the FPU is not, nor are the L2, L3 CPU caches (this depends on the model).
In theory instead of e.g. waiting for I/O, or while doing on FPU
operations the same CPU core could do other tasks (e.g. integer calc,..)
if HT is enabled.
In practice most pro-audio tasks are float operations and there's a only
single FPU per core. To the OS it looks like there are two CPUs though.
If two cpu-threads need the same FPU one stalls and there's no benefit.
In theory this should be not worse than doing the two tasks sequentially
and HT can be better in some cases. In practice that's not always the
case, likely because the caches are shared.
The whole thing is yet another complex system where the only way for a
linux-audio-user to really know if it makes sense to use HT is to just
try an measure.
best,
robin
4:40 p.m.
New subject: Isolating/dedicating Interrupts
On Sun, 22 Nov 2015, Robin Gareus wrote:
You can also tell the kernel with 'noht' to
not use hyperthread features
of the CPU, or disable processors at runtime.
I hadn't heard of that one, Thanks.
--
Len Ovens
www.ovenwerks.net
23 Nov
23 Nov
6:38 p.m.
New subject: Isolating/dedicating Interrupts
Thanks for all your help and input, part of it improved the situation.
Now, before further praise, just one more realted topic I haven't found
any information of.
Since I was on a budget and to avoid HT and onboard video I went AMD and
now, having 8 cores (albeit only 4 FPUs, which, as I've learned here,
are not so relevant for FX unless using convolution reverbs), I wonder
wether it makes any sense to dedicate one core to jack?
So adding isolcpus=7 to your kernel parameters and running jack (and
maybe zita bridge) with tasksel -c 7? And maybe even bind that soundcard
IRQ to that CPU as well?
Since jack does not support smp anyway, there is nothing to lose, but
some given away CPU cycles, as that CPU will be bored and not be
available for other tasks.
Complete nonsense? Since my setup is not really finished due to some KVM
Problems, which most likely will require adding another PCIe card, I
currently cannot test thoroughly.
Back to praise, as I've been able to get that USB9 from named interrupt
by unbinding it, killing my mouse instantly, but I found another port,
and by disabling USB3 alltogether using the same method. Don't see me
using that for the forseeable future. However, it seems I will have to
add a serial port card, which then will request another IRQ again. So my
mainboard is pretty packed, and instead of moving cards I can only swap
them. Nothing to gain here IRQ wise.
I do remember when one could assign IRQs to specific slots, but that was
pre PCIe era. Indeed a shame, especially since we now have 50+ instead
of the former only 15 or 16 IRQs. But steadily losing control is simply
the future of anything technology related.
7:45 p.m.
New subject: Isolating/dedicating Interrupts
Hello Ede,
On 11/23/2015 06:38 PM, Ede Wolf wrote:
So adding isolcpus=7 to your kernel parameters and
running jack (and
maybe zita bridge) with tasksel -c 7? And maybe even bind that soundcard
IRQ to that CPU as well?
Since jack does not support smp anyway, there is nothing to lose, but
some given away CPU cycles, as that CPU will be bored and not be
available for other tasks.
Jack2 does support SMP so I wouldn't pin that to one CPU. If you use
Jack1 it might be an option but I wonder how much you would gain with
that. I really think it would be better to not try meddling with
scheduling IRQ requests yourself and have the system handle it. Just my
2¢ ;)
Jeremy
7:53 p.m.
New subject: Isolating/dedicating Interrupts
If you use
Jack1 it might be an option but I wonder how much you would gain with
that.
That was exactly my question, wether reserving one CPU might improve
latency (as in getting lower with no xruns) or stabilize Midi a bit more.
Or rather, wether this will have side effects I may not think of,
otherwise this can be tested.
22 Nov
22 Nov
4:34 p.m.
New subject: Isolating/dedicating Interrupts (was: irqbalance)?
On Sun, 22 Nov 2015, Peter P. wrote:
* Len Ovens <len(a)ovenwerks.net> [2015-11-21
18:55]:
[...]
I found that it did not effect audio so long as I had jack set higher than
64/2 for latency, but with HT turned off, I can get 16/2 with good
stability and no xruns over a 24 hour period (assuminig cron is turned off
:) )
HT means that the system (not the OS, but HW) can stop the high priority
audio process on one half of a core, to run whatever on the other half of
the core. Linux may have learned to handle this better than the last time
I tested this... I am guessing the only way the OS could fix this is to
not assign anything to the other half core along with a high priority
thread... but I really don't know that part.
There just seem to be some things that are bad for low latency/RT work:
- anything where the cpu is doing something the OS is not aware of:
- HT
- Temperature monitoring (this seems to be fast enough not to
matter so long as the temp is kept low)
- Some older "In the cpu GPU stuff".
- Other CPU utilities that run outside of the OS (SMS I think)
- CPU speed changes. In theory this should not effect things, but I have
gotten lower latency with my cpu set hard to 800Mhz than with it running
3.2 Ghz and speed set to OnDemand. The best setting is Performance which
sets top speed. Turn off things in BIOS like Boost (Intel) and the thing
in AMD that allows one core to over speed if the rest are idle(ish).
It seems I often get xruns at the point the cpu speed goes down, but it is
ok on an upward change. (seems is the operative word)
More on speed: Every once in a while it is good to run a cpu hog for each
core for about 10 minutes to see where the temperature levels off at. If
the temperture is too high:
- cleaning required
- better cooling setup required
- set cpu speed mode to User and run the cpu at a fixed speed lower than
max.
The last one may be the only thing possible on a laptop.
* by CPU hog I mean something that pulls the core to 100% use. (compiling
Ardour seems to do that for me, but there are utilities out there just to
stress systems like cpuburn or stress)
--
Len Ovens
www.ovenwerks.net
I would probably turn HT off anyway and the i5
runs cooler
(=quieter BTW with similar cooling setup) If I wanted more speed, I would
look at a xeon with no HT or an i7 and turn ht off in BIOS if I could. That
is I would add more cores rather than HT.
Interesting, Len, why do you recommend
to disable HyperThreading? What
problems / disadvantages wrt. audio could it cause?
3087
days inactive
3112
days old
linux-audio-user@lists.linuxaudio.org
22 comments
11 participants
participants (11)
-
Brent Busby -
Ede Wolf -
Harry van Haaren -
Hermann Meyer -
Jeremy Jongepier -
Len Ovens -
Paul Davis -
Peter P. -
Raffaele Morelli -
Ralf Mardorf -
Robin Gareus