Re: [Xenomai-help] pit

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

Steven Seeger wrote:
>> That makes sense: Periodic timers keep on firing. That would explain
> up
>> to 16000 IRQ invocations per second. And the other 1000-2000 come from
>> Linux?
> 
> I have linux set to "tickless" in one setting, and 1000Hz in another.
> Weird.
> 
>> As suggested earlier: you can reduce the number of IRQ events by
> basing
>> your periodic tasks on the same start date. Then both will be woken up
>> at the same times and their priority will decide about the execution
> order.
> 
> The problem here is that many tasks are periodic, but not always
> required to run. Having them wake and wait for another period to do
> nothing is also overhead.

I'm not saying this. I'm saying that periodic task _timers_ fire anyway,
independent of the task waiting for them. So you should try to make them
fire at the same slots. That reduces the IRQ prologue/epilogue overhead
to 1, not n.

> 
>> Do you need Linux at 1 KHz? You may even want to try NO_HZ.
> 
> It's set to "tickles."
> 
>> I'm still wondering with what older numbers you compare all the nice
>> stats you now generate. Neither older Xenomai nor RTAI provide
>> comparable statistics. Are we doing fair comparisons here?
> 
> Well, RTAI had that output where it would give load values in 1/10th of
> a percent. (IIRC) The comparisons come from that. If, as Philippe says,
> RTAI charges that load to the pre-empted context, then I'm not sure
> where those numbers were coming from.

A fair comparison could be a non-real-time Linux benchmark that consumes
all the remaining CPU resources. Measure its execution time and you have
a reasonable metric for comparing the overall overhead. (The ROOT thread
CPU share with latest Xenomai should provide the same number, though.)

> 
> I do know that the system worked. I did some more experimenting and
> timing functions, and it seems the source of all my woes are syscalls.
> Namely, mutexes. There are several different resource sub-systems that
> layer off each other in this application. The highest-level one requires
> three mutex locks before doing a few IO operations. It takes me about
> 150 us to lock these three mutexes when nothing else is using them.

Lock nestings on a real-time system should be avoided, nesting levels >=
2 can generally be considered as a fatal design mistake. Just imagine
what the worst-case waiting time for your task is if all those locks are
contended! Maybe it is also worth thinking about some lock-less sync
patterns for some of your scenarios.

Jan

-- 
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux