25 Jan
2016
25 Jan
'16
12:29 p.m.
On Sun, 24 Jan 2016 15:03:08 +0100
Fokke de Jong <fokkedejong(a)gmail.com> wrote:
I am measuring cpu load by getting the time with
clock_gettime(CLOCK_MONOTONIC_RAW, timespec*) at the beginning and
end of each callback. When converted to a percentage my cpu load
hovers somewhere between 40 an 50% most of the time, but more or less
every 900 callbacks (0.8 seconds there is a spike of more than 100%.
I remember reading somewhere that realtime threads cannot run more
than .95s every second. That would be very bad if it actually meant
my threads are blocked run for a period of 50ms straight…
You can disable the realtime runtime throttling if that is a problem,
but I'd doubt that would be the reason for your troubles, and it's
unlikely to cause problems unless you're really maxing out the CPUs.
Other reasons could range from hardware/kernel modules that aren't
playing nice with RT to wifi drivers and the NVIDIA module also comes to
mind. Your system could also be suffering from SMI/NMI that runs out
of BIOS and completely preempts the kernel.
There are testing utilities in a package called rt-tests. Try to run
cyclictest like this (sudo) "cyclictest -S -m -p98". cyclictest
schedules threads to be run at a certain time, and can be used to get a
pretty good idea of kernel scheduling latencies. It's the max that is
interesting to us, and hopefully yours will be under 100us, but if you
have peaks that go much higher that could be a reason for audio
dropouts.
Best to run it in the background for a while, and even better would be
to put load on the system. The hackbench utility can be used for that.
Another reason could be cpu power management, though on a modern intel
processor that appears to be a thing of the past.
I suppose hyperthreading could be a potential pitfall, but personally I
see no problems with it with my audio workloads on my i7.
--
Joakim