[LAD] cpu spikes
jhernberg at alchemy.lu
Mon Jan 25 11:53:57 UTC 2016
On Mon, 25 Jan 2016 12:23:09 +0100
Jörn Nettingsmeier <nettings at stackingdwarves.net> wrote:
> i understand how device drivers can be nasty (graphics cards locking
> up the pci bus, wifi chips hogging the kernel for milliseconds at a
> time or worse...) but it seems that a) either kernel preemption and
> real-time scheduling is terribly buggy or hand-wavey, or b) we're
> feeding each other snake-oil in recommending to disable userspace
> things that is running without rt privs.
> i'd love to be educated on this.
My 2 cents is that it's snakeoil ;)
AFAIK, the important things are.
1. Use a properly configured realtime patched kernel.
2. Set a high priority of the soundcard interrupt, something like 97 is
a good value. (If using a USB soundcard, set the priority of the
interrupt servicing the USB hub instead).
3. Run Jack with realtime and memlocking enabled and at a priority of
4. Make sure that you don't have any hardware/drivers that play havoc
with your kernel scheduling. some WIFI adapters, NVIDIA, etc comes to
5. Make sure that the system isn't suffering from SMI/NMIs which
preempt the kernel and can take a long time to execute. This can be
done with hwlatdetect script in the rt-tests package.
6. Use cyclictest from rt-tests to confirm that there are no latency
spikes in how the kernel schedules threads.
Possibly hyperthreading, cpu power management, etc could cause
problems, and I don't have experience with all hardware out there, but
IME on modern Intel hardware this isn't a problem.
JACK2 also has a very nice profiling tool that can give a good idea
about what is going on with the soundcard interrupt, clients, etc.
Apart from that I think most things are snake oil, or ancient Internet
lore, of course ymmv ;)
More information about the Linux-audio-dev