On Monday 08 May 2006 20:14, Florian Paul Schmidt wrote: > On Mon, 8 May 2006 12:03:34 -0500 > > "Josh Lawrence" <hardbop200@xxxxxxxxx> wrote: > > fyi, I've followed Dana's instructions more than once and found them > > to be excellent. Just use a little common sense when following them > > (there are newer versions of the kernel and the patch out) and you'll > > be fine. > > > > As Dana mentioned, there's a LOT more to getting realtime working than > > just the kernel - be sure to read everything there. > > I browsed over that page and didn't find any info on setting up the irq > handler priorities which is _the_ essential feature of -rt. Apropos: on your page on -rt setup (excellent page, btw., many thanks! :-), you suggest raising "softirq-timer/0" to prio 99, to make sleep() function right (http://tapas.affenbande.org/?page_id=40 sleep() based/system timer). I did so, and got strange latencies (> 40 ms) exactly once every 10 minutes, caused by some routing-related action (rt_secret_rebuild) being run by the softirq-timer/0 thread. Don't you get bit by that, too? Kernel is 2.6.16-rt16 My solution is to configure with CONFIG_HIGH_RES_TIMERS=y. Then, sleep() wakes up correctly even with softirq-timer/0 being low-priority (SCHED_FIFO 1 or even SCHED_OTHER). In general I find adjusting priorities of the various softirq kernel threads a bit of secret art. I can't find much documentation about "what kernel thread runs which job" that would help making some proper decisions here. I found my desktop "feels" most responsive when demoting all softirq thread to SCHED_OTHER. I did so after seeing that with a non-rt kernel, bottom-half handler don't run SCHED_FIFO/_RR at all. So -rt now gives me robust low latencies for jackd, and still proper desktop feeling. Well, maybe this is getting off-topic for this list. But it seems to me trimming priorities between kernel and userland threads is a bit like no man's land. Wolfgang