Subject: Re: [linux-audio-dev] 2.4.0test5-pre4-lowlat latencies benchmarked, 2.2.16+Ingo's LL patch = strange behaviour
From: Iain Sandoe (iain_AT_sandoe.co.uk)
Date: Wed Jul 26 2000 - 02:04:24 EEST
Hi Benno,
I'm hoping that a comment you've made here might throw some light on the
situation with LinuxPPC.
> The very strange thing is that 2.2.16 although the latency behaviour is good
> it shows high spikes (around 2msec) at regular intervals, and you see that
these
> are in green, which means that when our thread is in the cpu wasting loop,
> something pre-empts us and chews away about 2msec.
On LinuxPPC (2.2.17pre10) these spikes are 8 to 10ms on occasion - maybe
every 19/20 seconds.
The only thing that can pre-empt this thread is an IRQ (right?)
So we thought that the 8-10ms might be an IRQ block. So I've just spent 2
weeks doing an modified version of Jun Sun's IRQ latency tool... (posted day
before yesterday - URL http://www.drfruitcake.com/linux/irq_blk.html for any
PPC audio types on this list).
However, the end result is that there are not any IRQ blocks showing that
are as long as that.
So what's the hypothesis?
It seems almost as if (on return from an interrupt - when rescheduling is
checked - at least on PPC) somehow the SCHED_FIFO task is not being
re-started and something else is getting a look-in... I'm definitely
perplexed by this.
Is there any danger of an instrumentation problem?
Iain.
This archive was generated by hypermail 2b28 : Wed Jul 26 2000 - 02:58:30 EEST