* Fernando Lopez-Lezcano <[EMAIL PROTECTED]> wrote:
> > ok, i reproduced something similar on one of my boxes and it turned
> > out to be a tracer bug. I've uploaded -rt10, could you try it? (The
> > xruns will likely remain, but at least the tracer should be more
> > usable now to find out the reason for the xruns.)
>
> I'm testing -rt10 right now (your binary rpm). Looks like the number
> and length of the xruns went down, at least for now. All below 2mSec -
> jack is running 128x2 @ 48000Hz. I'll let it run for a while and
> report the traces (I have a script that collects all traces above
> 60us, but not all xruns trigger a trace).
ok.
How do you gather the traces, are you using manual control of tracing
via prctl(0,1) / prctl(0,0) - or the built-in wakeup tracing method? The
wakeup tracing method will detect fundamental problems in -rt
scheduling, but other types of delays can be better debugged via
explicit tracing. [jackd used to have the gettimeofday(0,1)/(0,0) hack -
this API hack has been replaced by prctl(0,1)/(0,0) to start/stop
tracing] Take a look at linux/scripts/trace-it.c on how to set up
manually triggered tracing. [if you do that then all you need to do is
to start/stop the trace - the kernel will do a maximum search and will
record the longest delay between start/stop calls.]
Also, can you see the xruns/latencies with latencytest too? (That one
might be easier to reproduce for me.)
Also, my experience is that if there's a short succession of latencies
after each other, then it's usually the first trace that makes most
sense to analyze - the others might just be 'followup' or 'secondary'
delays caused by the tracing/printing overhead of the first trace. So
generally i concentrate on the first trace. But if the traces are
reasonably apart then each of them makes sense - and sometimes one trace
is more informative than another.
Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
