* [Xenomai-help] xenomai for mach-imx.
@ 2007-06-06 14:42 garryt
2007-06-06 15:10 ` Jan Kiszka
0 siblings, 1 reply; 2+ messages in thread
From: garryt @ 2007-06-06 14:42 UTC (permalink / raw)
To: xenomai
Hello,
I have compiled xenomai for an mach-imx (MC9328 MX-1) with ipipe 1.7-03. This
include small modifications to files according to the “adapting ARM I-pipe patch
to a new board” Documentation taht i could provide 4 sure.
By the way there is an additional __ipipe_mach_get_tscinfo function to define..
ipipe is 1.7-03, Linux kernel is 2.6.20 and xenomai from svn trunk.
I then run the testsuite to be sure that it is ok...Could someone on this list
tell me if these results are valid and similar to close architecture ?
Unfortunately i only have this board and nothing to compare to...
By the way would it be a possible "idea" to create a repository of results of
testsuite prgs on different architure ( with no load for example ? ) from people
on this list ? I have looked with no success for that...
Anyway here are the results from various tests that I run for only few seconds,
but further testing shows me this is stable.
All these tests were performed with no extra load...
--------------------------------------------
# arm-latency -t 0 -T 10 -p 1000
== 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| 7.312| 101.812| 107.750| 0| 7.312| 107.750
RTD| 7.187| 46.750| 108.625| 0| 7.187| 108.625
RTD| 7.187| 45.500| 113.437| 0| 7.187| 113.437
RTD| 6.937| 44.812| 107.875| 0| 6.937| 113.437
RTD| 6.937| 43.562| 112.750| 0| 6.937| 113.437
RTD| 7.187| 42.875| 108.562| 0| 6.937| 113.437
RTD| 6.937| 41.687| 114.375| 0| 6.937| 114.375
RTD| 7.187| 41.000| 107.937| 0| 6.937| 114.375
RTD| 6.937| 39.875| 111.000| 0| 6.937| 114.375
---|------------|------------|------------|--------|-------------------------
RTS| 6.937| 49.750| 114.375| 0| 00:00:10/00:00:10
# arm-latency -t 1 -T 10 -p 1000
== 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| 3.312| 3.735| 44.125| 0| 3.312| 44.125
RTD| 3.312| 3.769| 43.687| 0| 3.312| 44.125
RTD| 3.312| 3.843| 43.687| 0| 3.312| 44.125
RTD| 3.312| 3.741| 43.687| 0| 3.312| 44.125
RTD| 3.312| 3.823| 44.125| 0| 3.312| 44.125
RTD| 3.375| 3.742| 43.750| 0| 3.312| 44.125
RTD| 3.375| 3.822| 44.250| 0| 3.312| 44.250
RTD| 3.312| 3.777| 43.625| 0| 3.312| 44.250
RTD| 3.312| 3.821| 43.875| 0| 3.312| 44.250
---|------------|------------|------------|--------|-------------------------
RTS| 3.312| 3.785| 44.250| 0| 00:00:10/00:00:10
# arm-latency -t 2 -T 10 -p 1000
== 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| -3.500| -3.385| 16.125| 0| -3.500| 16.125
RTD| -3.500| -3.327| 16.063| 0| -3.500| 16.125
RTD| -3.562| -3.337| 16.063| 0| -3.562| 16.125
RTD| -3.500| -3.341| 15.938| 0| -3.562| 16.125
RTD| -3.562| -3.333| 16.125| 0| -3.562| 16.125
RTD| -3.500| -3.339| 16.563| 0| -3.562| 16.563
RTD| -3.500| -3.342| 16.125| 0| -3.562| 16.563
RTD| -3.562| -3.341| 16.000| 0| -3.562| 16.563
RTD| -3.500| -3.336| 16.188| 0| -3.562| 16.563
---|------------|------------|------------|--------|-------------------------
RTS| -3.562| -3.342| 16.563| 0| 00:00:10/00:00:10
?? <0 results ?? is there a particular meaning to this...
# ./arm-cyclictest -l 20000
0.00 0.00 0.00 1/24 290
T: 0 ( 290) P:99 I: 1000 C: 20000 Min: 12 Act: 12 Avg: 21 1
Xenomai: POSIX: destroyed thread c0c01320
# arm-switchbench
== Sampling period: 100 us
== Do not interrupt this program
RTH| lat min| lat avg| lat max| lost
RTD| 15.625| 7.625| 83.187| 51470
# arm-switchbench -n 20000
== Sampling period: 100 us
== Do not interrupt this program
RTH| lat min| lat avg| lat max| lost
RTD| 14.875| 6.000| 32.937| 12422
almost lost??
# arm-switchbench -n 20000 -p 300
== Sampling period: 300 us
== Do not interrupt this program
RTH| lat min| lat avg| lat max| lost
RTD| 15.625| 48.312| 89.062| 0
# arm-switchtest -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| 900| 900
RTD| 909| 1809
RTD| 903| 2712
RTD| 906| 3618
RTD| 909| 4527
RTD| 909| 5436
RTD| 909| 6345
RTD| 900| 7245
RTD| 900| 8145
RTD| 900| 9045
RTD| 909| 9954
RTD| 333| 10287
Xenomai: POSIX: destroyed thread c0c00b20
Thanks for your answer, this mail is long, sorry ;)
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: [Xenomai-help] xenomai for mach-imx.
2007-06-06 14:42 [Xenomai-help] xenomai for mach-imx garryt
@ 2007-06-06 15:10 ` Jan Kiszka
0 siblings, 0 replies; 2+ messages in thread
From: Jan Kiszka @ 2007-06-06 15:10 UTC (permalink / raw)
To: garryt; +Cc: xenomai
[-- Attachment #1: Type: text/plain, Size: 7267 bytes --]
garryt wrote:
> Hello,
>
> I have compiled xenomai for an mach-imx (MC9328 MX-1) with ipipe 1.7-03. This
> include small modifications to files according to the “adapting ARM I-pipe patch
> to a new board” Documentation taht i could provide 4 sure.
> By the way there is an additional __ipipe_mach_get_tscinfo function to define..
>
> ipipe is 1.7-03, Linux kernel is 2.6.20 and xenomai from svn trunk.
>
> I then run the testsuite to be sure that it is ok...Could someone on this list
> tell me if these results are valid and similar to close architecture ?
> Unfortunately i only have this board and nothing to compare to...
>
> By the way would it be a possible "idea" to create a repository of results of
> testsuite prgs on different architure ( with no load for example ? ) from people
> on this list ? I have looked with no success for that...
This idea exists for a long time, it "just" requires some effort to
implement it. Basically, all pieces are there: testsuites, load
descriptions, broad user base. We only need a well-defined procedure to
collect the data.
One idea, surely the most elegant one, is to do this automatically, have
a database back-end + web front-end and make the user only hit "submit"
in some benchmark tool. But maybe a more reachable approach could be to
open a new Wiki page and upload stuff there. Anyone willing to give this
a start, e.g. by defining the layout, describing the steps to obtain data?
>
> Anyway here are the results from various tests that I run for only few seconds,
> but further testing shows me this is stable.
>
> All these tests were performed with no extra load...
And thus they are almost meaningless. Please read the TROUBLESHOOTING
file on this topic ("How do I adequately stress-test?").
>
> --------------------------------------------
> # arm-latency -t 0 -T 10 -p 1000
> == 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| 7.312| 101.812| 107.750| 0| 7.312| 107.750
> RTD| 7.187| 46.750| 108.625| 0| 7.187| 108.625
> RTD| 7.187| 45.500| 113.437| 0| 7.187| 113.437
> RTD| 6.937| 44.812| 107.875| 0| 6.937| 113.437
> RTD| 6.937| 43.562| 112.750| 0| 6.937| 113.437
> RTD| 7.187| 42.875| 108.562| 0| 6.937| 113.437
> RTD| 6.937| 41.687| 114.375| 0| 6.937| 114.375
> RTD| 7.187| 41.000| 107.937| 0| 6.937| 114.375
> RTD| 6.937| 39.875| 111.000| 0| 6.937| 114.375
> ---|------------|------------|------------|--------|-------------------------
> RTS| 6.937| 49.750| 114.375| 0| 00:00:10/00:00:10
>
> # arm-latency -t 1 -T 10 -p 1000
> == 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| 3.312| 3.735| 44.125| 0| 3.312| 44.125
> RTD| 3.312| 3.769| 43.687| 0| 3.312| 44.125
> RTD| 3.312| 3.843| 43.687| 0| 3.312| 44.125
> RTD| 3.312| 3.741| 43.687| 0| 3.312| 44.125
> RTD| 3.312| 3.823| 44.125| 0| 3.312| 44.125
> RTD| 3.375| 3.742| 43.750| 0| 3.312| 44.125
> RTD| 3.375| 3.822| 44.250| 0| 3.312| 44.250
> RTD| 3.312| 3.777| 43.625| 0| 3.312| 44.250
> RTD| 3.312| 3.821| 43.875| 0| 3.312| 44.250
> ---|------------|------------|------------|--------|-------------------------
> RTS| 3.312| 3.785| 44.250| 0| 00:00:10/00:00:10
>
>
> # arm-latency -t 2 -T 10 -p 1000
> == 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| -3.500| -3.385| 16.125| 0| -3.500| 16.125
> RTD| -3.500| -3.327| 16.063| 0| -3.500| 16.125
> RTD| -3.562| -3.337| 16.063| 0| -3.562| 16.125
> RTD| -3.500| -3.341| 15.938| 0| -3.562| 16.125
> RTD| -3.562| -3.333| 16.125| 0| -3.562| 16.125
> RTD| -3.500| -3.339| 16.563| 0| -3.562| 16.563
> RTD| -3.500| -3.342| 16.125| 0| -3.562| 16.563
> RTD| -3.562| -3.341| 16.000| 0| -3.562| 16.563
> RTD| -3.500| -3.336| 16.188| 0| -3.562| 16.563
> ---|------------|------------|------------|--------|-------------------------
> RTS| -3.562| -3.342| 16.563| 0| 00:00:10/00:00:10
>
> ?? <0 results ?? is there a particular meaning to this...
Too early shots. Xenomai's estimated scheduling latency that is taken
into account when programming a timer is too large.
>
> # ./arm-cyclictest -l 20000
> 0.00 0.00 0.00 1/24 290
>
> T: 0 ( 290) P:99 I: 1000 C: 20000 Min: 12 Act: 12 Avg: 21 1
> Xenomai: POSIX: destroyed thread c0c01320
>
>
> # arm-switchbench
> == Sampling period: 100 us
> == Do not interrupt this program
> RTH| lat min| lat avg| lat max| lost
> RTD| 15.625| 7.625| 83.187| 51470
>
> # arm-switchbench -n 20000
> == Sampling period: 100 us
> == Do not interrupt this program
> RTH| lat min| lat avg| lat max| lost
> RTD| 14.875| 6.000| 32.937| 12422
>
> almost lost??
Too short period, see your (unloaded!) numbers above.
>
> # arm-switchbench -n 20000 -p 300
> == Sampling period: 300 us
> == Do not interrupt this program
> RTH| lat min| lat avg| lat max| lost
> RTD| 15.625| 48.312| 89.062| 0
>
> # arm-switchtest -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| 900| 900
> RTD| 909| 1809
> RTD| 903| 2712
> RTD| 906| 3618
> RTD| 909| 4527
> RTD| 909| 5436
> RTD| 909| 6345
> RTD| 900| 7245
> RTD| 900| 8145
> RTD| 900| 9045
> RTD| 909| 9954
> RTD| 333| 10287
> Xenomai: POSIX: destroyed thread c0c00b20
>
> Thanks for your answer, this mail is long, sorry ;)
>
Jan
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2007-06-06 15:10 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2007-06-06 14:42 [Xenomai-help] xenomai for mach-imx garryt
2007-06-06 15:10 ` Jan Kiszka
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.