On Sun, Jul 27, 2014 at 11:04 AM, Joakim Hernberg <jbh@xxxxxxxxxx> wrote: > On Sat, 26 Jul 2014 10:33:07 +0200 > Jeremy Jongepier <jeremy@xxxxxxxxxxxxxx> 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 _______________________________________________ Linux-audio-user mailing list Linux-audio-user@xxxxxxxxxxxxxxxxxxxx http://lists.linuxaudio.org/listinfo/linux-audio-user
