[Xenomai-help] Xenomai latency tests on MPC8xx

[Xenomai-help] Xenomai latency tests on MPC8xx

[fabien]

Here, there is some xenomai tests on a MPC855T, could you comment
these results please ?
Are they correct ?

# cat cpuinfo
processor       : 0
cpu             : 8xx
clock           : 50MHz
bus clock       : 50MHz
revision        : 0.0 (pvr 0050 0000)
bogomips        : 48.38

The kernel is a 2.6.23-6 (ppc branch) from DENX git repository,
Xenomai 2.4.0, and adeo-ipipe patch :
adeos-ipipe-2.6.23-ppc-1.6-00.patch.

I'm new in realtime system and xenomai so i have also some questions :
First, what's the purpose of the cyclic and switchbench test ?
How could i interpret the results of switchtest ?
And finaly, it's seem there is something wrong with irqloop test, but what ?

First, tests without load :

# ./latency -t0 -p1000 -T30
== Sampling period: 1000 us
== Test mode: periodic user-mode task
== All results in microseconds
warming up...
RTT|  00:00:01  (periodic user-mode task, 1000 us period, priority 99)
RTH|-----lat min|-----lat avg|-----lat max|-overrun|----lat best|---lat worst
RTD|      75.520|      84.480|     128.640|       0|      75.520|     128.640
RTD|      75.520|      86.080|     136.960|       0|      75.520|     136.960
[...]
RTS|      75.520|      86.080|     185.920|       0|    00:00:30/00:00:30

# ./latency -t1 -p1000 -T30
== Sampling period: 1000 us
== Test mode: in-kernel periodic task
== All results in microseconds
warming up...
RTT|  00:00:01  (in-kernel periodic task, 1000 us period, priority 99)
RTH|-----lat min|-----lat avg|-----lat max|-overrun|----lat best|---lat worst
RTD|      56.960|      66.118|      92.800|       0|      56.960|      92.800
RTD|      56.960|      66.777|     106.240|       0|      56.960|     106.240
RTD|      56.960|      66.037|     136.640|       0|      56.960|     136.640
[...]
RTS|      56.960|      66.308|     149.440|       0|    00:00:30/00:00:30

# ./latency -t2 -p1000 -T30
== Sampling period: 1000 us
== Test mode: in-kernel timer handler
== All results in microseconds
warming up...
RTT|  00:00:01  (in-kernel timer handler, 1000 us period, priority 99)
RTH|-----lat min|-----lat avg|-----lat max|-overrun|----lat best|---lat worst
RTD|      18.560|      20.938|      34.880|       0|      18.560|      34.880
RTD|      18.560|      21.446|      45.760|       0|      18.560|      45.760
[...]
RTS|      18.560|      21.320|     118.400|       0|    00:00:30/00:00:30

# ./cyclictest -t5 -l 30000
T: 0 (   64) P:99 I:    1000 C:   30000 Min:      97 Act:     138 Avg:
    127 Max:     180
T: 1 (   65) P:98 I:    1500 C:   30000 Min:      97 Act:     101 Avg:
    195 Max:     431
T: 2 (   66) P:97 I:    2000 C:   30000 Min:      97 Act:     138 Avg:
    290 Max:     660
T: 3 (   67) P:96 I:    2500 C:   25569 Min:      95 Act:     881 Avg:
    286 Max:     881
T: 4 (   68) P:95 I:    3000 C:   21308 Min:      96 Act:     168 Avg:
    552 Max:    1354

# ./switchbench -n10000 -p 1000
== Sampling period: 1000 us
== Do not interrupt this program
RTH|     lat min|     lat avg|     lat max|        lost
RTD|     137.920|     143.040|     160.640|           0

# ./switchtest -T30 -n
== Threads: sleeper-0 rtk-1 rtk-2 rtup-3 rtup-4 rtus-5 rtus-6 rtuo-7 rtuo-8
RTT|  00:00:01
RTH|ctx switches|-------total
RTD|         999|         999
RTD|         993|        1992
RTD|        1005|        2997
RTD|         999|        3996
RTD|         993|        4989
RTD|        1005|        5994
RTD|         999|        6993
RTD|         990|        7983
RTD|         993|        8976
RTD|        1005|        9981
RTD|         999|       10980
[...]

# insmod ./xeno_irqbench.ko
# ./irqloop -t0
irqloop: error starting test: Inappropriate ioctl for device
Xenomai: POSIX: destroyed thread c03a0e10
# lsmod
Module                  Size  Used by    Not tainted
xeno_irqbench           9788  -
xeno_posix            179428  -
xeno_switchtest         8704  -
xeno_rtdm              30572  -
#



----
Now tests with load : dd if=/dev/zero of=/dev/null
----

# ./latency -t0 -p1000 -T30
== Sampling period: 1000 us
== Test mode: periodic user-mode task
== All results in microseconds
warming up...
RTT|  00:00:01  (periodic user-mode task, 1000 us period, priority 99)
RTH|-----lat min|-----lat avg|-----lat max|-overrun|----lat best|---lat worst
RTD|     108.160|     119.680|     133.760|       0|     108.160|     133.760
RTD|     115.840|     120.000|     154.240|       0|     108.160|     154.240
[...]
RTS|      95.040|     119.680|     202.880|       0|    00:00:30/00:00:30

# ./latency -t1 -p1000 -T30
== Sampling period: 1000 us
== Test mode: in-kernel periodic task
== All results in microseconds
warming up...
RTT|  00:00:01  (in-kernel periodic task, 1000 us period, priority 99)
RTH|-----lat min|-----lat avg|-----lat max|-overrun|----lat best|---lat worst
RTD|      65.920|      73.409|     100.480|       0|      65.920|     100.480
RTD|      65.920|      74.055|     107.840|       0|      65.920|     107.840
RTD|      65.920|      73.954|     100.800|       0|      65.920|     107.840
[...]
RTS|      65.920|      73.868|     132.480|       0|    00:00:30/00:00:30

# ./latency -t2 -p1000 -T30
== Sampling period: 1000 us
== Test mode: in-kernel timer handler
== All results in microseconds
warming up...
RTT|  00:00:01  (in-kernel timer handler, 1000 us period, priority 99)
RTH|-----lat min|-----lat avg|-----lat max|-overrun|----lat best|---lat worst
RTD|      21.120|      25.826|      39.680|       0|      21.120|      39.680
RTD|      21.120|      26.073|      39.360|       0|      21.120|      39.680
[...]
RTS|      20.800|      25.987|      54.400|       0|    00:00:30/00:00:30

# ./cyclictest -t5 -l 30000
T: 0 (   68) P:99 I:    1000 C:   30000 Min:      96 Act:     135 Avg:
    144 Max:     177
T: 1 (   69) P:98 I:    1500 C:   30000 Min:      96 Act:     130 Avg:
    216 Max:     483
T: 2 (   70) P:97 I:    2000 C:   30000 Min:     128 Act:     133 Avg:
    313 Max:     704
T: 3 (   71) P:96 I:    2500 C:   30000 Min:      98 Act:     136 Avg:
    292 Max:     932
T: 4 (   72) P:95 I:    3000 C:   30000 Min:     127 Act:     135 Avg:
    470 Max:    1378

# ./switchbench -n10000 -p 1000
== Sampling period: 1000 us
== Do not interrupt this program
RTH|     lat min|     lat avg|     lat max|        lost
RTD|     144.960|     156.160|     162.240|           0

# ./switchtest -T30 -n
== Threads: sleeper-0 rtk-1 rtk-2 rtup-3 rtup-4 rtus-5 rtus-6 rtuo-7 rtuo-8
RTT|  00:00:01
RTH|ctx switches|-------total
RTD|         999|         999
RTD|         993|        1992
RTD|        1005|        2997
RTD|         999|        3996
RTD|        1008|        5004
RTD|         993|        5997
RTD|        1005|        7002
RTD|         999|        8001
RTD|         999|        9000
RTD|         999|        9999
RTD|         993|       10992



Thanks a lot
Fabien

Re: [Xenomai-help] Xenomai latency tests on MPC8xx

[Gilles Chanteperdrix]

On Jan 7, 2008 4:37 PM, fabien <fabien.fb@domain.hid> wrote:
> Here, there is some xenomai tests on a MPC855T, could you comment
> these results please ?
> Are they correct ?

I will not be able to comment results on ppc, however, you enabled
debugging, so, your results are meaningless, if you want meaningful
results, you should disable debugging.

-- 
                                               Gilles Chanteperdrix

Re: [Xenomai-help] Xenomai latency tests on MPC8xx

[fabien]

2008/1/7, Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>:
> On Jan 7, 2008 4:37 PM, fabien <fabien.fb@domain.hid> wrote:
> > Here, there is some xenomai tests on a MPC855T, could you comment
> > these results please ?
> > Are they correct ?
>
> I will not be able to comment results on ppc, however, you enabled
> debugging, so, your results are meaningless, if you want meaningful
> results, you should disable debugging.
>
I don't know witch debugging features you talk ? about kernel or Xenomai ?.
I haven't touch to Xenomai def  config.
In Linux config i have just KALLSYMS and BUG support, maybe is that ?
But how could you see that ? :0
Regards
Fabien

Re: [Xenomai-help] Xenomai latency tests on MPC8xx

[Gilles Chanteperdrix]

On Jan 7, 2008 5:02 PM, fabien <fabien.fb@domain.hid> wrote:
> 2008/1/7, Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>:
> > On Jan 7, 2008 4:37 PM, fabien <fabien.fb@domain.hid> wrote:
> > > Here, there is some xenomai tests on a MPC855T, could you comment
> > > these results please ?
> > > Are they correct ?
> >
> > I will not be able to comment results on ppc, however, you enabled
> > debugging, so, your results are meaningless, if you want meaningful
> > results, you should disable debugging.
> >
> I don't know witch debugging features you talk ? about kernel or Xenomai ?.
> I haven't touch to Xenomai def  config.
> In Linux config i have just KALLSYMS and BUG support, maybe is that ?
> But how could you see that ? :0

You have a message about Xenomai posix thread destruction, this
message only shows up if you enabled CONFIG_XENO_OPT_DEBUG_POSIX.
CONFIG_XENO_OPT_DEBUG_POSIX has no influence on latency, but other
CONFIG_XENO_OPT_DEBUG_* options may have an influence.

-- 
                                               Gilles Chanteperdrix

Re: [Xenomai-help] Xenomai latency tests on MPC8xx

[fabien]

2008/1/7, Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>:
> On Jan 7, 2008 5:02 PM, fabien <fabien.fb@domain.hid> wrote:
> > 2008/1/7, Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>:
> > > On Jan 7, 2008 4:37 PM, fabien <fabien.fb@domain.hid> wrote:
> > > > Here, there is some xenomai tests on a MPC855T, could you comment
> > > > these results please ?
> > > > Are they correct ?
> > >
> > > I will not be able to comment results on ppc, however, you enabled
> > > debugging, so, your results are meaningless, if you want meaningful
> > > results, you should disable debugging.
> > >
> > I don't know witch debugging features you talk ? about kernel or Xenomai ?.
> > I haven't touch to Xenomai def  config.
> > In Linux config i have just KALLSYMS and BUG support, maybe is that ?
> > But how could you see that ? :0
>
> You have a message about Xenomai posix thread destruction, this
> message only shows up if you enabled CONFIG_XENO_OPT_DEBUG_POSIX.
> CONFIG_XENO_OPT_DEBUG_POSIX has no influence on latency, but other
> CONFIG_XENO_OPT_DEBUG_* options may have an influence.
>
Ok thank Giles, i have just this one enabled :
CONFIG_XENO_OPT_DEBUG_POSIX others
are disabled. So results are already meaningful.


Regards

Re: [Xenomai-help] Xenomai latency tests on MPC8xx

[Wolfgang Grandegger]

fabien wrote:
> Here, there is some xenomai tests on a MPC855T, could you comment
> these results please ?
> Are they correct ?
> 
> # cat cpuinfo
> processor       : 0
> cpu             : 8xx
> clock           : 50MHz
> bus clock       : 50MHz
> revision        : 0.0 (pvr 0050 0000)
> bogomips        : 48.38
> 
> The kernel is a 2.6.23-6 (ppc branch) from DENX git repository,
> Xenomai 2.4.0, and adeo-ipipe patch :
> adeos-ipipe-2.6.23-ppc-1.6-00.patch.
> 
> I'm new in realtime system and xenomai so i have also some questions :
> First, what's the purpose of the cyclic and switchbench test ?
> How could i interpret the results of switchtest ?
> And finaly, it's seem there is something wrong with irqloop test, but what ?
> 
> First, tests without load :
> 
> # ./latency -t0 -p1000 -T30
> == Sampling period: 1000 us
> == Test mode: periodic user-mode task
> == All results in microseconds
> warming up...
> RTT|  00:00:01  (periodic user-mode task, 1000 us period, priority 99)
> RTH|-----lat min|-----lat avg|-----lat max|-overrun|----lat best|---lat worst
> RTD|      75.520|      84.480|     128.640|       0|      75.520|     128.640
> RTD|      75.520|      86.080|     136.960|       0|      75.520|     136.960
> [...]
> RTS|      75.520|      86.080|     185.920|       0|    00:00:30/00:00:30
> 
> # ./latency -t1 -p1000 -T30
> == Sampling period: 1000 us
> == Test mode: in-kernel periodic task
> == All results in microseconds
> warming up...
> RTT|  00:00:01  (in-kernel periodic task, 1000 us period, priority 99)
> RTH|-----lat min|-----lat avg|-----lat max|-overrun|----lat best|---lat worst
> RTD|      56.960|      66.118|      92.800|       0|      56.960|      92.800
> RTD|      56.960|      66.777|     106.240|       0|      56.960|     106.240
> RTD|      56.960|      66.037|     136.640|       0|      56.960|     136.640
> [...]
> RTS|      56.960|      66.308|     149.440|       0|    00:00:30/00:00:30
> 
> # ./latency -t2 -p1000 -T30
> == Sampling period: 1000 us
> == Test mode: in-kernel timer handler
> == All results in microseconds
> warming up...
> RTT|  00:00:01  (in-kernel timer handler, 1000 us period, priority 99)
> RTH|-----lat min|-----lat avg|-----lat max|-overrun|----lat best|---lat worst
> RTD|      18.560|      20.938|      34.880|       0|      18.560|      34.880
> RTD|      18.560|      21.446|      45.760|       0|      18.560|      45.760
> [...]
> RTS|      18.560|      21.320|     118.400|       0|    00:00:30/00:00:30
> 
> # ./cyclictest -t5 -l 30000
> T: 0 (   64) P:99 I:    1000 C:   30000 Min:      97 Act:     138 Avg:
>     127 Max:     180
> T: 1 (   65) P:98 I:    1500 C:   30000 Min:      97 Act:     101 Avg:
>     195 Max:     431
> T: 2 (   66) P:97 I:    2000 C:   30000 Min:      97 Act:     138 Avg:
>     290 Max:     660
> T: 3 (   67) P:96 I:    2500 C:   25569 Min:      95 Act:     881 Avg:
>     286 Max:     881
> T: 4 (   68) P:95 I:    3000 C:   21308 Min:      96 Act:     168 Avg:
>     552 Max:    1354
> 
> # ./switchbench -n10000 -p 1000
> == Sampling period: 1000 us
> == Do not interrupt this program
> RTH|     lat min|     lat avg|     lat max|        lost
> RTD|     137.920|     143.040|     160.640|           0
> 
> # ./switchtest -T30 -n
> == Threads: sleeper-0 rtk-1 rtk-2 rtup-3 rtup-4 rtus-5 rtus-6 rtuo-7 rtuo-8
> RTT|  00:00:01
> RTH|ctx switches|-------total
> RTD|         999|         999
> RTD|         993|        1992
> RTD|        1005|        2997
> RTD|         999|        3996
> RTD|         993|        4989
> RTD|        1005|        5994
> RTD|         999|        6993
> RTD|         990|        7983
> RTD|         993|        8976
> RTD|        1005|        9981
> RTD|         999|       10980
> [...]
> 
> # insmod ./xeno_irqbench.ko
> # ./irqloop -t0
> irqloop: error starting test: Inappropriate ioctl for device
> Xenomai: POSIX: destroyed thread c03a0e10
> # lsmod
> Module                  Size  Used by    Not tainted
> xeno_irqbench           9788  -
> xeno_posix            179428  -
> xeno_switchtest         8704  -
> xeno_rtdm              30572  -
> #
> 
> 
> 
> ----
> Now tests with load : dd if=/dev/zero of=/dev/null
> ----
> 
> # ./latency -t0 -p1000 -T30
> == Sampling period: 1000 us
> == Test mode: periodic user-mode task
> == All results in microseconds
> warming up...
> RTT|  00:00:01  (periodic user-mode task, 1000 us period, priority 99)
> RTH|-----lat min|-----lat avg|-----lat max|-overrun|----lat best|---lat worst
> RTD|     108.160|     119.680|     133.760|       0|     108.160|     133.760
> RTD|     115.840|     120.000|     154.240|       0|     108.160|     154.240
> [...]
> RTS|      95.040|     119.680|     202.880|       0|    00:00:30/00:00:30
> 
> # ./latency -t1 -p1000 -T30
> == Sampling period: 1000 us
> == Test mode: in-kernel periodic task
> == All results in microseconds
> warming up...
> RTT|  00:00:01  (in-kernel periodic task, 1000 us period, priority 99)
> RTH|-----lat min|-----lat avg|-----lat max|-overrun|----lat best|---lat worst
> RTD|      65.920|      73.409|     100.480|       0|      65.920|     100.480
> RTD|      65.920|      74.055|     107.840|       0|      65.920|     107.840
> RTD|      65.920|      73.954|     100.800|       0|      65.920|     107.840
> [...]
> RTS|      65.920|      73.868|     132.480|       0|    00:00:30/00:00:30
> 
> # ./latency -t2 -p1000 -T30
> == Sampling period: 1000 us
> == Test mode: in-kernel timer handler
> == All results in microseconds
> warming up...
> RTT|  00:00:01  (in-kernel timer handler, 1000 us period, priority 99)
> RTH|-----lat min|-----lat avg|-----lat max|-overrun|----lat best|---lat worst
> RTD|      21.120|      25.826|      39.680|       0|      21.120|      39.680
> RTD|      21.120|      26.073|      39.360|       0|      21.120|      39.680
> [...]
> RTS|      20.800|      25.987|      54.400|       0|    00:00:30/00:00:30
> 
> # ./cyclictest -t5 -l 30000
> T: 0 (   68) P:99 I:    1000 C:   30000 Min:      96 Act:     135 Avg:
>     144 Max:     177
> T: 1 (   69) P:98 I:    1500 C:   30000 Min:      96 Act:     130 Avg:
>     216 Max:     483
> T: 2 (   70) P:97 I:    2000 C:   30000 Min:     128 Act:     133 Avg:
>     313 Max:     704
> T: 3 (   71) P:96 I:    2500 C:   30000 Min:      98 Act:     136 Avg:
>     292 Max:     932
> T: 4 (   72) P:95 I:    3000 C:   30000 Min:     127 Act:     135 Avg:
>     470 Max:    1378
> 
> # ./switchbench -n10000 -p 1000
> == Sampling period: 1000 us
> == Do not interrupt this program
> RTH|     lat min|     lat avg|     lat max|        lost
> RTD|     144.960|     156.160|     162.240|           0
> 
> # ./switchtest -T30 -n
> == Threads: sleeper-0 rtk-1 rtk-2 rtup-3 rtup-4 rtus-5 rtus-6 rtuo-7 rtuo-8
> RTT|  00:00:01
> RTH|ctx switches|-------total
> RTD|         999|         999
> RTD|         993|        1992
> RTD|        1005|        2997
> RTD|         999|        3996
> RTD|        1008|        5004
> RTD|         993|        5997
> RTD|        1005|        7002
> RTD|         999|        8001
> RTD|         999|        9000
> RTD|         999|        9999
> RTD|         993|       10992

First, it's nice to see that all tests passed without oops, system hang
or large latency figures. Your results are reasonable for your test
scenario. I remember similar results on my TQM860L module under Linux
2.4.25. Your target is a very low-end PowerPC system with little cache
(min latency is rather close to max latency) and it's already a pain to
run Linux 2.6 on it. But you should apply more load and run the test
much longer to get realistic worst case latency figures, which are
likely higher then the values listed above. I usually use "while ls; do
ls; done" in a telnet window, "ping -f <host-ip>" and the cache
calibrator to produce high load. And do not forget to add "cat
/proc/xenomai/latency" to the above figures.

Wolfgang,

Re: [Xenomai-help] Xenomai latency tests on MPC8xx

[Wolfgang Grandegger]

fabien wrote:
> Here, there is some xenomai tests on a MPC855T, could you comment
> these results please ?
> Are they correct ?
> 
> # cat cpuinfo
> processor       : 0
> cpu             : 8xx
> clock           : 50MHz
> bus clock       : 50MHz
> revision        : 0.0 (pvr 0050 0000)
> bogomips        : 48.38
> 
> The kernel is a 2.6.23-6 (ppc branch) from DENX git repository,
> Xenomai 2.4.0, and adeo-ipipe patch :
> adeos-ipipe-2.6.23-ppc-1.6-00.patch.
> 
> I'm new in realtime system and xenomai so i have also some questions :
> First, what's the purpose of the cyclic and switchbench test ?

Cyclictest is a POSIX application measuring user space task scheduling
latencies. See also http://rt.wiki.kernel.org/index.php/Cyclictest.

> How could i interpret the results of switchtest ?
> And finaly, it's seem there is something wrong with irqloop test, but what ?

irqloop is not applicable for your hardware as it does not have a
parallel port or a 16550-compatible serial interface. Please check
http://www.rts.uni-hannover.de/xenomai/lxr/source/doc/txt/irqbench.txt.

FYI, I'm currently extending irqbench to work with GPIO port pins,
especially to measure latencies for PowerPC embedded boards.

Wolfgang.

Re: [Xenomai-help] Xenomai latency tests on MPC8xx

[fabien]

Hello, first thank for your advices Wolfgang.

2008/1/7, Wolfgang Grandegger <wg@domain.hid>:
> fabien wrote:
> > Here, there is some xenomai tests on a MPC855T, could you comment
> > these results please ?
> > Are they correct ?
> >
> > # cat cpuinfo
> > processor       : 0
> > cpu             : 8xx
> > clock           : 50MHz
> > bus clock       : 50MHz
> > revision        : 0.0 (pvr 0050 0000)
> > bogomips        : 48.38
> >
> > The kernel is a 2.6.23-6 (ppc branch) from DENX git repository,
> > Xenomai 2.4.0, and adeo-ipipe patch :
> > adeos-ipipe-2.6.23-ppc-1.6-00.patch.
> >
> > I'm new in realtime system and xenomai so i have also some questions :
> > First, what's the purpose of the cyclic and switchbench test ?
> > How could i interpret the results of switchtest ?
> > And finaly, it's seem there is something wrong with irqloop test, but what ?
> >
> > First, tests without load :
> >
> > # ./latency -t0 -p1000 -T30
> > == Sampling period: 1000 us
> > == Test mode: periodic user-mode task
> > == All results in microseconds
> > warming up...
> > RTT|  00:00:01  (periodic user-mode task, 1000 us period, priority 99)
> > RTH|-----lat min|-----lat avg|-----lat max|-overrun|----lat best|---lat worst
> > RTD|      75.520|      84.480|     128.640|       0|      75.520|     128.640
> > RTD|      75.520|      86.080|     136.960|       0|      75.520|     136.960
> > [...]
> > RTS|      75.520|      86.080|     185.920|       0|    00:00:30/00:00:30
> >
> > # ./latency -t1 -p1000 -T30
> > == Sampling period: 1000 us
> > == Test mode: in-kernel periodic task
> > == All results in microseconds
> > warming up...
> > RTT|  00:00:01  (in-kernel periodic task, 1000 us period, priority 99)
> > RTH|-----lat min|-----lat avg|-----lat max|-overrun|----lat best|---lat worst
> > RTD|      56.960|      66.118|      92.800|       0|      56.960|      92.800
> > RTD|      56.960|      66.777|     106.240|       0|      56.960|     106.240
> > RTD|      56.960|      66.037|     136.640|       0|      56.960|     136.640
> > [...]
> > RTS|      56.960|      66.308|     149.440|       0|    00:00:30/00:00:30
> >
> > # ./latency -t2 -p1000 -T30
> > == Sampling period: 1000 us
> > == Test mode: in-kernel timer handler
> > == All results in microseconds
> > warming up...
> > RTT|  00:00:01  (in-kernel timer handler, 1000 us period, priority 99)
> > RTH|-----lat min|-----lat avg|-----lat max|-overrun|----lat best|---lat worst
> > RTD|      18.560|      20.938|      34.880|       0|      18.560|      34.880
> > RTD|      18.560|      21.446|      45.760|       0|      18.560|      45.760
> > [...]
> > RTS|      18.560|      21.320|     118.400|       0|    00:00:30/00:00:30
> >
> > # ./cyclictest -t5 -l 30000
> > T: 0 (   64) P:99 I:    1000 C:   30000 Min:      97 Act:     138 Avg:
> >     127 Max:     180
> > T: 1 (   65) P:98 I:    1500 C:   30000 Min:      97 Act:     101 Avg:
> >     195 Max:     431
> > T: 2 (   66) P:97 I:    2000 C:   30000 Min:      97 Act:     138 Avg:
> >     290 Max:     660
> > T: 3 (   67) P:96 I:    2500 C:   25569 Min:      95 Act:     881 Avg:
> >     286 Max:     881
> > T: 4 (   68) P:95 I:    3000 C:   21308 Min:      96 Act:     168 Avg:
> >     552 Max:    1354
> >
> > # ./switchbench -n10000 -p 1000
> > == Sampling period: 1000 us
> > == Do not interrupt this program
> > RTH|     lat min|     lat avg|     lat max|        lost
> > RTD|     137.920|     143.040|     160.640|           0
> >
> > # ./switchtest -T30 -n
> > == Threads: sleeper-0 rtk-1 rtk-2 rtup-3 rtup-4 rtus-5 rtus-6 rtuo-7 rtuo-8
> > RTT|  00:00:01
> > RTH|ctx switches|-------total
> > RTD|         999|         999
> > RTD|         993|        1992
> > RTD|        1005|        2997
> > RTD|         999|        3996
> > RTD|         993|        4989
> > RTD|        1005|        5994
> > RTD|         999|        6993
> > RTD|         990|        7983
> > RTD|         993|        8976
> > RTD|        1005|        9981
> > RTD|         999|       10980
> > [...]
> >
> > # insmod ./xeno_irqbench.ko
> > # ./irqloop -t0
> > irqloop: error starting test: Inappropriate ioctl for device
> > Xenomai: POSIX: destroyed thread c03a0e10
> > # lsmod
> > Module                  Size  Used by    Not tainted
> > xeno_irqbench           9788  -
> > xeno_posix            179428  -
> > xeno_switchtest         8704  -
> > xeno_rtdm              30572  -
> > #
> >
> >
> >
> > ----
> > Now tests with load : dd if=/dev/zero of=/dev/null
> > ----
> >
> > # ./latency -t0 -p1000 -T30
> > == Sampling period: 1000 us
> > == Test mode: periodic user-mode task
> > == All results in microseconds
> > warming up...
> > RTT|  00:00:01  (periodic user-mode task, 1000 us period, priority 99)
> > RTH|-----lat min|-----lat avg|-----lat max|-overrun|----lat best|---lat worst
> > RTD|     108.160|     119.680|     133.760|       0|     108.160|     133.760
> > RTD|     115.840|     120.000|     154.240|       0|     108.160|     154.240
> > [...]
> > RTS|      95.040|     119.680|     202.880|       0|    00:00:30/00:00:30
> >
> > # ./latency -t1 -p1000 -T30
> > == Sampling period: 1000 us
> > == Test mode: in-kernel periodic task
> > == All results in microseconds
> > warming up...
> > RTT|  00:00:01  (in-kernel periodic task, 1000 us period, priority 99)
> > RTH|-----lat min|-----lat avg|-----lat max|-overrun|----lat best|---lat worst
> > RTD|      65.920|      73.409|     100.480|       0|      65.920|     100.480
> > RTD|      65.920|      74.055|     107.840|       0|      65.920|     107.840
> > RTD|      65.920|      73.954|     100.800|       0|      65.920|     107.840
> > [...]
> > RTS|      65.920|      73.868|     132.480|       0|    00:00:30/00:00:30
> >
> > # ./latency -t2 -p1000 -T30
> > == Sampling period: 1000 us
> > == Test mode: in-kernel timer handler
> > == All results in microseconds
> > warming up...
> > RTT|  00:00:01  (in-kernel timer handler, 1000 us period, priority 99)
> > RTH|-----lat min|-----lat avg|-----lat max|-overrun|----lat best|---lat worst
> > RTD|      21.120|      25.826|      39.680|       0|      21.120|      39.680
> > RTD|      21.120|      26.073|      39.360|       0|      21.120|      39.680
> > [...]
> > RTS|      20.800|      25.987|      54.400|       0|    00:00:30/00:00:30
> >
> > # ./cyclictest -t5 -l 30000
> > T: 0 (   68) P:99 I:    1000 C:   30000 Min:      96 Act:     135 Avg:
> >     144 Max:     177
> > T: 1 (   69) P:98 I:    1500 C:   30000 Min:      96 Act:     130 Avg:
> >     216 Max:     483
> > T: 2 (   70) P:97 I:    2000 C:   30000 Min:     128 Act:     133 Avg:
> >     313 Max:     704
> > T: 3 (   71) P:96 I:    2500 C:   30000 Min:      98 Act:     136 Avg:
> >     292 Max:     932
> > T: 4 (   72) P:95 I:    3000 C:   30000 Min:     127 Act:     135 Avg:
> >     470 Max:    1378
> >
> > # ./switchbench -n10000 -p 1000
> > == Sampling period: 1000 us
> > == Do not interrupt this program
> > RTH|     lat min|     lat avg|     lat max|        lost
> > RTD|     144.960|     156.160|     162.240|           0
> >
> > # ./switchtest -T30 -n
> > == Threads: sleeper-0 rtk-1 rtk-2 rtup-3 rtup-4 rtus-5 rtus-6 rtuo-7 rtuo-8
> > RTT|  00:00:01
> > RTH|ctx switches|-------total
> > RTD|         999|         999
> > RTD|         993|        1992
> > RTD|        1005|        2997
> > RTD|         999|        3996
> > RTD|        1008|        5004
> > RTD|         993|        5997
> > RTD|        1005|        7002
> > RTD|         999|        8001
> > RTD|         999|        9000
> > RTD|         999|        9999
> > RTD|         993|       10992
>
> First, it's nice to see that all tests passed without oops, system hang
> or large latency figures. Your results are reasonable for your test
> scenario. I remember similar results on my TQM860L module under Linux
> 2.4.25. Your target is a very low-end PowerPC system with little cache
> (min latency is rather close to max latency) and it's already a pain to
> run Linux 2.6 on it. But you should apply more load and run the test
> much longer to get realistic worst case latency figures, which are
> likely higher then the values listed above. I usually use "while ls; do
> ls; done" in a telnet window, "ping -f <host-ip>" and the cache
> calibrator to produce high load. And do not forget to add "cat
> /proc/xenomai/latency" to the above figures.
>
> Wolfgang,
>
>

I did the same test with :
a ping -f
telnet session : while ls; do ls; done
and a dd if=/dev/zero of=/dev/null

And i got the following results :
./latency -t0 -p1000 -T500
RTS|      86.400|     131.200|     229.440|       0|    00:08:21/00:08:20

# cat /proc/xenomai/latency
4160

./latency -t1 -p1000 -T500
RTS|      63.040|      92.998|     180.480|       0|    00:08:21/00:08:20

./latency -t2 -p1000 -T500
RTS|      20.480|      36.130|     123.200|       0|    00:08:21/00:08:20

# ./cyclictest -t5 -l 30000 -q
T: 0 (  563) P:99 I:    1000 C:   30000 Min:      97 Act:     142 Avg:
    150 Max:     216
T: 1 (  564) P:98 I:    1500 C:   30000 Min:      95 Act:     142 Avg:
    228 Max:     574
T: 2 (  565) P:97 I:    2000 C:   30000 Min:     102 Act:     141 Avg:
    335 Max:     776
T: 3 (  566) P:96 I:    2500 C:   30000 Min:      96 Act:     138 Avg:
    303 Max:     964
T: 4 (  567) P:95 I:    3000 C:   30000 Min:     123 Act:     143 Avg:
    481 Max:    1458

# ./switchbench -n100000 -p 1000
== Sampling period: 1000 us
== Do not interrupt this program
RTH|     lat min|     lat avg|     lat max|        lost
RTD|     140.480|     176.000|     276.480|           0

# ./switchtest -T30 -n
== Threads: sleeper-0 rtk-1 rtk-2 rtup-3 rtup-4 rtus-5 rtus-6 rtuo-7 rtuo-8
RTT|  00:00:03
RTH|ctx switches|-------total
RTD|         666|         666
RTD|           3|         669
RTD|          15|         684
RTD|          12|         696

I think the tests are correct ?
exept for the latter that is catastrophic .... just when i applied the ping -f
What do you think about this results ?

Best regards

Re: [Xenomai-help] Xenomai latency tests on MPC8xx

[Wolfgang Grandegger]

fabien wrote:
> Hello, first thank for your advices Wolfgang.
> 
> 2008/1/7, Wolfgang Grandegger <wg@domain.hid>:
>> fabien wrote:
>>> Here, there is some xenomai tests on a MPC855T, could you comment
>>> these results please ?
>>> Are they correct ?
[...deletions...]
> First, it's nice to see that all tests passed without oops, system hang
>> or large latency figures. Your results are reasonable for your test
>> scenario. I remember similar results on my TQM860L module under Linux
>> 2.4.25. Your target is a very low-end PowerPC system with little cache
>> (min latency is rather close to max latency) and it's already a pain to
>> run Linux 2.6 on it. But you should apply more load and run the test
>> much longer to get realistic worst case latency figures, which are
>> likely higher then the values listed above. I usually use "while ls; do
>> ls; done" in a telnet window, "ping -f <host-ip>" and the cache
>> calibrator to produce high load. And do not forget to add "cat
>> /proc/xenomai/latency" to the above figures.
>>
>> Wolfgang,
>>
>>
> 
> I did the same test with :
> a ping -f
> telnet session : while ls; do ls; done
> and a dd if=/dev/zero of=/dev/null
> 
> And i got the following results :
> ./latency -t0 -p1000 -T500
> RTS|      86.400|     131.200|     229.440|       0|    00:08:21/00:08:20
> 
> # cat /proc/xenomai/latency
> 4160
> 
> ./latency -t1 -p1000 -T500
> RTS|      63.040|      92.998|     180.480|       0|    00:08:21/00:08:20
> 
> ./latency -t2 -p1000 -T500
> RTS|      20.480|      36.130|     123.200|       0|    00:08:21/00:08:20
> 
> # ./cyclictest -t5 -l 30000 -q
> T: 0 (  563) P:99 I:    1000 C:   30000 Min:      97 Act:     142 Avg:
>     150 Max:     216
> T: 1 (  564) P:98 I:    1500 C:   30000 Min:      95 Act:     142 Avg:
>     228 Max:     574
> T: 2 (  565) P:97 I:    2000 C:   30000 Min:     102 Act:     141 Avg:
>     335 Max:     776
> T: 3 (  566) P:96 I:    2500 C:   30000 Min:      96 Act:     138 Avg:
>     303 Max:     964
> T: 4 (  567) P:95 I:    3000 C:   30000 Min:     123 Act:     143 Avg:
>     481 Max:    1458
> 
> # ./switchbench -n100000 -p 1000
> == Sampling period: 1000 us
> == Do not interrupt this program
> RTH|     lat min|     lat avg|     lat max|        lost
> RTD|     140.480|     176.000|     276.480|           0
> 
> # ./switchtest -T30 -n
> == Threads: sleeper-0 rtk-1 rtk-2 rtup-3 rtup-4 rtus-5 rtus-6 rtuo-7 rtuo-8
> RTT|  00:00:03
> RTH|ctx switches|-------total
> RTD|         666|         666
> RTD|           3|         669
> RTD|          15|         684
> RTD|          12|         696
> 
> I think the tests are correct ?

Yes, and the results are reasonable, apart from the last one...

> exept for the latter that is catastrophic .... just when i applied the ping -f
> What do you think about this results ?

... likely because the system is overloaded with 30 tasks.

Wolfgang.

[Xenomai-help] Shared Memory mmap fails

[Roderik.Wildenburg]

[-- Attachment #1: Type: text/plain, Size: 964 bytes --]

Dear Xenomai Pros,

executing the attached code snippet(a very much striped down satch.c example) results in the following error message.

# ./satch
mmap(producer_shm): 6

This means : "ENXIO, the range [off;off+len) is invalid for the shared memory region specified by fd;"

This problem does not only occur in this small example but also in my application.
Therefore and as I can´t see any obvious  mistake in this example, I think this could be a problem of Xenomai. 
Could somedbody try to execute this example and validate if there is a general problem ?
I use Xenomai 2.3.5 on a 2.4.25 PPC-kernel.

Thank you very much in advance
Roderik 

MAN Roland Druckmaschinen AG
Vorsitzender des Aufsichtsrates: Hanno C. Fiedler
Vorstand: Gerd Finkbeiner (Vorsitzender), Dr. Ingo Koch, Dr. Markus Rall, Paul Steidle    
Sitz der Gesellschaft: Offenbach am Main, Registergericht: Amtsgericht Offenbach HRB-Nr. 42592    
USt-Ident-Nr. DE 250200933

[-- Attachment #2: satch.c --]
[-- Type: application/octet-stream, Size: 1414 bytes --]

#include <stdio.h>

#include <time.h>
#include <errno.h>
#include <unistd.h>
#include <signal.h>
#include <sys/mman.h>
#include <pthread.h>
#include <mqueue.h>
#include <posix/posix.h>

#define SHM_NAME "/satchshm"

static void *producer_shm = MAP_FAILED;


void __xeno_user_exit (void)
{
    if (producer_shm != MAP_FAILED)
        munmap(producer_shm, 65536);
    shm_unlink(SHM_NAME);
}

int __xeno_user_init (void)

{
    int fd = -1;

    fd = shm_open(SHM_NAME, O_CREAT | O_RDWR, 0777);
    if (fd == -1)
        {
        printf("shm_open: %d\n", errno);
        return -errno;
        }

    if (ftruncate(fd, 65536))
        {
        printf("ftruncate: %d\n", errno);
        close(fd);
        return(-1);
        }

    
    producer_shm = mmap(NULL, 65536, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0);
    if (producer_shm == MAP_FAILED)
        {
        printf("mmap(producer_shm): %d\n", errno);
        return -errno;
        }
   return(fd);
}

int main (int ac, char *av[])

{
    sigset_t mask;
    int rc, sig;

    sigemptyset(&mask);
    sigaddset(&mask,SIGINT);
    sigaddset(&mask,SIGTERM);
    sigaddset(&mask,SIGHUP);
    sigaddset(&mask,SIGALRM);

    pthread_sigmask(SIG_BLOCK, &mask, NULL);

    mlockall(MCL_CURRENT|MCL_FUTURE);

    rc = __xeno_user_init();

    if (rc>0)
        {
           close(rc);
        }

    sigwait(&mask, &sig);
    __xeno_user_exit();

    return 0;
}

[-- Attachment #3: Makefile --]
[-- Type: application/octet-stream, Size: 389 bytes --]

APPLICATIONS = satch

all::

satch: satch.c



### Default Xenomai installation path
XENO ?= /opt/eldk/xenomai

XENOCONFIG=$(shell PATH=$(XENO):$(XENO)/bin:$(PATH) which xeno-config 2>/dev/null)


CC=$(shell $(XENOCONFIG) --cc)

CFLAGS= $(shell $(XENOCONFIG) --posix-cflags)

LDFLAGS=$(shell $(XENOCONFIG) --posix-ldflags)


all:: $(APPLICATIONS)

clean::
	$(RM) $(APPLICATIONS) *.o

Re: [Xenomai-help] Shared Memory mmap fails

[Gilles Chanteperdrix]

[-- Attachment #1: Type: text/plain, Size: 864 bytes --]

 Jan 10, 2008 9:54 AM,  <Roderik.Wildenburg@domain.hid> wrote:
> Dear Xenomai Pros,
>
> executing the attached code snippet(a very much striped down satch.c example) results in the following error message.
>
> # ./satch
> mmap(producer_shm): 6
>
> This means : "ENXIO, the range [off;off+len) is invalid for the shared memory region specified by fd;"
>
> This problem does not only occur in this small example but also in my application.
> Therefore and as I can´t see any obvious  mistake in this example, I think this could be a problem of Xenomai.
> Could somedbody try to execute this example and validate if there is a general problem ?
> I use Xenomai 2.3.5 on a 2.4.25 PPC-kernel.
>
> Thank you very much in advance
> Roderik

Could you try the attached patch ?

-- 
                                               Gilles Chanteperdrix

[-- Attachment #2: xeno-posix-revert-commit-3245.diff --]
[-- Type: application/octet-stream, Size: 1082 bytes --]

Index: ksrc/skins/posix/shm.c
===================================================================
--- ksrc/skins/posix/shm.c	(révision 3245)
+++ ksrc/skins/posix/shm.c	(révision 3244)
@@ -494,6 +494,11 @@
 		goto err_shm_put;
 	}
 
+	/* Allocate one more page for alignment (the address returned by mmap
+	   must be aligned). */
+	if (len)
+		len = xnheap_rounded_size(len + PAGE_SIZE, PAGE_SIZE);
+
 	err = 0;
 	if (emptyq_p(&shm->mappings)) {
 		/* Temporary storage, in order to preserve the memory contents upon
@@ -525,18 +530,12 @@
 
 		if (len) {
 #ifdef CONFIG_XENO_OPT_PERVASIVE
-			int flags;
-			len = xnheap_rounded_size(len, PAGE_SIZE);
-			flags = len <= 128 * 1024 ? GFP_USER : 0;
+			int flags = len <= 128 * 1024 ? GFP_USER : 0;
 			err = -xnheap_init_mapped(&shm->heapbase, len, flags);
 #else /* !CONFIG_XENO_OPT_PERVASIVE. */
 			{
-				void *heapaddr;
+				void *heapaddr = xnarch_sysalloc(len);
 
-				len = xnheap_rounded_size(len, PAGE_SIZE);
-
-				heapaddr = xnarch_sysalloc(len);
-
 				if (heapaddr)
 					err =
 					    -xnheap_init(&shm->heapbase,

Re: [Xenomai-help] Shared Memory mmap fails

[Roderik.Wildenburg]

Perfect !
Thank you very much for the super rapid response and solution.

Yours respectfully
Roderik


> -----Ursprüngliche Nachricht-----
> Von: Gilles Chanteperdrix [mailto:gilles.chanteperdrix@xenomai.org
> Gesendet: Donnerstag, 10. Januar 2008 15:05
> An: Wildenburg, Roderik RAEK3 MRA
> Cc: xenomai@xenomai.org
> Betreff: Re: [Xenomai-help] Shared Memory mmap fails
> 
>  Jan 10, 2008 9:54 AM,  <Roderik.Wildenburg@domain.hid> wrote:
> > Dear Xenomai Pros,
> >
> > executing the attached code snippet(a very much striped 
> down satch.c example) results in the following error message.
> >
> > # ./satch
> > mmap(producer_shm): 6
> >
> > This means : "ENXIO, the range [off;off+len) is invalid for 
> the shared memory region specified by fd;"
> >
> > This problem does not only occur in this small example but 
> also in my application.
> > Therefore and as I can´t see any obvious  mistake in this 
> example, I think this could be a problem of Xenomai.
> > Could somedbody try to execute this example and validate if 
> there is a general problem ?
> > I use Xenomai 2.3.5 on a 2.4.25 PPC-kernel.
> >
> > Thank you very much in advance
> > Roderik
> 
> Could you try the attached patch ?
> 
> -- 
>                                                Gilles Chanteperdrix
> 

MAN Roland Druckmaschinen AG
Vorsitzender des Aufsichtsrates: Hanno C. Fiedler
Vorstand: Gerd Finkbeiner (Vorsitzender), Dr. Ingo Koch, Dr. Markus Rall, Paul Steidle    
Sitz der Gesellschaft: Offenbach am Main, Registergericht: Amtsgericht Offenbach HRB-Nr. 42592    
USt-Ident-Nr. DE 250200933