On Thu, August 16, 2007 11:43, Jan Kiszka wrote: >>>>>> I'm using two machines here, one acts as a master, other one acts as >>>>>> a slave. The slave isn't able to synchronize with master when >>>>>> configuring a cycle length around 10 down to 2 ms (and most probably >>>>>> any cycle length lower then that). When choosing 1 second cycle >>>>>> length, it syncs fine. >>>>>> Capturing the whole story with wireshark shows, that slave in short >>>>>> cycle configurations requests reply calibration frame e.g. in cycle >>>>>> 1500, although it sends request calibration frame in cycle 1700, so >>>>>> of course this can't work. As it works in 1 s cycle configuration, >>>>>> only reason for this behavoir I can imagine is, that slave isn't >>>>>> able >>>>>> to calculate and send request calibration frame early enough. But >>>>>> this isn't really possible, because we're talking about a >2GHz >>>>>> machine (x86). >>>>> ...which is know to be free of hardware-related latency quirks >>>>> (tested >>>>> with Xenomai tools)? If yes, please send be your trace. >>>> Don't wonder I'm answering :-) >>>> attached a complete log of xeno-test, do you also need a wireshark log >>>> ? >>> Yeah, I was actually referring to the pcap file. >> attached, I cut the important lines +- some. It's the only request >> coming >> from slave. > The master drops this request because the target slot is in the past.
That's what Karl wrote in his first message ;) > What is the slot offset of the slave? ~1700 us? Could you post the full > TDMA configuration? You don't use RTcfg, correct? No, it's 800. Master: cycletime 2000 us, offset 100, size 102 Slave: offset 800 We don't use RTcfg, that's right. Our implementation on an embedded system works fine with the same master. > -200 cycles, i.e. 4 seconds... Hmm... This sounds as weird as your > other, yet unexplained observation. >>> Anyway, the xeno-test looks a fishy as well. The latency tool appears >>> to >>> run fine (except for the testing device conflicts, but that's a >>> different story), but the cyclictest is totally screwed! And these are >>> dimensions normally related to SMI etc. artefacts. >> Due to some error here, the SMI workaraound was not included, attached a >> new file with SMI workaroung.....but it didn't really change anything. >>> Please make sure no other RT load is present during the test (just in >>> case) and re-run latency and cyclictest stand-alone for several minutes >>> each. If strange numbers remain (millisecond latencies...), check >>> TROUBLESHOOTING hints and then report to xenomai-help. >> The machine just came up and we started the test, nothing else is >> running. >> But where do you see milliseconds of latency ? I see worst values of >> around 20 microseconds. > > Here: > > T: 0 ( 5727) P:10 I: 1000 C: 9 Min: 19 Act: 19 Avg: > 2722 Max: 6489 > ^^^^ > > Might be a problem only of the cyclictest (still worth reporting then), > but it may point at more serious issues as well. Xenomai List report will follow. Greets, Nadym ------------------------------------------------------------------------- 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
