Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm2-V0.7.29-0

[Florian Schmidt <mista.tapas@gmx.net>]

On Sat, 20 Nov 2004 20:11:55 +0100
Florian Schmidt <mista.tapas@gmx.net> wrote:

> 29-4 with PREEMPT works very good (jackd at 64 frames: 0 xruns (running for
> 1h now), soundcard irq unthreaded). Opposed to 29-1 PREEMPT_REALTIME which
> showed some very weird jackd behaviour (xruns from 10usec to 50msec [!!!]).
> rtc_wakeup was showing no large jitter for that kernel though, nor did the
> different traces show anything that might have caused the jackd xruns. And
> yes, i configured the irq handlers sanely :)
> 
> Will build 29-4 PREEMPT_REALTIME now and see how this one behaves.

Pretty much as bad as 29-1. Sadly i have no idea on how to find out what is
causing jackd to act so weird under a PREEMPT_REALTIME kernel. It seems
there is some correlation to activity on X. Hiding and showing windows has a
certain chance of triggering a large xrun.

Hmm, the max jitter rtc_wakeup shows at 1024hz is around 150us. Which seems
a tiny bit large, too, as the rtc histogram shows a max wakeup latency of
16us..

It seems it's not the threaded irq handlers as jackd peformed quite well
under 29-4 PREEMPT with the soundcrd irq handler threaded and at high prio
(which i forgot to mention in my previous mail).

So i don't really know how to go about this. I suppose i just run PREEMPT
kernels instead of PREEMPT_REALTIME. Maybe it's the overhead which is
killing jackd performance with PREEMPT_REALTIME, but i don't believe so
(50ms? nah!).

flo

P.S.: There's so many variables in this PREEMPT/PREEMPT_REALTIME, handlers
threaded/unthreaded. IRQ handler thread priorities. It would probably be
cool if we could create some testing procedure which produces results which
are comparable. Ideally this procedure would be automated. Any takers?