Jan Kiszka wrote:
> Gilles Chanteperdrix wrote:
>
>>Jan Kiszka wrote:
>>
>>>Gilles Chanteperdrix wrote:
>>>
>>>
>>>>Jan Kiszka wrote:
>>>>
>>>>
>>>>>Perrine Martignoni wrote:
>>>>>
>>>>>
>>>>>
>>>>>>Ok. I'll do this.
>>>>>>
>>>>>>But I don't understand why the same application compiled without any links
>>>>>>with Xenomai give different results if there is Xenomai in the kernel.
>>>>>
>>>>>[Looking at your numbers again] Hmm, maybe some rounding issue of ticks
>>>>>due to whatever side-effect of I-pipe. We would first of all need the
>>>>>usual set of information (.config, involved versions) and also
>>>>>/sys/devices/system/clocksource/clocksource0/current_clocksource.
>>>>
>>>>Maybe what Perrine is observing is simply the overhead of the I-pipe ?
>>>>I mean, Linux is Xenomai idle task, so it is acceptable for Linux
>>>>numbers to be a bit worse than when Xenomai is not running.
>>>
>>>I bit worse is expected. But I think we are seeing 1 or 2 ticks wake-up
>>>delays here. As far as I understood, they are not due to Xenomai
>>>consuming significant cycles in the background, are they, Perrine?
>>
>>What I see is latencies 5us longer. 5us on ARM is almost nothing, keep
>>in mind that a simple syscall on ARM already takes 10 us.
>>
>
>
> T: 0 ( 732) P:99 I: 10500 C: 2291 Min: 41 Act: 2281 Avg:
> 5075 Max: 10224
>
> vs.
>
> T: 0 ( 893) P:99 I: 10000 C: 1756 Min: 13407 Act: 13536 Avg:
> 13452 Max: 13693
>
> Thus the _minimum_ and the _average_ wakeup time of a Linux task
> increase fairly significant here. That's the point. Given a reasonable
> runtime of both test, this /could/ be considered as a regression of a
> Xenomai-enabled Linux kernel.
Ok, results are in milliseconds, not microseconds. I guess what we
observe here is an effect of Xenomai timer interception.
Perrine, what version of the I-pipe patch are you using ?
--
Gilles Chanteperdrix
_______________________________________________
Xenomai-help mailing list
[email protected]
https://mail.gna.org/listinfo/xenomai-help
