[LAD] cpu spikes

[Joakim Hernberg]

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
80.

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
mind.

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 ;)

-- 

   Joakim