Re: [Xenomai-help] pit

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

Steven Seeger wrote:
>> 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.
> 
> This makes sense, but if I simply disable the periodic timer then it
> should have 0 timer overhead, and then I turn it periodic when I need
> the task. The task timer won't fire if the periodic timer is disabled,
> right?

For sure, if there are system states where the periodic tasks do not
have to run, calling rt_task_set_periodic(..., TM_INFINITE) will help to
reduce unneeded load.

> 
>> 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 should really get the old flash and take some measurements as
> comparison.
> 
>> 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.
> 
> Actually I disagree in this case. The reason is that each of the three
> levels aren't interlocked. So, level 1 is the core, level 2 is something
> that uses the core, and level 3 is something that uses something that
> uses the core. Each one takes a little longer than the one below it, but
> there is a very small worst case time for each that is deterministic. As

Of course, the above was a rule of thumb, and there can always be
reasonable exceptions. But they are /generally/ few. :)

> this time is (or should be!) much smaller than the base timer period
> (125us) then things should be ok. They were, after all, just fine on the
> RTAI version of this app. I was very pleased with the jitter and
> response even on a crappy non-realtime friendly Geode.

I bet the overhead was not measurable because everything lived in kernel
space, right?

> 
> I am starting to think about certain things, though, in order to keep
> the syscalls to a minimum. We'd like to use Xenomai mainly for the
> debugging capabilities that RTAI lacked. Having everything all in one
> context makes for easy development. Obviously the sound driver is in the
> kernel space, but that's small and simple.

Keep another advantage in mind: going to user space allows you (or your
contractor) to distribute closed-source applications without consulting
costly lawyers - if that can help at all... :)

Jan

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