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

[Jan Kiszka <jan.kiszka@domain.hid>]

[-- Attachment #1: Type: text/plain, Size: 2352 bytes --]

Philippe Gerum wrote:
> On Sat, 2006-07-29 at 16:20 +0200, Jan Kiszka wrote:
>>>> :|func        6   xnintr_clock_handler (__ipipe_dispatch_wired)
>>>> :|func        6   xnintr_irq_handler (xnintr_clock_handler)
>>>> :|func        7   xnpod_announce_tick (xnintr_irq_handler)
>>>> :|func        8+  xntimer_do_tick_aperiodic (xnpod_announce_tick)
>>>> :|func        9   xnthread_periodic_handler (xntimer_do_tick_aperiodic)
>>>> :|func       10   xnpod_resume_thread (xnthread_periodic_handler)
>>>> :|[21559]    11+  xnpod_resume_thread (xnthread_periodic_handler)
>>>> :|func       13+  xnthread_periodic_handler (xntimer_do_tick_aperiodic)
>> ...
>>
>>>> :|func      363+  xnthread_periodic_handler (xntimer_do_tick_aperiodic)
>> That are a lot of overruns. Haven't counted, but it should be one
>> xnthread_periodic_handler per missed 100 us period (20000 / 100 = 200!).
>> [BTW, I think we should handle even this failure scenario without
>> looping.
> 
> We need to loop in the aperiodic handler in order to catch timers that
> could have elapsed while processing the current tick. However,

No, that was not what I meant. I know that we need the timer loop. But I
was thinking of something like this for the tick handler's error path:

if (unlikely((timer.date += timer.interval) < now))
	timer.date = now + timer.interval -
		(now - timer.date) % timer.interval;

> xnpod_wait_thread_period() - over which rt_task_wait_period() is based -
> does not loop, but rather computes the actual count of overruns by
> substracting the current time from the deadline.

...but by looping for some scenarios instead of dividing for all. Why
optimising the slow path here?

> 
> Which brings us an interesting question: why does the aperiodic handler
> loop frenetically in the first place? I would be pretty interested in
> checking the TSC values returned by xnarch_get_cpu_tsc() while spinning
> inside this deadly loop...

You can already read those TSCs: each trace point got recorded with the
current TSC value, fresh from the hardware.

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.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]