On Tuesday 09 May 2006 01:08, Lee Revell wrote:
To be more precise, I get xruns, not scheduling latencies. Scheduling latency
is low (~50us), but softirq-timer/0 preempts all other threads when boosted
to prio 99, leading to xruns in jackd.
It's not a scheduler or -rt latency problem, it's a priority problem, since
softirq-timer/0 runs different jobs that would require different priorities:
wakeup sleep() at highest prio, rt_secret_rebuild et. al. at low prio.
With CONFIG_HIGH_RES_TIMERS=y it seems thatt softirq-timer/0 is no longer
needed for waking up sleep()ing threads, so it can be left at it's default
low prio (or even demoted to SCHED_OTHER?).
> > > My solution is to configure with CONFIG_HIGH_RES_TIMERS=y. Then,
Ah, ok. Now well known to me, too ;-)
> Lately I've been focused on getting mainline usable for audio - I have
With CONFIG_HIGH_RES_TIMERS=y, yes.
With CONFIG_HIGH_RES_TIMERS=n, no. Then, high-prio theads don't wake up from
sleep() if a mid-prio CPU hog is running. Typical scenario is a high-prio
watchdog like Florians rt_watchdog (http://tapas.affenbande.org/?page_id=38),
which fails to work unless softirq-timer/0 runs with higher prio than the CPU
hog. It seems that softirq-timer/0 has to be scheduled for any thread to wake
up. It's a bit like priority inversion.
> If not try setting the softirq thread to a lower RT priority than your
Yes, that should cure the xruns. But I wonder if jackd's watchdog can do it's
job when a jack client is running wild? Probably not. softirq-timer/0 would
not get to run then, so the watchdog wouldn't wake up.
> I've added Ingo to the cc: list, maybe he has some input.
That would be helpful. Also adding Steve to cc: as he mentioned writing a
section in an O'Reilly book about how to use the -rt patch in