On Sun, Jul 27, 2014 at 11:04 AM, Joakim Hernberg <jbh@email-addr-hidden> wrote:
> On Sat, 26 Jul 2014 10:33:07 +0200
> Jeremy Jongepier <jeremy@email-addr-hidden> 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@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-user
Received on Mon Jul 28 04:15:01 2014
This archive was generated by hypermail 2.1.8 : Mon Jul 28 2014 - 04:15:02 EEST