[Xenomai-help] Strange results with latency test

[Xenomai-help] Strange results with latency test

[Matthias Fechner]

Hi,

I tested today Xenomai on my AMD64 (32-bit mode) with the latency
program from the testsuite and I got for lat min negative values.

Can my computer predict the future? :)

How can I interpret these values?

100 us
== Test mode: periodic user-mode task
== All results in microseconds
warming up...
RTT|  00:00:01  (periodic user-mode task, 100 us period, priority 99)
RTH|-----lat min|-----lat avg|-----lat max|-overrun|----lat best|---lat worst
RTD|      -1.337|      -0.958|       0.970|       0|      -1.337| 0.970
RTD|      -1.290|      -0.907|       1.959|       0|      -1.337| 1.959
...
RTD|      -1.406|      -0.923|       1.884|       0|      -1.468| 4.358
---|------------|------------|------------|--------|-------------------------
RTS|      -1.468|      -0.922|       4.358|       0| 00:00:34/00:00:34



Best regards,
Matthias

-- 

"Programming today is a race between software engineers striving to
build bigger and better idiot-proof programs, and the universe trying to
produce bigger and better idiots. So far, the universe is winning." --
Rich Cook

Re: [Xenomai-help] Strange results with latency test

[Gilles Chanteperdrix]

Matthias Fechner wrote:
> Hi,
> 
> I tested today Xenomai on my AMD64 (32-bit mode) with the latency
> program from the testsuite and I got for lat min negative values.
> 
> Can my computer predict the future? :)

The expiration time of a timer is usually known in advance, so, in that
sense, your computer predicts the future.

> 
> How can I interpret these values?

It means that Xenomai anticipates, that is, the timer is programmed
to tick a bit early in order to account for the interrupt and scheduling
latencies. In your case it is a bit too early, you can change this
anticipation time at compilation time with the configuration constant
CONFIG_OPT_TIMING_TIMERLAT and CONFIG_XENO_OPT_TIMING_SCHEDLAT, or 
change it at run time by writing a new value in /proc/xenomai/latency.

-- 
                                                  Gilles Chanteperdrix

Re: [Xenomai-help] Strange results with latency test

[Wolfgang Grandegger]

Matthias Fechner wrote:
> Hi,
> 
> I tested today Xenomai on my AMD64 (32-bit mode) with the latency
> program from the testsuite and I got for lat min negative values.
> 
> Can my computer predict the future? :)

Of course, the timer is programmed a bit in advance taking into account 
some average latency, like code run time, HW latencies, etc. It is 
system dependent.

> How can I interpret these values?
> 
> 100 us
> == Test mode: periodic user-mode task
> == All results in microseconds
> warming up...
> RTT|  00:00:01  (periodic user-mode task, 100 us period, priority 99)
> RTH|-----lat min|-----lat avg|-----lat max|-overrun|----lat best|---lat worst
> RTD|      -1.337|      -0.958|       0.970|       0|      -1.337| 0.970
> RTD|      -1.290|      -0.907|       1.959|       0|      -1.337| 1.959
> ...
> RTD|      -1.406|      -0.923|       1.884|       0|      -1.468| 4.358
> ---|------------|------------|------------|--------|-------------------------
> RTS|      -1.468|      -0.922|       4.358|       0| 00:00:34/00:00:34

Add the value listed by 'cat /proc/xenomai/latency` to the above figures 
or set the latency to "1 ns" with 'echo "1" > /proc/xenomai/latency'.

Wolfgang.

Re: [Xenomai-help] Strange results with latency test

[Matthias Fechner]

Hello Gilles and Wolfgang,

* Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org> [09-11-06 15:04]:
> It means that Xenomai anticipates, that is, the timer is programmed
> to tick a bit early in order to account for the interrupt and scheduling
> latencies. In your case it is a bit too early, you can change this
> anticipation time at compilation time with the configuration constant
> CONFIG_OPT_TIMING_TIMERLAT and CONFIG_XENO_OPT_TIMING_SCHEDLAT, or 
> change it at run time by writing a new value in /proc/xenomai/latency.

ah ok thx a lot for that information.

Best regards,
Matthias

-- 

"Programming today is a race between software engineers striving to
build bigger and better idiot-proof programs, and the universe trying to
produce bigger and better idiots. So far, the universe is winning." --
Rich Cook