Nadym Salem wrote: > On Fri, August 17, 2007 14:20, Jan Kiszka wrote: > >>>> > Ok, since we discussed that in xenomai mailinglist yesterday and >>>> there >>>> > seems to be no solution with my bios, >>>> There is one solution which you refused to try. >>> Not refused, just postponed. What I suppose is, that my rtnet problem is >>> independent from the xenomai problem because of the mentioned reasons, >>> and >>> that's what I wanted to find out to save some time in installing >>> everything new and finding out that it's a completely different problem. >> Your slave utterly fails to send its calibration request frame on time. >> It misses its slot by more than 200 cycles (yeah, 400 ms, I packed my >> calculator already as well), and this is a fairly unusual behaviour, >> very likely due to timer latency issues of the underlying hardware (or >> RTOS, but that's less likely). >> If you don't believe this, start instrumenting (printk etc.) TDMA and >> compare the time it wants to sleep for its slot to the time it actually >> does. I would be surprised if the delay is already wrong (not saying >> that this is absolutely impossible, but very unlikely given your other >> reports). > > It wasn't a question of believing. That my xenomai timing is out of any > acceptible range is not a question. That my slave is not able to send the > requests in time, too. What I was just wondering about is the fact, that a > master on the same machine is able to do cycle times under 2 ms (same
Hmm, I have some theory about this, but it's too speculative ATM. > behaviour with two identical cloned machines, so no hardware problem). If You mean you cloned the _slave_ setup to two different boxes (different mainboards at least) and the issue persists? I must have overread this "minor" hint then. In that case we would face a software issue, and I would take everything back. > you tell me, it's nevertheless the Xenomai problem, I have no doubt it is > like that. I will report what 2.6.2 will do. Again: If you slave issue if "portable" across different hardware and even Xenomai versions, we need to step into RTnet debugging as sketched earlier. This need not take much time as already the first action of the slave fails. If you go that way and need more hints where to look, let me know. Jan
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________ RTnet-users mailing list RTnet-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rtnet-users