On 03/12/2013 05:56 AM, Gilles Chanteperdrix wrote:
> On 03/11/2013 11:47 PM, Paul wrote:
>
>> Some precision and 2 small examples about a preempt test:
>>
>> On 11/03/2013 08:47, Gilles Chanteperdrix wrote:
>>> On 03/11/2013 10:15 AM, Paul wrote:
>>>
>>>> Hello,
>>>>
>>>> ... ... ...
>>>>
>>>> I check the priority masking with a preempt test which is derived
>>>> from the latency test: The real time task loop for 1/4 of its period
>>>> reading and rereading the clock, so i get the min, avg and worst case
>>>> that the task can be preempted while it is running.
>>>
>>>> If you are interested in this test, i can post it when I have
>>>> modified the output messages.
>>>
>>>
>>> I do not really understand. Why would it be more preempted in the first
>>> 1/4 of its period?
>>>
>>>
>> No reason sure but -
>> It can be preempted only while it is running, so between the time it
>> is restarted after sleeping and before it go to sleep again.
>> Let it running 1/4 of the period is enough to catch lots of events if
>> there is lots of irqs but not too much so linux, dohell or even xenomai
>> tasks can run just a bit slower.
>>
>>
>> Here are some result i get (yes with the priority interrupt masking, and
>> i am pretty sure it work - but the watchdog is on).
>> There is a dohell at the same time in the whole experiment and i start
>> X11, stop it , restart it ...
>>
>>
>> root@debian:/usr/xenomai/bin#
>> /usr/src/build_xenomai/src/testsuite/preempt/preempt -p 111
>> == Sampling period: 111 us
>> == Test mode: periodic user-mode task
>> == All results in microseconds
>> warming up...
>> RTT| 00:00:01 (periodic user-mode task, 111 us period, priority 99)
>> RTH|----pre min|----pre avg|----pre max|-overrun|---msw|---pre
>> best|--pre worst
>> RTD| 0.333| 0.374| 3.333| 0| 0|
>> 0.333| 3.333
>> RTD| 0.333| 0.374| 15.666| 0| 0| 0.333|
>> 15.666
>> ---|-----------|-----------|-----------|--------|------|-------------------------
>>
>> RTH|----pre min|----pre avg|----pre max|-overrun|---msw|---pre
>> best|--pre worst
>> RTD| 0.333| 0.374| 3.708| 0| 0| 0.333|
>> 23.333
>> RTD| 0.333| 0.374| 3.874| 0| 0| 0.333|
>> 23.333
>> RTD| 0.333| 0.374| 3.541| 0| 0| 0.333|
>> 23.333
>> RTD| 0.333| 0.374| 3.916| 0| 0| 0.333|
>> 23.333
>> RTD| 0.333| 0.374| 3.541| 0| 0| 0.333|
>> 23.333
>> RTD| 0.333| 0.374| 3.583| 0| 0| 0.333|
>> 23.333
>> RTD| 0.333| 0.374| 3.499| 0| 0| 0.333|
>> 23.333
>> RTD| 0.333| 0.374| 3.833| 0| 0| 0.333|
>> 23.333
>> RTD| 0.333| 0.374| 3.791| 0| 0| 0.333|
>> 23.333
>> RTD| 0.333| 0.374| 3.666| 0| 0| 0.333|
>> 23.333
>> RTD| 0.333| 0.374| 3.833| 0| 0| 0.333|
>> 23.333
>> RTD| 0.333| 0.374| 3.749| 0| 0| 0.333|
>> 23.333
>> RTD| 0.333| 0.374| 3.749| 0| 0| 0.333|
>> 23.333
>> RTD| 0.333| 0.374| 3.624| 0| 0| 0.333|
>> 23.333
>> ^C---|-----------|-----------|-----------|--------|------|-------------------------
>> RTS| 0.333| 0.374| 23.333| 0| 0|
>> 00:13:33/00:13:33
>>
>>
>> A second experiment, just setting the period to 100 (and the period for
>> the watchdog is a multiple so 3/4 it never preempt the task:
>
>
> Looks only like pure luck to me. As you may or may not know, Xenomai
> uses the timer in one-shot mode, so, the watchdog tick has no reason to
> be aligned with your application timer. I would say the chances for your
> task to be preempted by the watchdog tick while it is measuring is 1/4...
>
>
Of course the difference if your application timer is a sub-multiple of
the watchdog timer is that the watchdog will always preempt your
application at the same moment, so, if it did not preempt it during the
first quarter of one period during the first second, it will never do.
--
Gilles.
_______________________________________________
Xenomai mailing list
[email protected]
http://www.xenomai.org/mailman/listinfo/xenomai
