Re: [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0.4

[Rui Nuno Capela]

Ingo Molnar wrote:
>
> * Rui Nuno Capela wrote:
>
>> OK. Here are my early consolidated results. Feel free to comment.
>>
>>                                     2.6.9     RT-U3   RT-V0.4.3
>>                                   --------- --------- ---------
>>   XRUN Rate . . . . . . . . . . .     424         8         4    /hour
>>   Delay Rate (>spare time)  . . .     496         0         0    /hour
>>   Delay Rate (>1000 usecs)  . . .     940         8         4    /hour
>>   Maximum Delay . . . . . . . . .    6904       921       721    usecs
>>   Maximum Process Cycle . . . . .    1449      1469      1590    usecs
>>   Average DSP CPU Load  . . . . .      38        39        40    %
>>   Average Context-Switch Rate . .    7480      8929      9726    /sec
>
> looks pretty good, doesnt it?
>

Yes indeed :)


> how is the 'maximum delay' calculated? Could you put in a tracing hook
> into jackd whenever such a ~720 usecs maximum is hit? I'd _love_ to see
> how such a latency path looks like, it seems a bit long.
>

That 'maximum delay' is collected on each jackd process cycle. AFAICS, it
is the figure of a scheduling delay, as measured by jackd as the time
interval between interrupt and effective jackd process handler (re)entry.

Please note that I'm not a JACK developer. I'm just a regular user
with ancient coding skills ;) I do however subscribe to the jackit-devel
maillist. And the author of qjackctl, if that matters...

For reading this 'maximum delay' I am actually using a custom patch
against jack-0.99.7cvs, being a Lee Revell's original.


> It should be a relatively simple hack to jackd. Firstly, download the
> -V0.5.3 patch and enable LATENCY_TRACE, then do:
>
>         echo 2 > /proc/sys/kernel/trace_enabled
>
> this activates the 'application-triggered kernel tracer' functionality.
>
> No tracing happens by default, but tracing starts if the application
> executes this function:
>
>         gettimeofday(0,1);
>
> and tracing stops if the application does:
>
>         gettimeofday(0,0);
>
> whenever the app does this (0,0) call the trace gets saved and you can
> retrieve it from /proc/latency_trace where you can retrieve it. There is
> no combination of these parameters that can break the kernel, so it's a
> 100% safe tracing facility. You can 'ignore' a latency [e.g. if it's not
> a maximum] by simply not doing the (0,0) call. The next (0,1) call done
> will override the previous, already running trace.
>
> [stupid function but this combination of the syscall parameters is not
> used otherwise so the latency tracer hijacks it.]
>
> i dont know how Jackd does things, but i'd suggest to enable tracing the
> first time possible when getting an interrupt - in theory this should
> happen as soon as the wakeup-latency-tracer says - i.e. at most in like
> 30 usecs. The bulk of the remaining 700 usecs will be spent in jackd,
> and you can trace those 700 usecs.
>
> or if you would be willing to do a little bit of ALSA hacking, you could
> add this to the ALSA interrupt handler:
>
>         #include <linux/syscalls.h>
>
>         ...
>         sys_gettimeofday(0, 1);
>
> [the attached patch implements this for ali5451.]
>
> and do the gettimeofday(0,0) in jackd [if the latency measured there is
> a new maximum]! This way tracing is turned on within the kernel IRQ
> handler (i.e. as soon as possible) and turned off within ALSA. This will
> enable us to see an even more complete latency path.
>
> NOTE: there can only be one trace active at a time. So if there can be
> multiple channels active at a time then this user-triggered tracer might
> be less useful. Do these channels have any priority? Or if multiple
> channels are necessary then you could modify the patch to only do the
> (0,1) call for say channel #0:
>
>         if (channel == 0)
>                 sys_gettimeofday(0, 1);
>
> in this case the trace-off-save (0,0) call in Jackd must also only do
> this for channel 0 processing! (or whichever channel you find the most
> interesting.)
>

Ouch. This is a bit too much to digest in so little time :) I'll try to
re-read this from cache, erm... tomorrow ;)

BTW, this means that I have to re-enable LATENCY_TIMING back again? Notice
that all my results were taken with a production configuration, that is,
with all debug options now set to off (OK, I think I've left the
stack-overflow on, but that was the only one).

OTOH, this latency timing has been troublesome on either of my setups,
recently. But I'll give it another try...


> also, i looked at the sound/pci/ali5451/ali5451.c driver code and it has
> one weird piece of code on line 988:
>
>         udelay(100);
>
> that adds a 100 usecs latency to the main path, for no good reason! It
> also spends that time burning CPU time, delaying other processing. Could
> you add an IRQs/sec measurement too if possible, so that we can compare
> the IRQ rates of various kernels?
>

Yes, I can add interrupts/sec measuring with nmeter. Neat utility indeed,
thanks to Denis Vlasenko.


> Also, i'd suggest to simply remove that line (or apply the attached
> patch) - does the driver still work fine with that?
>

Now that you call, I remember to hack that very same line, some time go,
but couldn't get no better than a udelay(33). Removing that line just
ended in some kind of malfunction, but can't remember what exactly. One
thing's for sure, sound didn't came out of it :-/


> plus i've also got questions about how Jackd interfaces with ALSA: does
> it use SIGIO, or some direct driver ioctl? If SIGIO is used then how is
> it done precisely - is an 'RT' queued signal used or ordinary SIGIO?
> Also, how is the 'channel' information established upon getting a SIGIO,
> is it in the siginfo structure?
>

Now that's really pushing me over. Any ALSA-JACK developers around here to
comment?

Bye now.
-- 
rncbc aka Rui Nuno Capela
rncbc@xxxxxxxxx

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/