Re: [Xenomai-help] Beginner's question / testsuite / latency

[Philippe Gerum <rpm@xenomai.org>]

On Mon, 2006-07-31 at 00:00 +0200, Jan Kiszka wrote:

<snip>

> > I'd like to explain why we don't we see any other routines than
> > xnthread_aperiodic_handler called from xntimer_do_tick_aperiodic in the
> > call frame? Even in case of massive jittery (e.g. > 300 us late) in one
> > shot, we should not spin in this code, due to the resync done in
> > xnpod_wait_thread_timeout - assuming we only have a single outstanding
> > timer (+ the host tick, but this should not be an issue).
> 
> xnpod_wait_thread_timeout? Do you mean xnpod_wait_thread_period? How
> should it help us as long as we are in the tick handler?
> 

Yes, I meant xnpod_wait_thread_period; forget about this, brain is
missing ECC feature. I misread the tracer output.

> > 
> >> I rather think, also when looking at Julien's second trace, that we have
> >> some issue with X in user-space here, probably in combination with weird
> >> VIA hardware stalling IRQ delivery for a "few" microseconds. Let's see
> >> if the irqbench gives similar results.
> >>
> > 
> > The problem is that I can reproduce X-related jittery (> 2 ms in a row)
> > on one of my test boxen when dragging windows over the screen, without
> > triggering the NMI watchdog set to 100 us (and guess what, the chipset
> > in question is from VIA).
> 
> Does NMI management happen in the CPU or has the chipset any influence
> as well?

I was referring to something like SMI# -> SMM which disables IRQs _and_
the NMI# and INIT# lines, in which case, the chipset would be at the
root of the problem. Since we cannot guarantee that our existing SMI
work-around blocks all potential SMI sources/events (hence the name), we
cannot exclude such possibility.

>  If yes, I could imagine what VIA does here... Have you already
> checked what irqbench records?
> 

Not yet.

> Jan
> 
-- 
Philippe.