Re: [Xenomai-help] no-brainer realtime issue
No, my application uses and always has used periodic timing with a tick of 125 us. Steven On 2/17/06 10:29 AM, Philippe Gerum [EMAIL PROTECTED] wrote: Steven Seeger wrote: Could my problem be caused by me using the latest SVN for xenomai? Should I try the released version instead? You should first try my last suggestion, i.e. disable the forced periodic support from the configuration. If your application used to rely on the deprecated rt_timer_start() call for setting the oneshot mode, then enabling the periodic timing option is inappropriate. Steven ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] no-brainer realtime issue
Just to let you know, I tried recompiling everything without periodic support enabled and I can't even load the xeno_nucleus.ko module. I get an -ENODEV presumably because my board won't work with the aperiodic timing mode. On 2/17/06 7:59 AM, Philippe Gerum [EMAIL PROTECTED] wrote: Yous seem to be running in periodic timing mode, with a default slice of 125 us. Which parameters are passed to rt_task_set_periodic() and rt_task_wait_period() in your sampling task? ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] no-brainer realtime issue
Just to let you know, I tried recompiling everything without periodic support enabled and I can't even load the xeno_nucleus.ko module. I get an -ENODEV presumably because my board won't work with the aperiodic timing mode. On 2/17/06 7:59 AM, Philippe Gerum [EMAIL PROTECTED] wrote: Yous seem to be running in periodic timing mode, with a default slice of 125 us. Which parameters are passed to rt_task_set_periodic() and rt_task_wait_period() in your sampling task?
Re: [Xenomai-help] no-brainer realtime issue
Steven Seeger wrote: Maybe I didn't set it up right? I followed the instructions in the README.INSTALL file. Attached is my linux tree's .config. Could you try and configure the timer in aperiodic mode ? -- Gilles Chanteperdrix. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] no-brainer realtime issue
Steven Seeger wrote: Which framebuffer support did you select at kernel level? What is the output of testsuite/latency while using the VT console? I'm using the gx1fb framebuffer for the geode. However, since this problem occurs even when the VT outputting the text is not active, I don't think it's fb related. The latency output is just a bunch of numbers. :P Until those numbers are sane, there is no point in trying anything else though. Here is some output with the latency -p 500 command, and halfway through it I put a 100% load on the cpu. Ok, the testsuite clearly fails on your board, and something in the current setup prevents any real-time use. .config would help. == Sampling period: 500 us == Test mode: periodic user-mode task warming up... RTT| 00:00:01 (periodic user-mode task, 500 us period) RTH|-lat min|-lat avg|-lat max|-overrun|lat best|---lat worst RTD|-2327277|-1766041|-1196976| 0|-2327277| -1196976 RTD|-3443424|-2882532|-2293218| 0|-3443424| -1196976 RTD|-4558603| 3176566|-3412343| 0|-4558603| -1196976 RTD|-5663780| 2061495|-4522950| 0|-5663780| -1196976 RTD|-6764019| 976449|-5637527| 0|-6764019| -1196976 RTD|-7885937| -137963|-6750223| 0|-7885937| -1196976 RTD|-8993661|-1254331|-7868111| 0|-8993661| -1196976 RTD| -10141655|-2395933|-8979941| 0| -10141655| -1196976 ---||||| - RTS| -10141655| -277784|-1196976| 0|00:00:08/00:00:08 -- Philippe. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] no-brainer realtime issue
Maybe I didn't set it up right? I followed the instructions in the README.INSTALL file. Attached is my linux tree's .config. Steven Until those numbers are sane, there is no point in trying anything else though. Ok, the testsuite clearly fails on your board, and something in the current setup prevents any real-time use. .config would help. lin.conf Description: Binary data ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] no-brainer realtime issue
Steven Seeger wrote: Maybe I didn't set it up right? I followed the instructions in the README.INSTALL file. Attached is my linux tree's .config. Try enabling the SMI workaround (Xeno's Machine menu), just in case, since you are running a Geode box. Steven Until those numbers are sane, there is no point in trying anything else though. Ok, the testsuite clearly fails on your board, and something in the current setup prevents any real-time use. .config would help. -- Philippe. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] no-brainer realtime issue
Hehe I misread that option. I read it as disable SMI and intended for it to be on. I'll try that. :) Steven On 2/17/06 6:28 AM, Philippe Gerum [EMAIL PROTECTED] wrote: Steven Seeger wrote: Maybe I didn't set it up right? I followed the instructions in the README.INSTALL file. Attached is my linux tree's .config. Try enabling the SMI workaround (Xeno's Machine menu), just in case, since you are running a Geode box. Steven Until those numbers are sane, there is no point in trying anything else though. Ok, the testsuite clearly fails on your board, and something in the current setup prevents any real-time use. .config would help. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] no-brainer realtime issue
Turning on the SMI disable stuff, rebuilding the kernel and modules, and installing everything to my board did not solve the latency problem. My numbers keep growing as the latency tester runs. Any other ideas? I've never had an rtai/xenomai/fusion/whatever system fail basic realtime requirements like this before in the 4 years I've been using this geode board. Steven On 2/17/06 6:28 AM, Philippe Gerum [EMAIL PROTECTED] wrote: Steven Seeger wrote: Maybe I didn't set it up right? I followed the instructions in the README.INSTALL file. Attached is my linux tree's .config. Try enabling the SMI workaround (Xeno's Machine menu), just in case, since you are running a Geode box. Steven Until those numbers are sane, there is no point in trying anything else though. Ok, the testsuite clearly fails on your board, and something in the current setup prevents any real-time use. .config would help. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] no-brainer realtime issue
Yous seem to be running in periodic timing mode, with a default slice of 125 us. Which parameters are passed to rt_task_set_periodic() and rt_task_wait_period() in your sampling task? I am confused why this matters? You said the latency test shows my realtime does not work, so clearly the problem I have isn't specific to my code, but rather to my system, right? Here is my call to rt_task_set_periodic: rt_task_set_periodic(task, TM_NOW, rt_timer_ns2ticks(50)); I don't pass any parameters to rt_task_wait_period() Steven ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] no-brainer realtime issue
Steven Seeger wrote: Yous seem to be running in periodic timing mode, with a default slice of 125 us. Which parameters are passed to rt_task_set_periodic() and rt_task_wait_period() in your sampling task? I am confused why this matters? You said the latency test shows my realtime does not work, so clearly the problem I have isn't specific to my code, but rather to my system, right? The latency figures obtained are totally braindamage, so either something weird is happening in 1) the real-time core, or 2) with the hw config selected, or 3) in the application. 1) is always possible, but you might also consider that early timer shots beyond two _milliseconds_ (-2293218 ns) would have been caught by a few other people on the list; this has not been the case yet. So considering a massive breakage in the real-time behaviour of that magnitude at this point of the investigation seems a bit premature. 2) Geode brings its own set of issues. SMI is one of them. Something may also go wrong when upgrading a kernel while reusing an old config file. Given your past answers, I now take for granted that it is not the case, but asking first is better. 3) v2.1 has changed a lot of things wrt v2.0, including the way some key configurations are made. Timing mode is one of those critical changes, and maybe one of those changes has had a negative impact in some unexpected way. Looking at the application to see what it requests to the real-time core and how it does it, is the usual way to start digging the issue. Here is my call to rt_task_set_periodic: rt_task_set_periodic(task, TM_NOW, rt_timer_ns2ticks(50)); Ok, I think we might be dealing with a timing mode issue. Could you try disabling CONFIG_XENO_OPT_TIMING_PERIODIC in your kernel config (Timing menu) and re-run the latency test? TIA, I don't pass any parameters to rt_task_wait_period() Yep, my mistake. Steven -- Philippe. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] no-brainer realtime issue
Steven Seeger wrote: Which framebuffer support did you select at kernel level? What is the output of testsuite/latency while using the VT console? I'm using the gx1fb framebuffer for the geode. However, since this problem occurs even when the VT outputting the text is not active, I don't think it's fb related. The latency output is just a bunch of numbers. :P Until those numbers are sane, there is no point in trying anything else though. Here is some output with the latency -p 500 command, and halfway through it I put a 100% load on the cpu. Ok, the testsuite clearly fails on your board, and something in the current setup prevents any real-time use. .config would help. == Sampling period: 500 us == Test mode: periodic user-mode task warming up... RTT| 00:00:01 (periodic user-mode task, 500 us period) RTH|-lat min|-lat avg|-lat max|-overrun|lat best|---lat worst RTD|-2327277|-1766041|-1196976| 0|-2327277| -1196976 RTD|-3443424|-2882532|-2293218| 0|-3443424| -1196976 RTD|-4558603| 3176566|-3412343| 0|-4558603| -1196976 RTD|-5663780| 2061495|-4522950| 0|-5663780| -1196976 RTD|-6764019| 976449|-5637527| 0|-6764019| -1196976 RTD|-7885937| -137963|-6750223| 0|-7885937| -1196976 RTD|-8993661|-1254331|-7868111| 0|-8993661| -1196976 RTD| -10141655|-2395933|-8979941| 0| -10141655| -1196976 ---||||| - RTS| -10141655| -277784|-1196976| 0|00:00:08/00:00:08 -- Philippe.
Re: [Xenomai-help] no-brainer realtime issue
Steven Seeger wrote: Turning on the SMI disable stuff, rebuilding the kernel and modules, and installing everything to my board did not solve the latency problem. My numbers keep growing as the latency tester runs. Any other ideas? I've never had an rtai/xenomai/fusion/whatever system fail basic realtime requirements like this before in the 4 years I've been using this geode board. Yous seem to be running in periodic timing mode, with a default slice of 125 us. Which parameters are passed to rt_task_set_periodic() and rt_task_wait_period() in your sampling task? Steven On 2/17/06 6:28 AM, Philippe Gerum [EMAIL PROTECTED] wrote: Steven Seeger wrote: Maybe I didn't set it up right? I followed the instructions in the README.INSTALL file. Attached is my linux tree's .config. Try enabling the SMI workaround (Xeno's Machine menu), just in case, since you are running a Geode box. Steven Until those numbers are sane, there is no point in trying anything else though. Ok, the testsuite clearly fails on your board, and something in the current setup prevents any real-time use. .config would help. -- Philippe.
Re: [Xenomai-help] no-brainer realtime issue
Steven Seeger wrote: Yous seem to be running in periodic timing mode, with a default slice of 125 us. Which parameters are passed to rt_task_set_periodic() and rt_task_wait_period() in your sampling task? I am confused why this matters? You said the latency test shows my realtime does not work, so clearly the problem I have isn't specific to my code, but rather to my system, right? The latency figures obtained are totally braindamage, so either something weird is happening in 1) the real-time core, or 2) with the hw config selected, or 3) in the application. 1) is always possible, but you might also consider that early timer shots beyond two _milliseconds_ (-2293218 ns) would have been caught by a few other people on the list; this has not been the case yet. So considering a massive breakage in the real-time behaviour of that magnitude at this point of the investigation seems a bit premature. 2) Geode brings its own set of issues. SMI is one of them. Something may also go wrong when upgrading a kernel while reusing an old config file. Given your past answers, I now take for granted that it is not the case, but asking first is better. 3) v2.1 has changed a lot of things wrt v2.0, including the way some key configurations are made. Timing mode is one of those critical changes, and maybe one of those changes has had a negative impact in some unexpected way. Looking at the application to see what it requests to the real-time core and how it does it, is the usual way to start digging the issue. Here is my call to rt_task_set_periodic: rt_task_set_periodic(task, TM_NOW, rt_timer_ns2ticks(50)); Ok, I think we might be dealing with a timing mode issue. Could you try disabling CONFIG_XENO_OPT_TIMING_PERIODIC in your kernel config (Timing menu) and re-run the latency test? TIA, I don't pass any parameters to rt_task_wait_period() Yep, my mistake. Steven -- Philippe.
Re: [Xenomai-help] no-brainer realtime issue
Could my problem be caused by me using the latest SVN for xenomai? Should I try the released version instead? Steven
Re: [Xenomai-help] no-brainer realtime issue
Steven Seeger wrote: Could my problem be caused by me using the latest SVN for xenomai? Should I try the released version instead? You should first try my last suggestion, i.e. disable the forced periodic support from the configuration. If your application used to rely on the deprecated rt_timer_start() call for setting the oneshot mode, then enabling the periodic timing option is inappropriate. Steven ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help -- Philippe.
[Xenomai-help] no-brainer realtime issue
I have a xenomai userspace application that does the following: A thread of priority 90 toggles a bit (outb) to move a stepper motor. A thread of priority 10 updates the display once a second. The motor thread is periodic and uses rt_task_wait_period(). The display thread just uses sleep(1). My question is this: the priority 90 thread is higher priority, and doesn't do anything relating to linux system calls. Whenever the display thread updates the display, the motor thread stalls momentarily. Any idea why this is? Steven ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] no-brainer realtime issue
Steven Seeger wrote:
I have a xenomai userspace application that does the following:
A thread of priority 90 toggles a bit (outb) to move a stepper motor.
A thread of priority 10 updates the display once a second.
The motor thread is periodic and uses rt_task_wait_period(). The display
thread just uses sleep(1).
My question is this: the priority 90 thread is higher priority, and doesn't
do anything relating to linux system calls. Whenever the display thread
updates the display, the motor thread stalls momentarily.
Any idea why this is?
If your motor thread really looks like
while (1) {
toggle_bit();
rt_task_wait_period();
}
you may suffer from contentions of the related bus towards your motor
(what kind of interface do you use?).
To test this, just put some instrumentation around the toggle_bit()
(take timestamps and look for abnormal delays). What frequency is your
motor thread running at?
If there is more code in your loop, please post the program (or a
simplified but still failing version).
Jan
signature.asc
Description: OpenPGP digital signature
___
Xenomai-help mailing list
Xenomai-help@gna.org
https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] no-brainer realtime issue
Jan Kiszka wrote:
Steven Seeger wrote:
I have a xenomai userspace application that does the following:
A thread of priority 90 toggles a bit (outb) to move a stepper motor.
A thread of priority 10 updates the display once a second.
The motor thread is periodic and uses rt_task_wait_period(). The display
thread just uses sleep(1).
My question is this: the priority 90 thread is higher priority, and doesn't
do anything relating to linux system calls. Whenever the display thread
updates the display, the motor thread stalls momentarily.
Any idea why this is?
If your motor thread really looks like
while (1) {
toggle_bit();
rt_task_wait_period();
}
you may suffer from contentions of the related bus towards your motor
(what kind of interface do you use?).
To test this, just put some instrumentation around the toggle_bit()
(take timestamps and look for abnormal delays). What frequency is your
motor thread running at?
If there is more code in your loop, please post the program (or a
simplified but still failing version).
Additionally, the output of /proc/xenomai/stat for a failing run might give some
useful information.
Jan
___
Xenomai-help mailing list
Xenomai-help@gna.org
https://mail.gna.org/listinfo/xenomai-help
--
Philippe.
___
Xenomai-help mailing list
Xenomai-help@gna.org
https://mail.gna.org/listinfo/xenomai-help
