synch problem with chrony and xenomai

asked 2014-05-20 08:22:50 -0500

mark_vision
275 ●35 ●41 ●49

Hi all, I've just discovered that to synchronize messages across different physical machines I have to use Chrony. Everithing is fine....except when I actually run my real robot, which is actuated with the xenomai module. Since then, the clock starts delaying very quickly. As soon as I stop the task, the clock starts re-synch. Note that the daemon is active all the time.

I think that xenomai is kind of excluding chrony o something like that, I'm not familiar with RT-linux unfortunately

edit retag flag offensive close merge delete

add a comment

answered 2014-05-20 09:45:19 -0500

ahendrix

47576 ●179 ●367 ●662 http://namniart.com/

I don't think this is chrony; I think your realtime control software is causing the clock to run slowly or miss interrupts. Chrony can help synchronize clocks across machines and can correct for a small amount of drift in the speed of your clock, but even without it running, the clock on your machine shouldn't drift that much.

You could do a few experiments to see this. Run chrony to sync up the clocks, then stop it and wait 5 or 10 minutes to measure the normal drift in your clock, using ntpdate -q. Then re-sync the clock, stop chrony, and run your control loop for the same amount of time to see if it causes the clock to drift more, and by how much.

I would also contact the vendor or developer that wrote your realtime control software and have them help you debug it.

edit flag offensive delete link

Comments

It's the realtime control software, for sure. The vendor...are my colleagues! We use xenomai on ubuntu 10.04 and since i'm not familiar with RT stuff I don't know from where can I start.

mark_vision ( 2014-05-20 22:13:04 -0500 )edit

I would start with the experiment that I described, to confirm that running the realtime process is causing your clock problems, and then start looking at adjusting the relative priority of your realtime process and the clock interrupt process until the problem goes away.

ahendrix ( 2014-05-21 06:36:32 -0500 )edit

I said it because I did the experiment you suggested last night and I repeated it this morning. The drift depends on the amount of load of the RT task. I found something here http://www.xenomai.org/pipermail/xenomai/2011-May/023553.html where they suggest to recompile the xenomai stuff with some flags changed. I will try it but I still can't understand why the clock is drifting too much even if it is ignoring the interrupt for few milliseconds.

mark_vision ( 2014-05-21 07:15:28 -0500 )edit

On most CPUs, there's often only a single bit to indicate if an interrupt is pending or not. If a SECOND interrupt occurs before the first is serviced, that bit remains set, and you don't get any indication that you've missed an interrupt.

ahendrix ( 2014-05-21 07:27:09 -0500 )edit

so what do you suggest? Do you think that recompiling with CONFIG_NO_HZ and CONFIG_HZ 100 instead of 1000 could solve the problem? Can my problem also be related to the CLOCK_HOST_REALTIME corrected in this version http://www.xenomai.org/index.php/Xenomai:News#2011-11-05_Xenomai_2.6.0 (my version is 2.5.2)?

mark_vision ( 2014-05-22 04:08:07 -0500 )edit

"and then start looking at adjusting the relative priority of your realtime process and the clock interrupt process until the problem goes away."

ahendrix ( 2014-05-22 10:05:47 -0500 )edit

add a comment

synch problem with chrony and xenomai

2 Answers

Comments

Question Tools

Stats

Related questions

synch problem with chrony and xenomai edit

2 Answers

Comments

Question Tools

Stats

Related questions

synch problem with chrony and xenomai