Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm3-V0.7.32-6

[Ingo Molnar <mingo@elte.hu>]

* Mark_H_Johnson@raytheon.com <Mark_H_Johnson@raytheon.com> wrote:

> >But you do have set your reference irq (soundcard) to the highest prio
> >in the PREEMPT_RT case? I just ask to make sure.
>
> Yes, but then I have ALL the IRQ's at the highest priority (plus a couple
> other /0 and /1 tasks). [...]

that is the fundamental problem i believe: your 'CPU loop' gets delayed
by them.

> [...] Please note, I only use latencytest (an audio application) to
> get an idea of RT performance on a desktop machine before I consider
> using the kernel for my real application.

but you never want your real application be delayed by things like IDE
processing or networking workloads, correct? The only thing that should
have higher priority than your application is the event thread that
handles the hardware from which you get events. I.e. the soundcard IRQ
in your case (plus the timer IRQ thread, because your task is also
timing out).

i'm not sure what the primary event source for your application is, but
i bet it's not the IDE irq thread, nor the network IRQ thread.

so you are seeing the _inverse_ of advances in the -RT kernel: it's
getting better and better at preempting your prio 30 CPU loop with the
higher-prio RT tasks. I.e. the lower-prio CPU loop gets worse and worse
latencies.

	Ingo