On Sun, Jul 27, 2014 at 11:04 AM, Joakim Hernberg <jbh(a)alchemy.lu> wrote:
On Sat, 26 Jul 2014 10:33:07 +0200
Jeremy Jongepier <jeremy(a)autostatic.com> wrote:
Just a big thank you for the comprehensive
explanation! I'll add this
to the System Configuration wiki page on
linuxaudio.org if you don't
mind.
Not at all, go ahead. There are a few things I wish I would have
written differently, but it was a ml post and not an essay :)
The rt testing package is indeed called rt-tests and not rt-tools.
The reason I see max scheduling latencies of about 100us on the -rt
kernel with cyclictest is most likely due to using the -i100 parameter.
Setting it lower would likely result in lower max values, but at the
cost of increasing cpu use.
In fact I think the max scheduling latencies on my system is more
likely around 40us or so, but what really interests me is to know
that I don't have max values into the millisecond range.
Hi Joakim,
I've just been playing around with this, and can confirm that a
hand-built -rt kernel has lower max sched latencies than a generic
lowlatency kernel in ubuntu on my system (<100us compared to 1500+).
However, I noticed a really weird thing - that when running the test
using sudo cyclictest -m -n -Sp99 -i100 -d0, the reported DSP load on
qjackctl is reduced (by around 50%), and there are fewer xruns at low
latencies. As soon as I stop cyclictest, the xruns (at a rather low
jack frames/period of 32) come back.. Any idea why this should be???
James