Re: [Xenomai-core] Cosmetic changes to script xeno-config + man page
> In order to compare Xenomai with other Debian packagees, I > checked gtk-config, and I have a few remarks on xeno-config > and its manpage. [...] I merely documented xeno-config as it is now, and made the printed usage consistent. If you modify it, I will update the manpage accordingly. Another item to add to the looOOong-term wishlist: I would like to have ready-to-use autoconf rules, to use instead of xeno-config. If someone ever writes such rules, e.g. in a "xenomai.m4" file, it would only be necessary, at Xenomai install time: 1- to copy xenomai.m4 into /usr/share/autoconf/autoconf/ 2- to add the following line into autoconf.m4: m4_include([autoconf/xenomai.m4]) 2- to regenerate autoconf.m4f by running: cd /usr/share/autoconf/autoconf autom4te --language=autoconf --freeze --output=autoconf.m4f A simpler solution would be to ship a xenomai.m4 to be used as a acinclude.m4 in every project using Xenomai. But I have had very bad experiences with aclocal in that use case. aclocal is quite buggy. And it would be more confortable for projects it is were immediately available after installing Xenomai. > Now, about the manpage itself, unless I am wrong, the DESTDIR > feature is not documented, it is very useful when compiling > for a target. DESTDIR is a feature of makefiles generated through Automake, not of xeno-config. Why would you like to document this is in xeno-config's manpage? -- Romain Lenglet ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] Xenomai latency tests on various PowerPC boards
Hallo, attached you will find the results of Xemonai latency measurements on various embedded PowerPC boards using MPC 8xx and AMCC 4xx processors, from low to high end covering a worst case latency range from 25 to 225 us. It also includes a comparison with RTAI 3.0r5 on the slowest CPU. Here are some remarks and comments: - On low-end processor code size matters a lot and it's difficult to beat RTAI/RTHAL. - Apart from the CPU power, big caches and a fast memory interface improves latencies. - L2 cache improves latencies a lot (compare Ocotea with Yosemite). - I'm a bit puzzled about the results of the "cruncher" test. Could someone explain the output, please? - Stability seems already quite good. At least I did not observe any crash yet :-). The PowerPC port of Xenomai is already in good shape. That's great! Wolfgang. Latency tests with Xenomai on various PowerPC boards Board : Processor CPU-Clk Bus-Clk I-Cache D-Cache Memory Remarks TQM860L : MPC 860 50 MHz 50 MHz4 KB4 kB 16 MB TQM866M : MPC 866133 MHz 66 MHz 16 KB8 kB 128 MB Walnut : AMCC 405GP 200 MHz 100 MHz 16 KB8 kB 32 MB Yosemite: AMCC 440EP 533 MHz 133 MHz 32 KB 32 KB 256 MB DDR-RAM, FPU Ocotea : AMCC 440GX 533 MHz 152 MHz 32 KB 32 KB 256 MB DDR-RAM, L2 256 KB Linux : DENX linux-2.6.14-rc3-g4c234921 iPipe : 1.0-00 Xenomai: SVN 2005-10-15 CRUNCER without load: | Ideal computation time TQM860L | 368 us ??? TQM866L | 10008 us Walnut | 10150 us Yosemite | 9911 us Ocotea | 9479 us SWITCH without load: | lat min| lat avg| lat max|lost TQM860L | 103360| 107840| 209280| 0 TQM866L | 25745| 31880| 51369| 5 Walnut | 24620| 25965| 32280| 1 Yosemite |5626|5655| 17403| 0 Ocotea |5158|5169| 10038| 0 KLATENCY with load: |-lat min|-lat avg|-lat max|-overrun|---test-time TQM860L | 50560| 98976| 199040| 0|00:09:45 TQM866L | 13835| 28571| 74348| 0|00:11:44 Walnut | 16195| 25062| 45755| 0|00:10:09 Yosemite |3106|9697| 36832| 0|00:09:55 Ocotea |3575|7438| 24474| 0|00:10:50 LATENCY with load: |-lat min|-lat avg|-lat max|-overrun|---test-time TQM860L | 60480| 120960| 224320| 0|00:09:46 TQM866L | 15759| 34286| 78799| 0|00:11:14 Walnut | 21070| 31650| 64500| 0|00:09:58 Yosemite |3808| 12163| 47898| 0|00:10:00 Ocotea |3575|7438| 24474| 0|00:10:50 KLATENCY comparison Xenomai 2.0 vs. RTAI/RTHAL 3.0r5 on TQM860L: --- KLATENCY with load: |-lat min|-lat avg|-lat max|-overrun|---test-time Xenomai 2.0 | 50560| 98976| 199040| 0|00:09:45 RTAI 3.0r5 | 23120| 31838| 70520| ?|00:12:26 Note: load has been put onto the system by running in a telnet session "ping -f " and "while ls; do ls; done". Note: all test have been run with CONFIG_XENO_HW_TIMER_LATENCY="1" and CONFIG_XENO_HW_SCHED_LATENCY="1" to get correct latancy values. RTAI figures have been corrected manually. xenomai-latencies-ppc.tgz Description: GNU Zip compressed data ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Testing the adeos-ipipe-2.6.13-ppc-1.0-00.patch
On 10/17/2005 05:42 PM Fillod Stephane wrote: > Hi Philippe, > > Sorry for the late report, Xenomai appears to work fine on a Freescale > e500 > board (MPC8541E) under Linux 2.6.13. Xenomai version was v1.9.9, ie. the > daily > snapshot as of today. Here are some preliminary figures (CPU 800MHz, Bus > 133MHz, > 32 kiB I-Cache 32 kiB D-Cache, 256 kiB L2): > > switch $ ./run > == Sampling period: 100 us > RTH| lat min| lat avg| lat max|lost > RTD|3660|3690|8070| 0 > > kaltency $ ./run > RTH|klat min|klat avg|klat max| overrun| > RTS| -7350| -5715|6420| 0| > 00:03:17/00:03:17 > > latency $ ./run > == Sampling period: 100 us > RTT| 00:08:04 > RTH|-lat min|-lat avg|-lat max|-overrun| > RTS| -6930| -4260|8700| 0| > 00:08:06/00:08:06 > > Load for klatency/latency was ping flooding on FCC (piece of cake), > and cache calibrator. IMHO, we can do nastier. Comparing the corrected latency figures (+9500ns) of your MPC8541E with my Ocotea-Board (AMCC 440 GX at 533 MHz) gives: Ocotea |3575|7438| 24474| 0|00:10:50 MPC8541E |2570|5240| 18200| 0| This scales rather well with the CPU clocks 533/800. L1 and L2 caches and the memory interface seem almost identical. Wolfgang. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [bug-reminder] user/kernel space header deps
Philippe Gerum wrote: > Gilles Chanteperdrix wrote: > >> Jan Kiszka wrote: >> > Hi, >> > > just to avoid that this issue got lost during the migration to >> Xenomai: >> >> Before it get lost again, maybe you would like to use our brand-new bug >> tracker ? >> >> https://gna.org/bugs/?func=additem&group=xenomai >> https://gna.org/bugs/index.php?func=detailitem&item_id=4545 > > Please add the kernel module compilation flags issue you once raised > too. This one will be solved when the build system is fully refactored > though. > https://gna.org/bugs/index.php?func=detailitem&item_id=4546 (nice to know that this one also causes some of my x86_64 issues) Jan signature.asc Description: OpenPGP digital signature ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Xenomai latency tests on various PowerPC boards
Wolfgang Grandegger wrote: Hallo, attached you will find the results of Xemonai latency measurements on various embedded PowerPC boards using MPC 8xx and AMCC 4xx processors, from low to high end covering a worst case latency range from 25 to 225 us. It also includes a comparison with RTAI 3.0r5 on the slowest CPU. Here are some remarks and comments: - On low-end processor code size matters a lot and it's difficult to beat RTAI/RTHAL. Beat no, get closer, yes, probably. The good news is that looking at the figures, we do have a margin of improvement! :o> Btw, the nucleus can be configured so that the user-space threading engine is compiled out (i.e. CONFIG_XENO_OPT_PERVASIVE from the nucleus menu), which would be the corresponding profile to compare with klatency (i.e. sched_up). Disabling this option reduces the code size for the nucleus from: textdata bss dec hex filename 66740 7926540 74072 12158 nucleus/xeno_nucleus.ko to: text data bss dec hex filename 52596 5763956 57128df28 nucleus/xeno_nucleus.ko Still a bit fat though. - Apart from the CPU power, big caches and a fast memory interface improves latencies. - L2 cache improves latencies a lot (compare Ocotea with Yosemite). - I'm a bit puzzled about the results of the "cruncher" test. Could someone explain the output, please? This test is reminiscent of the HYADES project (ia64 port of RTAI/fusion), where we wanted to illustrate the level of execution determinism one could achieve using the interrupt shield technique on large ia64 SMP systems. To this end, we measured the jitter in execution time of a calibrated float-crunching loop, with and without interrupt load. This test is likely going to disappear at some point in time, because it's not that informative in Xeno's context. - Stability seems already quite good. At least I did not observe any crash yet :-). That's cool. I see no other way to properly improve performances than first having something which could be run on various platforms without them randomly jumping out of the window, or us relying on plain Voodoo stuff to explain why those setup would work or not. The PowerPC port of Xenomai is already in good shape. That's great! Thanks. This is likely because I do feel better since I have been aware that there's life beyond x86. :o) Wolfgang. Latency tests with Xenomai on various PowerPC boards Board : Processor CPU-Clk Bus-Clk I-Cache D-Cache Memory Remarks TQM860L : MPC 860 50 MHz 50 MHz4 KB4 kB 16 MB TQM866M : MPC 866133 MHz 66 MHz 16 KB8 kB 128 MB Walnut : AMCC 405GP 200 MHz 100 MHz 16 KB8 kB 32 MB Yosemite: AMCC 440EP 533 MHz 133 MHz 32 KB 32 KB 256 MB DDR-RAM, FPU Ocotea : AMCC 440GX 533 MHz 152 MHz 32 KB 32 KB 256 MB DDR-RAM, L2 256 KB Linux : DENX linux-2.6.14-rc3-g4c234921 iPipe : 1.0-00 Xenomai: SVN 2005-10-15 CRUNCER without load: | Ideal computation time TQM860L | 368 us ??? TQM866L | 10008 us Walnut | 10150 us Yosemite | 9911 us Ocotea | 9479 us SWITCH without load: | lat min| lat avg| lat max|lost TQM860L | 103360| 107840| 209280| 0 TQM866L | 25745| 31880| 51369| 5 Walnut | 24620| 25965| 32280| 1 Yosemite |5626|5655| 17403| 0 Ocotea |5158|5169| 10038| 0 KLATENCY with load: |-lat min|-lat avg|-lat max|-overrun|---test-time TQM860L | 50560| 98976| 199040| 0|00:09:45 TQM866L | 13835| 28571| 74348| 0|00:11:44 Walnut | 16195| 25062| 45755| 0|00:10:09 Yosemite |3106|9697| 36832| 0|00:09:55 Ocotea |3575|7438| 24474| 0|00:10:50 LATENCY with load: |-lat min|-lat avg|-lat max|-overrun|---test-time TQM860L | 60480| 120960| 224320| 0|00:09:46 TQM866L | 15759| 34286| 78799| 0|00:11:14 Walnut | 21070| 31650| 64500| 0|00:09:58 Yosemite |3808| 12163| 47898| 0|00:10:00 Ocotea |3575|7438| 24474| 0|00:10:50 KLATENCY comparison Xenomai 2.0 vs. RTAI/RTHAL 3.0r5 on TQM860L: --- KLATENCY with load: |-lat min|-lat avg|-lat max|-overrun|---test-time Xenomai 2.0 | 50560| 98976| 199040| 0|00:09:45 RTAI 3.0r5 | 23120| 31838| 70520| ?|00:12:26 Note: load has been put onto the system by running in a telnet sessio
Re: [Xenomai-core] Xenomai latency tests on various PowerPC boards
Philippe Gerum wrote: Wolfgang Grandegger wrote: Hallo, attached you will find the results of Xemonai latency measurements on various embedded PowerPC boards using MPC 8xx and AMCC 4xx processors, from low to high end covering a worst case latency range from 25 to 225 us. It also includes a comparison with RTAI 3.0r5 on the slowest CPU. Here are some remarks and comments: - On low-end processor code size matters a lot and it's difficult to beat RTAI/RTHAL. Beat no, get closer, yes, probably. The good news is that looking at the figures, we do have a margin of improvement! :o> Btw, the nucleus can be configured so that the user-space threading engine is compiled out (i.e. CONFIG_XENO_OPT_PERVASIVE from the nucleus menu), which would be the corresponding profile to compare with klatency (i.e. sched_up). Disabling this option reduces the code size for the nucleus from: text databssdechexfilename 66740792 6540 74072 12158 nucleus/xeno_nucleus.ko to: text databssdechexfilename 52596576 3956 57128 df28 nucleus/xeno_nucleus.ko Disabling the periodic timer support which is unused for the klatency test brings this down to: textdata bss dec hex filename 51040 5443956 55540d8f4 nucleus/xeno_nucleus.ko Still a bit fat though. - Apart from the CPU power, big caches and a fast memory interface improves latencies. - L2 cache improves latencies a lot (compare Ocotea with Yosemite). - I'm a bit puzzled about the results of the "cruncher" test. Could someone explain the output, please? This test is reminiscent of the HYADES project (ia64 port of RTAI/fusion), where we wanted to illustrate the level of execution determinism one could achieve using the interrupt shield technique on large ia64 SMP systems. To this end, we measured the jitter in execution time of a calibrated float-crunching loop, with and without interrupt load. This test is likely going to disappear at some point in time, because it's not that informative in Xeno's context. - Stability seems already quite good. At least I did not observe any crash yet :-). That's cool. I see no other way to properly improve performances than first having something which could be run on various platforms without them randomly jumping out of the window, or us relying on plain Voodoo stuff to explain why those setup would work or not. The PowerPC port of Xenomai is already in good shape. That's great! Thanks. This is likely because I do feel better since I have been aware that there's life beyond x86. :o) Wolfgang. Latency tests with Xenomai on various PowerPC boards Board : Processor CPU-Clk Bus-Clk I-Cache D-Cache Memory Remarks TQM860L : MPC 860 50 MHz 50 MHz4 KB4 kB 16 MB TQM866M : MPC 866133 MHz 66 MHz 16 KB8 kB 128 MB Walnut : AMCC 405GP 200 MHz 100 MHz 16 KB8 kB 32 MB Yosemite: AMCC 440EP 533 MHz 133 MHz 32 KB 32 KB 256 MB DDR-RAM, FPU Ocotea : AMCC 440GX 533 MHz 152 MHz 32 KB 32 KB 256 MB DDR-RAM, L2 256 KB Linux : DENX linux-2.6.14-rc3-g4c234921 iPipe : 1.0-00 Xenomai: SVN 2005-10-15 CRUNCER without load: | Ideal computation time TQM860L | 368 us ??? TQM866L | 10008 us Walnut | 10150 us Yosemite | 9911 us Ocotea | 9479 us SWITCH without load: | lat min| lat avg| lat max|lost TQM860L | 103360| 107840| 209280| 0 TQM866L | 25745| 31880| 51369| 5 Walnut | 24620| 25965| 32280| 1 Yosemite |5626|5655| 17403| 0 Ocotea |5158|5169| 10038| 0 KLATENCY with load: |-lat min|-lat avg|-lat max|-overrun|---test-time TQM860L | 50560| 98976| 199040| 0|00:09:45 TQM866L | 13835| 28571| 74348| 0|00:11:44 Walnut | 16195| 25062| 45755| 0|00:10:09 Yosemite |3106|9697| 36832| 0|00:09:55 Ocotea |3575|7438| 24474| 0|00:10:50 LATENCY with load: |-lat min|-lat avg|-lat max|-overrun|---test-time TQM860L | 60480| 120960| 224320| 0|00:09:46 TQM866L | 15759| 34286| 78799| 0|00:11:14 Walnut | 21070| 31650| 64500| 0|00:09:58 Yosemite |3808| 12163| 47898| 0|00:10:00 Ocotea |3575|7438| 24474| 0|00:10:50 KLATENCY comparison Xenomai 2.0 vs. RTAI/RTHAL 3.0r5 on TQM860L: --- KLATENCY with
Re: [Xenomai-core] Xenomai latency tests on various PowerPC boards
On 10/18/2005 01:44 PM Philippe Gerum wrote: > Philippe Gerum wrote: >> Wolfgang Grandegger wrote: >> >>> Hallo, >>> >>> attached you will find the results of Xemonai latency measurements on >>> various embedded PowerPC boards using MPC 8xx and AMCC 4xx processors, >>> from low to high end covering a worst case latency range from 25 to 225 >>> us. It also includes a comparison with RTAI 3.0r5 on the slowest CPU. >>> Here are some remarks and comments: >>> >>> - On low-end processor code size matters a lot and it's difficult to >>> beat RTAI/RTHAL. >>> >> >> Beat no, get closer, yes, probably. The good news is that looking at the >> figures, we do have a margin of improvement! :o> >> >> Btw, the nucleus can be configured so that the user-space threading >> engine is compiled out (i.e. CONFIG_XENO_OPT_PERVASIVE from the nucleus >> menu), which would be the corresponding profile to compare with klatency >> (i.e. sched_up). Disabling this option reduces the code size for the >> nucleus from: >> >>text databssdechexfilename >> 66740792 6540 74072 12158 >> nucleus/xeno_nucleus.ko >> >> to: >> >> text databssdechexfilename >> 52596576 3956 57128 df28 >> nucleus/xeno_nucleus.ko >> > > Disabling the periodic timer support which is unused for the klatency test > brings this down to: > > text data bss dec hex filename >51040 5443956 55540d8f4 nucleus/xeno_nucleus.ko OK, here are the new figures with (*) CONFIG_XENO_OPT_PERVASIVE is not set CONFIG_XENO_HW_PERIODIC_TIMER is not set: |-lat min|-lat avg|-lat max|-overrun|---test-time RTAI 3.0r5 | 23120| 31838| 70520| ?|00:12:26 Xenomai| 50560| 98976| 199040| 0|00:09:45 Xenomai (*)| 44160| 96215| 200640| 0|00:09:53 The min latency decreases as expected. > >> Still a bit fat though. >> >>> - Apart from the CPU power, big caches and a fast memory interface >>> improves latencies. >>> >>> - L2 cache improves latencies a lot (compare Ocotea with Yosemite). >>> >>> - I'm a bit puzzled about the results of the "cruncher" test. Could >>> someone explain the output, please? >>> >> >> This test is reminiscent of the HYADES project (ia64 port of >> RTAI/fusion), where we wanted to illustrate the level of execution >> determinism one could achieve using the interrupt shield technique on >> large ia64 SMP systems. To this end, we measured the jitter in execution >> time of a calibrated float-crunching loop, with and without interrupt >> load. This test is likely going to disappear at some point in time, >> because it's not that informative in Xeno's context. >> >>> - Stability seems already quite good. At least I did not observe any >>> crash yet :-). >>> >> >> That's cool. I see no other way to properly improve performances than >> first having something which could be run on various platforms without >> them randomly jumping out of the window, or us relying on plain Voodoo >> stuff to explain why those setup would work or not. >> >>> The PowerPC port of Xenomai is already in good shape. That's great! >>> >> >> Thanks. This is likely because I do feel better since I have been aware >> that there's life beyond x86. :o) >> >>> Wolfgang. >>> >>> >>> >>> >>> >>> >>> >>> Latency tests with Xenomai on various PowerPC boards >>> >>> >>> Board : Processor CPU-Clk Bus-Clk I-Cache D-Cache Memory Remarks >>> >>> TQM860L : MPC 860 50 MHz 50 MHz4 KB4 kB 16 MB >>> TQM866M : MPC 866133 MHz 66 MHz 16 KB8 kB 128 MB >>> >>> Walnut : AMCC 405GP 200 MHz 100 MHz 16 KB8 kB 32 MB >>> Yosemite: AMCC 440EP 533 MHz 133 MHz 32 KB 32 KB 256 MB DDR-RAM, FPU >>> Ocotea : AMCC 440GX 533 MHz 152 MHz 32 KB 32 KB 256 MB DDR-RAM, >>> L2 256 KB >>> >>> >>> Linux : DENX linux-2.6.14-rc3-g4c234921 >>> iPipe : 1.0-00 >>> Xenomai: SVN 2005-10-15 >>> >>> >>> CRUNCER without load: >>> >>> | Ideal computation time >>> TQM860L | 368 us ??? >>> TQM866L | 10008 us Walnut | 10150 us >>> Yosemite | 9911 us >>> Ocotea | 9479 us >>> >>> SWITCH without load: >>> >>> | lat min| lat avg| lat max|lost >>> TQM860L | 103360| 107840| 209280| 0 >>> TQM866L | 25745| 31880| 51369| 5 >>> Walnut | 24620| 25965| 32280| 1 >>> Yosemite |5626|5655| 17403| 0 >>> Ocotea |5158|5169| 10038| 0 >>> >>> >>> KLATENCY with load: >>> >>> |-lat min|-lat avg|-lat max|-overrun|---test-time >>> TQM860L | 50560| 98976| 199040
Re: [Xenomai-core] Xenomai latency tests on various PowerPC boards
Wolfgang Grandegger wrote: On 10/18/2005 01:44 PM Philippe Gerum wrote: Philippe Gerum wrote: Wolfgang Grandegger wrote: Hallo, attached you will find the results of Xemonai latency measurements on various embedded PowerPC boards using MPC 8xx and AMCC 4xx processors, from low to high end covering a worst case latency range from 25 to 225 us. It also includes a comparison with RTAI 3.0r5 on the slowest CPU. Here are some remarks and comments: - On low-end processor code size matters a lot and it's difficult to beat RTAI/RTHAL. Beat no, get closer, yes, probably. The good news is that looking at the figures, we do have a margin of improvement! :o> Btw, the nucleus can be configured so that the user-space threading engine is compiled out (i.e. CONFIG_XENO_OPT_PERVASIVE from the nucleus menu), which would be the corresponding profile to compare with klatency (i.e. sched_up). Disabling this option reduces the code size for the nucleus from: text databssdechexfilename 66740792 6540 74072 12158 nucleus/xeno_nucleus.ko to: text databssdechexfilename 52596576 3956 57128 df28 nucleus/xeno_nucleus.ko Disabling the periodic timer support which is unused for the klatency test brings this down to: textdata bss dec hex filename 51040 5443956 55540d8f4 nucleus/xeno_nucleus.ko OK, here are the new figures with (*) CONFIG_XENO_OPT_PERVASIVE is not set CONFIG_XENO_HW_PERIODIC_TIMER is not set: |-lat min|-lat avg|-lat max|-overrun|---test-time RTAI 3.0r5 | 23120| 31838| 70520| ?|00:12:26 Xenomai| 50560| 98976| 199040| 0|00:09:45 Xenomai (*)| 44160| 96215| 200640| 0|00:09:53 The min latency decreases as expected. Looks like significant. I wonder now what's the impact of having 2.6 trashing the caches during the sleep periods compared to 2.4. But to have an answer here, we will need Xeno running over 2.4. Ok, it's planned. Still a bit fat though. - Apart from the CPU power, big caches and a fast memory interface improves latencies. - L2 cache improves latencies a lot (compare Ocotea with Yosemite). - I'm a bit puzzled about the results of the "cruncher" test. Could someone explain the output, please? This test is reminiscent of the HYADES project (ia64 port of RTAI/fusion), where we wanted to illustrate the level of execution determinism one could achieve using the interrupt shield technique on large ia64 SMP systems. To this end, we measured the jitter in execution time of a calibrated float-crunching loop, with and without interrupt load. This test is likely going to disappear at some point in time, because it's not that informative in Xeno's context. - Stability seems already quite good. At least I did not observe any crash yet :-). That's cool. I see no other way to properly improve performances than first having something which could be run on various platforms without them randomly jumping out of the window, or us relying on plain Voodoo stuff to explain why those setup would work or not. The PowerPC port of Xenomai is already in good shape. That's great! Thanks. This is likely because I do feel better since I have been aware that there's life beyond x86. :o) Wolfgang. Latency tests with Xenomai on various PowerPC boards Board : Processor CPU-Clk Bus-Clk I-Cache D-Cache Memory Remarks TQM860L : MPC 860 50 MHz 50 MHz4 KB4 kB 16 MB TQM866M : MPC 866133 MHz 66 MHz 16 KB8 kB 128 MB Walnut : AMCC 405GP 200 MHz 100 MHz 16 KB8 kB 32 MB Yosemite: AMCC 440EP 533 MHz 133 MHz 32 KB 32 KB 256 MB DDR-RAM, FPU Ocotea : AMCC 440GX 533 MHz 152 MHz 32 KB 32 KB 256 MB DDR-RAM, L2 256 KB Linux : DENX linux-2.6.14-rc3-g4c234921 iPipe : 1.0-00 Xenomai: SVN 2005-10-15 CRUNCER without load: | Ideal computation time TQM860L | 368 us ??? TQM866L | 10008 us Walnut | 10150 us Yosemite | 9911 us Ocotea | 9479 us SWITCH without load: | lat min| lat avg| lat max|lost TQM860L | 103360| 107840| 209280| 0 TQM866L | 25745| 31880| 51369| 5 Walnut | 24620| 25965| 32280| 1 Yosemite |5626|5655| 17403| 0 Ocotea |5158|5169| 10038| 0 KLATENCY with load: |-lat min|-lat avg|-lat max|-overrun|---test-time TQM860L | 50560| 98976| 199040| 0|00:09:45 TQM866L | 13835| 28571| 74348| 0|00:11:44 Walnut | 16195| 25062| 45755| 0|
[Xenomai-core] Xenomai and gdbserver
Hi I wonder if someone has been able to perform a remote debug with xenomai/fusion. I have problems debugging fusion-0.9.1 programs with kernel-2.6.12.2 and Fedora Core 2 gdb-6.0 When i run GDB chain and step into rt_task_create(...), GDB prompts "[1]+ Stopped gdb chain" and terminates. I can call "gdbserver ipnum:port chain". then connect to it from a remote machine using gdb and "target remote..." ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Xenomai and gdbserver
I use remote debug with fusion/2.6.13, but I am using fusion from svn. Also, there are bugs. One I have found recently is that if a task is created with T_SUSP and then you start stepping through the code, the task seems to start up on its own somehow. Weird. Older verisons of fusion had issues with not every task in the application halting on breakpoint. On 10/18/05 8:10 AM, "Marco Cavallini" <[EMAIL PROTECTED]> wrote: > Hi > I wonder if someone has been able to perform a remote debug with > xenomai/fusion. > I have problems debugging fusion-0.9.1 programs with kernel-2.6.12.2 and > Fedora Core 2 > gdb-6.0 > > When i run GDB chain and step into rt_task_create(...), GDB prompts "[1]+ > Stopped gdb chain" and > terminates. I can > call "gdbserver ipnum:port chain". then connect to it from a remote machine > using gdb and "target remote..." > > > ___ > Xenomai-core mailing list > Xenomai-core@gna.org > https://mail.gna.org/listinfo/xenomai-core ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Xenomai and gdbserver
Steven Seeger wrote: I use remote debug with fusion/2.6.13, but I am using fusion from svn. Also, there are bugs. One I have found recently is that if a task is created with T_SUSP and then you start stepping through the code, the task seems to start up on its own somehow. Weird. Last time you reported that you actually mentioned the rt_task_spawn() service, which is designed to start the task immediately. Reading about the T_SUSP bit now seems to mean that you are not using rt_task_spawn() anymore, but that the problem indeed appears. Could you be more specific about the code in question? Older verisons of fusion had issues with not every task in the application halting on breakpoint. Strange indeed, since there is no reason for the exception triggered by any breakpoint to behave in a context-dependent manner, I mean on a task-by-task basis. Do you remember the first version that seemed to solve the issue? On 10/18/05 8:10 AM, "Marco Cavallini" <[EMAIL PROTECTED]> wrote: Hi I wonder if someone has been able to perform a remote debug with xenomai/fusion. I have problems debugging fusion-0.9.1 programs with kernel-2.6.12.2 and Fedora Core 2 gdb-6.0 When i run GDB chain and step into rt_task_create(...), GDB prompts "[1]+ Stopped gdb chain" and terminates. I can call "gdbserver ipnum:port chain". then connect to it from a remote machine using gdb and "target remote..." ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core -- Philippe. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Xenomai and gdbserver
Marco Cavallini wrote: Hi I wonder if someone has been able to perform a remote debug with xenomai/fusion. I have problems debugging fusion-0.9.1 programs with kernel-2.6.12.2 and Fedora Core 2 gdb-6.0 When i run GDB chain and step into rt_task_create(...), GDB prompts "[1]+ Stopped gdb chain" and terminates. I can I'm tracking an issue like that, causing the debuggee to run into a SIGBUS, due to the program counter being messed up somehow. AFAICT, this sometimes happens when stepping over code that migrates between primary and secondary modes (and rt_task_create does). I need to log this one on the bug tracker. It's pretty PITA to chase, but it's 100% reproductible here, so there's hope. call "gdbserver ipnum:port chain". then connect to it from a remote machine using gdb and "target remote..." ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core -- Philippe. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Cosmetic changes to script xeno-config + man page
Romain Lenglet wrote: > > In order to compare Xenomai with other Debian packagees, I > > checked gtk-config, and I have a few remarks on xeno-config > > and its manpage. > [...] > > I merely documented xeno-config as it is now, and made the > printed usage consistent. If you modify it, I will update the > manpage accordingly. Sorry for the digression then. But the point about DESTDIR still holds, from my point of view. > > > Another item to add to the looOOong-term wishlist: I would like > to have ready-to-use autoconf rules, to use instead of > xeno-config. > > If someone ever writes such rules, e.g. in a "xenomai.m4" file, > it would only be necessary, at Xenomai install time: > 1- to copy xenomai.m4 into /usr/share/autoconf/autoconf/ > 2- to add the following line into autoconf.m4: > m4_include([autoconf/xenomai.m4]) > 2- to regenerate autoconf.m4f by running: > cd /usr/share/autoconf/autoconf > autom4te --language=autoconf --freeze --output=autoconf.m4f > > A simpler solution would be to ship a xenomai.m4 to be used as a > acinclude.m4 in every project using Xenomai. But I have had very > bad experiences with aclocal in that use case. aclocal is quite > buggy. And it would be more confortable for projects it is were > immediately available after installing Xenomai. Yes, this was the original plan, but there are still many things on our todo list before that. > > > > Now, about the manpage itself, unless I am wrong, the DESTDIR > > feature is not documented, it is very useful when compiling > > for a target. > > DESTDIR is a feature of makefiles generated through Automake, not > of xeno-config. Why would you like to document this is in > xeno-config's manpage? DESTDIR is used by xeno-config the same way it is used by Makefiles. When you compiled Xenomai for a target and installed it with DESTDIR=/home/romain/target, you have to set DESTDIR in xeno-config environment so that it outputs -I/home/romain/target/usr/realtime/include and -L/home/romain/target/usr/realtimeLib. Since it is a rather obscure functionality, it probably deserves an explanation. -- Gilles Chanteperdrix. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Xenomai latency tests on various PowerPC boards
Wolfgang Grandegger wrote: On 10/18/2005 01:44 PM Philippe Gerum wrote: Philippe Gerum wrote: Wolfgang Grandegger wrote: Hallo, attached you will find the results of Xemonai latency measurements on various embedded PowerPC boards using MPC 8xx and AMCC 4xx processors, from low to high end covering a worst case latency range from 25 to 225 us. It also includes a comparison with RTAI 3.0r5 on the slowest CPU. Here are some remarks and comments: - On low-end processor code size matters a lot and it's difficult to beat RTAI/RTHAL. Beat no, get closer, yes, probably. The good news is that looking at the figures, we do have a margin of improvement! :o> Btw, the nucleus can be configured so that the user-space threading engine is compiled out (i.e. CONFIG_XENO_OPT_PERVASIVE from the nucleus menu), which would be the corresponding profile to compare with klatency (i.e. sched_up). Disabling this option reduces the code size for the nucleus from: text databssdechexfilename 66740792 6540 74072 12158 nucleus/xeno_nucleus.ko to: text databssdechexfilename 52596576 3956 57128 df28 nucleus/xeno_nucleus.ko Disabling the periodic timer support which is unused for the klatency test brings this down to: textdata bss dec hex filename 51040 5443956 55540d8f4 nucleus/xeno_nucleus.ko OK, here are the new figures with (*) CONFIG_XENO_OPT_PERVASIVE is not set CONFIG_XENO_HW_PERIODIC_TIMER is not set: |-lat min|-lat avg|-lat max|-overrun|---test-time RTAI 3.0r5 | 23120| 31838| 70520| ?|00:12:26 Xenomai| 50560| 98976| 199040| 0|00:09:45 Xenomai (*)| 44160| 96215| 200640| 0|00:09:53 The min latency decreases as expected. I just discovered that -00 did not include some recent changes I had in my tree, aimed at prevent high latencies during fork pressure. I've committed -01 which does include them. When time allows, I'd be interested to know if this has some impact on the Ocotea figures. TIA, -- Philippe. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Cosmetic changes to script xeno-config + man page
> > A simpler solution would be to ship a xenomai.m4 to be used > > as a acinclude.m4 in every project using Xenomai. But I > > have had very bad experiences with aclocal in that use > > case. aclocal is quite buggy. And it would be more > > confortable for projects it is were immediately available > > after installing Xenomai. > > Yes, this was the original plan, but there are still many > things on our todo list before that. I found a better solution, that could be a replacement for both a xenomai.m4 trick, and the xeno-config script: pkg-config. http://pkgconfig.freedesktop.org/wiki/ There are packages for pkgconfig in both Debian and RedHat, AFAIK, and surely for all other distribs. I will look into making a xenomai.pc file. > DESTDIR is used by xeno-config the same way it is used by > Makefiles. When you compiled Xenomai for a target and > installed it with DESTDIR=/home/romain/target, you have to set > DESTDIR in xeno-config environment so that it outputs > -I/home/romain/target/usr/realtime/include and > -L/home/romain/target/usr/realtimeLib. > > Since it is a rather obscure functionality, it probably > deserves an explanation. Ok, done. Please apply patches #472 and #474: https://gna.org/patch/index.php?func=detailitem&item_id=472 https://gna.org/patch/index.php?func=detailitem&item_id=474 -- Romain Lenglet ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Cosmetic changes to script xeno-config + man page
Romain Lenglet wrote: > > if you see an error, please provide a proper patch. > > Here is a patch that includes the correction of xeno-config.in > and the manpage. If someone wants to add it to the patch tracker > on the Gna! project page, please do it. You are supposed to be able to ad that patch to the tracker: being a logged-in user should be enough to be able to post a patch. I do not think it wise to open it to anonymous users, it would open it for use by spammers. > I am currently working on manpages for xeno-load(1) and > runinfo(5) (for the format of .runinfo files). I will send a > patch with these. Thanks. Note that you will need to document the latency test. This looks important, because this is the first program users should run, before messing with .runinfo. In order to compare Xenomai with other Debian packagees, I checked gtk-config, and I have a few remarks on xeno-config and its manpage. gtk-config is made to be sourced from configure scripts, so that configure scripts have a simple way to know whether GTK is installed, and a simple way to get the glib_* variables and export them to the generated makefiles. When run with no arguments, xeno-config prints the usage, but most importantly returns an error. I would suggest firstly that we do not print anything, after all the standard way to get help is the --help or -h argument, but if you do insist that you want help, I admit configure script may redirect output when sourcing xeno-config. But I strongly suggest we return 0, otherwise, there is no simple way for a configure script to know whether Xenomai is correctly installed. gtk-config has no --verbose option and I wonder how useful this option is. I mean, if you want to have the variables list, you may run (modulo we do not return 1 as status when called with no arguments) . xeno-config set | grep '^XENO' Now, about the manpage itself, unless I am wrong, the DESTDIR feature is not documented, it is very useful when compiling for a target. -- Gilles Chanteperdrix.
Re: [Xenomai-core] Cosmetic changes to script xeno-config + man page
> In order to compare Xenomai with other Debian packagees, I > checked gtk-config, and I have a few remarks on xeno-config > and its manpage. [...] I merely documented xeno-config as it is now, and made the printed usage consistent. If you modify it, I will update the manpage accordingly. Another item to add to the looOOong-term wishlist: I would like to have ready-to-use autoconf rules, to use instead of xeno-config. If someone ever writes such rules, e.g. in a "xenomai.m4" file, it would only be necessary, at Xenomai install time: 1- to copy xenomai.m4 into /usr/share/autoconf/autoconf/ 2- to add the following line into autoconf.m4: m4_include([autoconf/xenomai.m4]) 2- to regenerate autoconf.m4f by running: cd /usr/share/autoconf/autoconf autom4te --language=autoconf --freeze --output=autoconf.m4f A simpler solution would be to ship a xenomai.m4 to be used as a acinclude.m4 in every project using Xenomai. But I have had very bad experiences with aclocal in that use case. aclocal is quite buggy. And it would be more confortable for projects it is were immediately available after installing Xenomai. > Now, about the manpage itself, unless I am wrong, the DESTDIR > feature is not documented, it is very useful when compiling > for a target. DESTDIR is a feature of makefiles generated through Automake, not of xeno-config. Why would you like to document this is in xeno-config's manpage? -- Romain Lenglet
[Xenomai-core] Xenomai latency tests on various PowerPC boards
Hallo, attached you will find the results of Xemonai latency measurements on various embedded PowerPC boards using MPC 8xx and AMCC 4xx processors, from low to high end covering a worst case latency range from 25 to 225 us. It also includes a comparison with RTAI 3.0r5 on the slowest CPU. Here are some remarks and comments: - On low-end processor code size matters a lot and it's difficult to beat RTAI/RTHAL. - Apart from the CPU power, big caches and a fast memory interface improves latencies. - L2 cache improves latencies a lot (compare Ocotea with Yosemite). - I'm a bit puzzled about the results of the "cruncher" test. Could someone explain the output, please? - Stability seems already quite good. At least I did not observe any crash yet :-). The PowerPC port of Xenomai is already in good shape. That's great! Wolfgang. Latency tests with Xenomai on various PowerPC boards Board : Processor CPU-Clk Bus-Clk I-Cache D-Cache Memory Remarks TQM860L : MPC 860 50 MHz 50 MHz4 KB4 kB 16 MB TQM866M : MPC 866133 MHz 66 MHz 16 KB8 kB 128 MB Walnut : AMCC 405GP 200 MHz 100 MHz 16 KB8 kB 32 MB Yosemite: AMCC 440EP 533 MHz 133 MHz 32 KB 32 KB 256 MB DDR-RAM, FPU Ocotea : AMCC 440GX 533 MHz 152 MHz 32 KB 32 KB 256 MB DDR-RAM, L2 256 KB Linux : DENX linux-2.6.14-rc3-g4c234921 iPipe : 1.0-00 Xenomai: SVN 2005-10-15 CRUNCER without load: | Ideal computation time TQM860L | 368 us ??? TQM866L | 10008 us Walnut | 10150 us Yosemite | 9911 us Ocotea | 9479 us SWITCH without load: | lat min| lat avg| lat max|lost TQM860L | 103360| 107840| 209280| 0 TQM866L | 25745| 31880| 51369| 5 Walnut | 24620| 25965| 32280| 1 Yosemite |5626|5655| 17403| 0 Ocotea |5158|5169| 10038| 0 KLATENCY with load: |-lat min|-lat avg|-lat max|-overrun|---test-time TQM860L | 50560| 98976| 199040| 0|00:09:45 TQM866L | 13835| 28571| 74348| 0|00:11:44 Walnut | 16195| 25062| 45755| 0|00:10:09 Yosemite |3106|9697| 36832| 0|00:09:55 Ocotea |3575|7438| 24474| 0|00:10:50 LATENCY with load: |-lat min|-lat avg|-lat max|-overrun|---test-time TQM860L | 60480| 120960| 224320| 0|00:09:46 TQM866L | 15759| 34286| 78799| 0|00:11:14 Walnut | 21070| 31650| 64500| 0|00:09:58 Yosemite |3808| 12163| 47898| 0|00:10:00 Ocotea |3575|7438| 24474| 0|00:10:50 KLATENCY comparison Xenomai 2.0 vs. RTAI/RTHAL 3.0r5 on TQM860L: --- KLATENCY with load: |-lat min|-lat avg|-lat max|-overrun|---test-time Xenomai 2.0 | 50560| 98976| 199040| 0|00:09:45 RTAI 3.0r5 | 23120| 31838| 70520| ?|00:12:26 Note: load has been put onto the system by running in a telnet session "ping -f " and "while ls; do ls; done". Note: all test have been run with CONFIG_XENO_HW_TIMER_LATENCY="1" and CONFIG_XENO_HW_SCHED_LATENCY="1" to get correct latancy values. RTAI figures have been corrected manually. xenomai-latencies-ppc.tgz Description: GNU Zip compressed data
Re: [Xenomai-core] Testing the adeos-ipipe-2.6.13-ppc-1.0-00.patch
On 10/17/2005 05:42 PM Fillod Stephane wrote: > Hi Philippe, > > Sorry for the late report, Xenomai appears to work fine on a Freescale > e500 > board (MPC8541E) under Linux 2.6.13. Xenomai version was v1.9.9, ie. the > daily > snapshot as of today. Here are some preliminary figures (CPU 800MHz, Bus > 133MHz, > 32 kiB I-Cache 32 kiB D-Cache, 256 kiB L2): > > switch $ ./run > == Sampling period: 100 us > RTH| lat min| lat avg| lat max|lost > RTD|3660|3690|8070| 0 > > kaltency $ ./run > RTH|klat min|klat avg|klat max| overrun| > RTS| -7350| -5715|6420| 0| > 00:03:17/00:03:17 > > latency $ ./run > == Sampling period: 100 us > RTT| 00:08:04 > RTH|-lat min|-lat avg|-lat max|-overrun| > RTS| -6930| -4260|8700| 0| > 00:08:06/00:08:06 > > Load for klatency/latency was ping flooding on FCC (piece of cake), > and cache calibrator. IMHO, we can do nastier. Comparing the corrected latency figures (+9500ns) of your MPC8541E with my Ocotea-Board (AMCC 440 GX at 533 MHz) gives: Ocotea |3575|7438| 24474| 0|00:10:50 MPC8541E |2570|5240| 18200| 0| This scales rather well with the CPU clocks 533/800. L1 and L2 caches and the memory interface seem almost identical. Wolfgang.
Re: [Xenomai-core] [bug-reminder] user/kernel space header deps
Philippe Gerum wrote: > Gilles Chanteperdrix wrote: > >> Jan Kiszka wrote: >> > Hi, >> > > just to avoid that this issue got lost during the migration to >> Xenomai: >> >> Before it get lost again, maybe you would like to use our brand-new bug >> tracker ? >> >> https://gna.org/bugs/?func=additem&group=xenomai >> https://gna.org/bugs/index.php?func=detailitem&item_id=4545 > > Please add the kernel module compilation flags issue you once raised > too. This one will be solved when the build system is fully refactored > though. > https://gna.org/bugs/index.php?func=detailitem&item_id=4546 (nice to know that this one also causes some of my x86_64 issues) Jan signature.asc Description: OpenPGP digital signature
Re: [Xenomai-core] Xenomai latency tests on various PowerPC boards
Wolfgang Grandegger wrote: Hallo, attached you will find the results of Xemonai latency measurements on various embedded PowerPC boards using MPC 8xx and AMCC 4xx processors, from low to high end covering a worst case latency range from 25 to 225 us. It also includes a comparison with RTAI 3.0r5 on the slowest CPU. Here are some remarks and comments: - On low-end processor code size matters a lot and it's difficult to beat RTAI/RTHAL. Beat no, get closer, yes, probably. The good news is that looking at the figures, we do have a margin of improvement! :o> Btw, the nucleus can be configured so that the user-space threading engine is compiled out (i.e. CONFIG_XENO_OPT_PERVASIVE from the nucleus menu), which would be the corresponding profile to compare with klatency (i.e. sched_up). Disabling this option reduces the code size for the nucleus from: textdata bss dec hex filename 66740 7926540 74072 12158 nucleus/xeno_nucleus.ko to: text data bss dec hex filename 52596 5763956 57128df28 nucleus/xeno_nucleus.ko Still a bit fat though. - Apart from the CPU power, big caches and a fast memory interface improves latencies. - L2 cache improves latencies a lot (compare Ocotea with Yosemite). - I'm a bit puzzled about the results of the "cruncher" test. Could someone explain the output, please? This test is reminiscent of the HYADES project (ia64 port of RTAI/fusion), where we wanted to illustrate the level of execution determinism one could achieve using the interrupt shield technique on large ia64 SMP systems. To this end, we measured the jitter in execution time of a calibrated float-crunching loop, with and without interrupt load. This test is likely going to disappear at some point in time, because it's not that informative in Xeno's context. - Stability seems already quite good. At least I did not observe any crash yet :-). That's cool. I see no other way to properly improve performances than first having something which could be run on various platforms without them randomly jumping out of the window, or us relying on plain Voodoo stuff to explain why those setup would work or not. The PowerPC port of Xenomai is already in good shape. That's great! Thanks. This is likely because I do feel better since I have been aware that there's life beyond x86. :o) Wolfgang. Latency tests with Xenomai on various PowerPC boards Board : Processor CPU-Clk Bus-Clk I-Cache D-Cache Memory Remarks TQM860L : MPC 860 50 MHz 50 MHz4 KB4 kB 16 MB TQM866M : MPC 866133 MHz 66 MHz 16 KB8 kB 128 MB Walnut : AMCC 405GP 200 MHz 100 MHz 16 KB8 kB 32 MB Yosemite: AMCC 440EP 533 MHz 133 MHz 32 KB 32 KB 256 MB DDR-RAM, FPU Ocotea : AMCC 440GX 533 MHz 152 MHz 32 KB 32 KB 256 MB DDR-RAM, L2 256 KB Linux : DENX linux-2.6.14-rc3-g4c234921 iPipe : 1.0-00 Xenomai: SVN 2005-10-15 CRUNCER without load: | Ideal computation time TQM860L | 368 us ??? TQM866L | 10008 us Walnut | 10150 us Yosemite | 9911 us Ocotea | 9479 us SWITCH without load: | lat min| lat avg| lat max|lost TQM860L | 103360| 107840| 209280| 0 TQM866L | 25745| 31880| 51369| 5 Walnut | 24620| 25965| 32280| 1 Yosemite |5626|5655| 17403| 0 Ocotea |5158|5169| 10038| 0 KLATENCY with load: |-lat min|-lat avg|-lat max|-overrun|---test-time TQM860L | 50560| 98976| 199040| 0|00:09:45 TQM866L | 13835| 28571| 74348| 0|00:11:44 Walnut | 16195| 25062| 45755| 0|00:10:09 Yosemite |3106|9697| 36832| 0|00:09:55 Ocotea |3575|7438| 24474| 0|00:10:50 LATENCY with load: |-lat min|-lat avg|-lat max|-overrun|---test-time TQM860L | 60480| 120960| 224320| 0|00:09:46 TQM866L | 15759| 34286| 78799| 0|00:11:14 Walnut | 21070| 31650| 64500| 0|00:09:58 Yosemite |3808| 12163| 47898| 0|00:10:00 Ocotea |3575|7438| 24474| 0|00:10:50 KLATENCY comparison Xenomai 2.0 vs. RTAI/RTHAL 3.0r5 on TQM860L: --- KLATENCY with load: |-lat min|-lat avg|-lat max|-overrun|---test-time Xenomai 2.0 | 50560| 98976| 199040| 0|00:09:45 RTAI 3.0r5 | 23120| 31838| 70520| ?|00:12:26 Note: load has been put onto the system by running in a telnet sessio
Re: [Xenomai-core] Xenomai latency tests on various PowerPC boards
Philippe Gerum wrote: Wolfgang Grandegger wrote: Hallo, attached you will find the results of Xemonai latency measurements on various embedded PowerPC boards using MPC 8xx and AMCC 4xx processors, from low to high end covering a worst case latency range from 25 to 225 us. It also includes a comparison with RTAI 3.0r5 on the slowest CPU. Here are some remarks and comments: - On low-end processor code size matters a lot and it's difficult to beat RTAI/RTHAL. Beat no, get closer, yes, probably. The good news is that looking at the figures, we do have a margin of improvement! :o> Btw, the nucleus can be configured so that the user-space threading engine is compiled out (i.e. CONFIG_XENO_OPT_PERVASIVE from the nucleus menu), which would be the corresponding profile to compare with klatency (i.e. sched_up). Disabling this option reduces the code size for the nucleus from: text databssdechexfilename 66740792 6540 74072 12158 nucleus/xeno_nucleus.ko to: text databssdechexfilename 52596576 3956 57128 df28 nucleus/xeno_nucleus.ko Disabling the periodic timer support which is unused for the klatency test brings this down to: textdata bss dec hex filename 51040 5443956 55540d8f4 nucleus/xeno_nucleus.ko Still a bit fat though. - Apart from the CPU power, big caches and a fast memory interface improves latencies. - L2 cache improves latencies a lot (compare Ocotea with Yosemite). - I'm a bit puzzled about the results of the "cruncher" test. Could someone explain the output, please? This test is reminiscent of the HYADES project (ia64 port of RTAI/fusion), where we wanted to illustrate the level of execution determinism one could achieve using the interrupt shield technique on large ia64 SMP systems. To this end, we measured the jitter in execution time of a calibrated float-crunching loop, with and without interrupt load. This test is likely going to disappear at some point in time, because it's not that informative in Xeno's context. - Stability seems already quite good. At least I did not observe any crash yet :-). That's cool. I see no other way to properly improve performances than first having something which could be run on various platforms without them randomly jumping out of the window, or us relying on plain Voodoo stuff to explain why those setup would work or not. The PowerPC port of Xenomai is already in good shape. That's great! Thanks. This is likely because I do feel better since I have been aware that there's life beyond x86. :o) Wolfgang. Latency tests with Xenomai on various PowerPC boards Board : Processor CPU-Clk Bus-Clk I-Cache D-Cache Memory Remarks TQM860L : MPC 860 50 MHz 50 MHz4 KB4 kB 16 MB TQM866M : MPC 866133 MHz 66 MHz 16 KB8 kB 128 MB Walnut : AMCC 405GP 200 MHz 100 MHz 16 KB8 kB 32 MB Yosemite: AMCC 440EP 533 MHz 133 MHz 32 KB 32 KB 256 MB DDR-RAM, FPU Ocotea : AMCC 440GX 533 MHz 152 MHz 32 KB 32 KB 256 MB DDR-RAM, L2 256 KB Linux : DENX linux-2.6.14-rc3-g4c234921 iPipe : 1.0-00 Xenomai: SVN 2005-10-15 CRUNCER without load: | Ideal computation time TQM860L | 368 us ??? TQM866L | 10008 us Walnut | 10150 us Yosemite | 9911 us Ocotea | 9479 us SWITCH without load: | lat min| lat avg| lat max|lost TQM860L | 103360| 107840| 209280| 0 TQM866L | 25745| 31880| 51369| 5 Walnut | 24620| 25965| 32280| 1 Yosemite |5626|5655| 17403| 0 Ocotea |5158|5169| 10038| 0 KLATENCY with load: |-lat min|-lat avg|-lat max|-overrun|---test-time TQM860L | 50560| 98976| 199040| 0|00:09:45 TQM866L | 13835| 28571| 74348| 0|00:11:44 Walnut | 16195| 25062| 45755| 0|00:10:09 Yosemite |3106|9697| 36832| 0|00:09:55 Ocotea |3575|7438| 24474| 0|00:10:50 LATENCY with load: |-lat min|-lat avg|-lat max|-overrun|---test-time TQM860L | 60480| 120960| 224320| 0|00:09:46 TQM866L | 15759| 34286| 78799| 0|00:11:14 Walnut | 21070| 31650| 64500| 0|00:09:58 Yosemite |3808| 12163| 47898| 0|00:10:00 Ocotea |3575|7438| 24474| 0|00:10:50 KLATENCY comparison Xenomai 2.0 vs. RTAI/RTHAL 3.0r5 on TQM860L: --- KLATENCY with
Re: [Xenomai-core] Xenomai latency tests on various PowerPC boards
On 10/18/2005 01:44 PM Philippe Gerum wrote: > Philippe Gerum wrote: >> Wolfgang Grandegger wrote: >> >>> Hallo, >>> >>> attached you will find the results of Xemonai latency measurements on >>> various embedded PowerPC boards using MPC 8xx and AMCC 4xx processors, >>> from low to high end covering a worst case latency range from 25 to 225 >>> us. It also includes a comparison with RTAI 3.0r5 on the slowest CPU. >>> Here are some remarks and comments: >>> >>> - On low-end processor code size matters a lot and it's difficult to >>> beat RTAI/RTHAL. >>> >> >> Beat no, get closer, yes, probably. The good news is that looking at the >> figures, we do have a margin of improvement! :o> >> >> Btw, the nucleus can be configured so that the user-space threading >> engine is compiled out (i.e. CONFIG_XENO_OPT_PERVASIVE from the nucleus >> menu), which would be the corresponding profile to compare with klatency >> (i.e. sched_up). Disabling this option reduces the code size for the >> nucleus from: >> >>text databssdechexfilename >> 66740792 6540 74072 12158 >> nucleus/xeno_nucleus.ko >> >> to: >> >> text databssdechexfilename >> 52596576 3956 57128 df28 >> nucleus/xeno_nucleus.ko >> > > Disabling the periodic timer support which is unused for the klatency test > brings this down to: > > text data bss dec hex filename >51040 5443956 55540d8f4 nucleus/xeno_nucleus.ko OK, here are the new figures with (*) CONFIG_XENO_OPT_PERVASIVE is not set CONFIG_XENO_HW_PERIODIC_TIMER is not set: |-lat min|-lat avg|-lat max|-overrun|---test-time RTAI 3.0r5 | 23120| 31838| 70520| ?|00:12:26 Xenomai| 50560| 98976| 199040| 0|00:09:45 Xenomai (*)| 44160| 96215| 200640| 0|00:09:53 The min latency decreases as expected. > >> Still a bit fat though. >> >>> - Apart from the CPU power, big caches and a fast memory interface >>> improves latencies. >>> >>> - L2 cache improves latencies a lot (compare Ocotea with Yosemite). >>> >>> - I'm a bit puzzled about the results of the "cruncher" test. Could >>> someone explain the output, please? >>> >> >> This test is reminiscent of the HYADES project (ia64 port of >> RTAI/fusion), where we wanted to illustrate the level of execution >> determinism one could achieve using the interrupt shield technique on >> large ia64 SMP systems. To this end, we measured the jitter in execution >> time of a calibrated float-crunching loop, with and without interrupt >> load. This test is likely going to disappear at some point in time, >> because it's not that informative in Xeno's context. >> >>> - Stability seems already quite good. At least I did not observe any >>> crash yet :-). >>> >> >> That's cool. I see no other way to properly improve performances than >> first having something which could be run on various platforms without >> them randomly jumping out of the window, or us relying on plain Voodoo >> stuff to explain why those setup would work or not. >> >>> The PowerPC port of Xenomai is already in good shape. That's great! >>> >> >> Thanks. This is likely because I do feel better since I have been aware >> that there's life beyond x86. :o) >> >>> Wolfgang. >>> >>> >>> >>> >>> >>> >>> >>> Latency tests with Xenomai on various PowerPC boards >>> >>> >>> Board : Processor CPU-Clk Bus-Clk I-Cache D-Cache Memory Remarks >>> >>> TQM860L : MPC 860 50 MHz 50 MHz4 KB4 kB 16 MB >>> TQM866M : MPC 866133 MHz 66 MHz 16 KB8 kB 128 MB >>> >>> Walnut : AMCC 405GP 200 MHz 100 MHz 16 KB8 kB 32 MB >>> Yosemite: AMCC 440EP 533 MHz 133 MHz 32 KB 32 KB 256 MB DDR-RAM, FPU >>> Ocotea : AMCC 440GX 533 MHz 152 MHz 32 KB 32 KB 256 MB DDR-RAM, >>> L2 256 KB >>> >>> >>> Linux : DENX linux-2.6.14-rc3-g4c234921 >>> iPipe : 1.0-00 >>> Xenomai: SVN 2005-10-15 >>> >>> >>> CRUNCER without load: >>> >>> | Ideal computation time >>> TQM860L | 368 us ??? >>> TQM866L | 10008 us Walnut | 10150 us >>> Yosemite | 9911 us >>> Ocotea | 9479 us >>> >>> SWITCH without load: >>> >>> | lat min| lat avg| lat max|lost >>> TQM860L | 103360| 107840| 209280| 0 >>> TQM866L | 25745| 31880| 51369| 5 >>> Walnut | 24620| 25965| 32280| 1 >>> Yosemite |5626|5655| 17403| 0 >>> Ocotea |5158|5169| 10038| 0 >>> >>> >>> KLATENCY with load: >>> >>> |-lat min|-lat avg|-lat max|-overrun|---test-time >>> TQM860L | 50560| 98976| 199040
Re: [Xenomai-core] Xenomai latency tests on various PowerPC boards
Wolfgang Grandegger wrote: On 10/18/2005 01:44 PM Philippe Gerum wrote: Philippe Gerum wrote: Wolfgang Grandegger wrote: Hallo, attached you will find the results of Xemonai latency measurements on various embedded PowerPC boards using MPC 8xx and AMCC 4xx processors, from low to high end covering a worst case latency range from 25 to 225 us. It also includes a comparison with RTAI 3.0r5 on the slowest CPU. Here are some remarks and comments: - On low-end processor code size matters a lot and it's difficult to beat RTAI/RTHAL. Beat no, get closer, yes, probably. The good news is that looking at the figures, we do have a margin of improvement! :o> Btw, the nucleus can be configured so that the user-space threading engine is compiled out (i.e. CONFIG_XENO_OPT_PERVASIVE from the nucleus menu), which would be the corresponding profile to compare with klatency (i.e. sched_up). Disabling this option reduces the code size for the nucleus from: text databssdechexfilename 66740792 6540 74072 12158 nucleus/xeno_nucleus.ko to: text databssdechexfilename 52596576 3956 57128 df28 nucleus/xeno_nucleus.ko Disabling the periodic timer support which is unused for the klatency test brings this down to: textdata bss dec hex filename 51040 5443956 55540d8f4 nucleus/xeno_nucleus.ko OK, here are the new figures with (*) CONFIG_XENO_OPT_PERVASIVE is not set CONFIG_XENO_HW_PERIODIC_TIMER is not set: |-lat min|-lat avg|-lat max|-overrun|---test-time RTAI 3.0r5 | 23120| 31838| 70520| ?|00:12:26 Xenomai| 50560| 98976| 199040| 0|00:09:45 Xenomai (*)| 44160| 96215| 200640| 0|00:09:53 The min latency decreases as expected. Looks like significant. I wonder now what's the impact of having 2.6 trashing the caches during the sleep periods compared to 2.4. But to have an answer here, we will need Xeno running over 2.4. Ok, it's planned. Still a bit fat though. - Apart from the CPU power, big caches and a fast memory interface improves latencies. - L2 cache improves latencies a lot (compare Ocotea with Yosemite). - I'm a bit puzzled about the results of the "cruncher" test. Could someone explain the output, please? This test is reminiscent of the HYADES project (ia64 port of RTAI/fusion), where we wanted to illustrate the level of execution determinism one could achieve using the interrupt shield technique on large ia64 SMP systems. To this end, we measured the jitter in execution time of a calibrated float-crunching loop, with and without interrupt load. This test is likely going to disappear at some point in time, because it's not that informative in Xeno's context. - Stability seems already quite good. At least I did not observe any crash yet :-). That's cool. I see no other way to properly improve performances than first having something which could be run on various platforms without them randomly jumping out of the window, or us relying on plain Voodoo stuff to explain why those setup would work or not. The PowerPC port of Xenomai is already in good shape. That's great! Thanks. This is likely because I do feel better since I have been aware that there's life beyond x86. :o) Wolfgang. Latency tests with Xenomai on various PowerPC boards Board : Processor CPU-Clk Bus-Clk I-Cache D-Cache Memory Remarks TQM860L : MPC 860 50 MHz 50 MHz4 KB4 kB 16 MB TQM866M : MPC 866133 MHz 66 MHz 16 KB8 kB 128 MB Walnut : AMCC 405GP 200 MHz 100 MHz 16 KB8 kB 32 MB Yosemite: AMCC 440EP 533 MHz 133 MHz 32 KB 32 KB 256 MB DDR-RAM, FPU Ocotea : AMCC 440GX 533 MHz 152 MHz 32 KB 32 KB 256 MB DDR-RAM, L2 256 KB Linux : DENX linux-2.6.14-rc3-g4c234921 iPipe : 1.0-00 Xenomai: SVN 2005-10-15 CRUNCER without load: | Ideal computation time TQM860L | 368 us ??? TQM866L | 10008 us Walnut | 10150 us Yosemite | 9911 us Ocotea | 9479 us SWITCH without load: | lat min| lat avg| lat max|lost TQM860L | 103360| 107840| 209280| 0 TQM866L | 25745| 31880| 51369| 5 Walnut | 24620| 25965| 32280| 1 Yosemite |5626|5655| 17403| 0 Ocotea |5158|5169| 10038| 0 KLATENCY with load: |-lat min|-lat avg|-lat max|-overrun|---test-time TQM860L | 50560| 98976| 199040| 0|00:09:45 TQM866L | 13835| 28571| 74348| 0|00:11:44 Walnut | 16195| 25062| 45755| 0|
[Xenomai-core] Xenomai and gdbserver
Hi I wonder if someone has been able to perform a remote debug with xenomai/fusion. I have problems debugging fusion-0.9.1 programs with kernel-2.6.12.2 and Fedora Core 2 gdb-6.0 When i run GDB chain and step into rt_task_create(...), GDB prompts "[1]+ Stopped gdb chain" and terminates. I can call "gdbserver ipnum:port chain". then connect to it from a remote machine using gdb and "target remote..."
Re: [Xenomai-core] Xenomai and gdbserver
I use remote debug with fusion/2.6.13, but I am using fusion from svn. Also, there are bugs. One I have found recently is that if a task is created with T_SUSP and then you start stepping through the code, the task seems to start up on its own somehow. Weird. Older verisons of fusion had issues with not every task in the application halting on breakpoint. On 10/18/05 8:10 AM, "Marco Cavallini" <[EMAIL PROTECTED]> wrote: > Hi > I wonder if someone has been able to perform a remote debug with > xenomai/fusion. > I have problems debugging fusion-0.9.1 programs with kernel-2.6.12.2 and > Fedora Core 2 > gdb-6.0 > > When i run GDB chain and step into rt_task_create(...), GDB prompts "[1]+ > Stopped gdb chain" and > terminates. I can > call "gdbserver ipnum:port chain". then connect to it from a remote machine > using gdb and "target remote..." > > > ___ > Xenomai-core mailing list > Xenomai-core@gna.org > https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Xenomai and gdbserver
Steven Seeger wrote: I use remote debug with fusion/2.6.13, but I am using fusion from svn. Also, there are bugs. One I have found recently is that if a task is created with T_SUSP and then you start stepping through the code, the task seems to start up on its own somehow. Weird. Last time you reported that you actually mentioned the rt_task_spawn() service, which is designed to start the task immediately. Reading about the T_SUSP bit now seems to mean that you are not using rt_task_spawn() anymore, but that the problem indeed appears. Could you be more specific about the code in question? Older verisons of fusion had issues with not every task in the application halting on breakpoint. Strange indeed, since there is no reason for the exception triggered by any breakpoint to behave in a context-dependent manner, I mean on a task-by-task basis. Do you remember the first version that seemed to solve the issue? On 10/18/05 8:10 AM, "Marco Cavallini" <[EMAIL PROTECTED]> wrote: Hi I wonder if someone has been able to perform a remote debug with xenomai/fusion. I have problems debugging fusion-0.9.1 programs with kernel-2.6.12.2 and Fedora Core 2 gdb-6.0 When i run GDB chain and step into rt_task_create(...), GDB prompts "[1]+ Stopped gdb chain" and terminates. I can call "gdbserver ipnum:port chain". then connect to it from a remote machine using gdb and "target remote..." ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core -- Philippe.
Re: [Xenomai-core] Xenomai and gdbserver
Marco Cavallini wrote: Hi I wonder if someone has been able to perform a remote debug with xenomai/fusion. I have problems debugging fusion-0.9.1 programs with kernel-2.6.12.2 and Fedora Core 2 gdb-6.0 When i run GDB chain and step into rt_task_create(...), GDB prompts "[1]+ Stopped gdb chain" and terminates. I can I'm tracking an issue like that, causing the debuggee to run into a SIGBUS, due to the program counter being messed up somehow. AFAICT, this sometimes happens when stepping over code that migrates between primary and secondary modes (and rt_task_create does). I need to log this one on the bug tracker. It's pretty PITA to chase, but it's 100% reproductible here, so there's hope. call "gdbserver ipnum:port chain". then connect to it from a remote machine using gdb and "target remote..." ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core -- Philippe.
Re: [Xenomai-core] Cosmetic changes to script xeno-config + man page
Romain Lenglet wrote: > > In order to compare Xenomai with other Debian packagees, I > > checked gtk-config, and I have a few remarks on xeno-config > > and its manpage. > [...] > > I merely documented xeno-config as it is now, and made the > printed usage consistent. If you modify it, I will update the > manpage accordingly. Sorry for the digression then. But the point about DESTDIR still holds, from my point of view. > > > Another item to add to the looOOong-term wishlist: I would like > to have ready-to-use autoconf rules, to use instead of > xeno-config. > > If someone ever writes such rules, e.g. in a "xenomai.m4" file, > it would only be necessary, at Xenomai install time: > 1- to copy xenomai.m4 into /usr/share/autoconf/autoconf/ > 2- to add the following line into autoconf.m4: > m4_include([autoconf/xenomai.m4]) > 2- to regenerate autoconf.m4f by running: > cd /usr/share/autoconf/autoconf > autom4te --language=autoconf --freeze --output=autoconf.m4f > > A simpler solution would be to ship a xenomai.m4 to be used as a > acinclude.m4 in every project using Xenomai. But I have had very > bad experiences with aclocal in that use case. aclocal is quite > buggy. And it would be more confortable for projects it is were > immediately available after installing Xenomai. Yes, this was the original plan, but there are still many things on our todo list before that. > > > > Now, about the manpage itself, unless I am wrong, the DESTDIR > > feature is not documented, it is very useful when compiling > > for a target. > > DESTDIR is a feature of makefiles generated through Automake, not > of xeno-config. Why would you like to document this is in > xeno-config's manpage? DESTDIR is used by xeno-config the same way it is used by Makefiles. When you compiled Xenomai for a target and installed it with DESTDIR=/home/romain/target, you have to set DESTDIR in xeno-config environment so that it outputs -I/home/romain/target/usr/realtime/include and -L/home/romain/target/usr/realtimeLib. Since it is a rather obscure functionality, it probably deserves an explanation. -- Gilles Chanteperdrix.
Re: [Xenomai-core] Xenomai latency tests on various PowerPC boards
Wolfgang Grandegger wrote: On 10/18/2005 01:44 PM Philippe Gerum wrote: Philippe Gerum wrote: Wolfgang Grandegger wrote: Hallo, attached you will find the results of Xemonai latency measurements on various embedded PowerPC boards using MPC 8xx and AMCC 4xx processors, from low to high end covering a worst case latency range from 25 to 225 us. It also includes a comparison with RTAI 3.0r5 on the slowest CPU. Here are some remarks and comments: - On low-end processor code size matters a lot and it's difficult to beat RTAI/RTHAL. Beat no, get closer, yes, probably. The good news is that looking at the figures, we do have a margin of improvement! :o> Btw, the nucleus can be configured so that the user-space threading engine is compiled out (i.e. CONFIG_XENO_OPT_PERVASIVE from the nucleus menu), which would be the corresponding profile to compare with klatency (i.e. sched_up). Disabling this option reduces the code size for the nucleus from: text databssdechexfilename 66740792 6540 74072 12158 nucleus/xeno_nucleus.ko to: text databssdechexfilename 52596576 3956 57128 df28 nucleus/xeno_nucleus.ko Disabling the periodic timer support which is unused for the klatency test brings this down to: textdata bss dec hex filename 51040 5443956 55540d8f4 nucleus/xeno_nucleus.ko OK, here are the new figures with (*) CONFIG_XENO_OPT_PERVASIVE is not set CONFIG_XENO_HW_PERIODIC_TIMER is not set: |-lat min|-lat avg|-lat max|-overrun|---test-time RTAI 3.0r5 | 23120| 31838| 70520| ?|00:12:26 Xenomai| 50560| 98976| 199040| 0|00:09:45 Xenomai (*)| 44160| 96215| 200640| 0|00:09:53 The min latency decreases as expected. I just discovered that -00 did not include some recent changes I had in my tree, aimed at prevent high latencies during fork pressure. I've committed -01 which does include them. When time allows, I'd be interested to know if this has some impact on the Ocotea figures. TIA, -- Philippe.
