[lkml]   [2004]   [Oct]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0.4
    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

    Bye now.
    rncbc aka Rui Nuno Capela

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 14:07    [W:0.032 / U:0.104 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site