Chrony configuration and limitations

asked 2011-09-12 01:59:55 -0500

Victor Lopez
651 ●12 ●21 ●29

updated 2011-09-13 04:56:10 -0500

Hi, we're having some issues regarding time synchronization between the robot and desktop computers.

I have read that chrony is the best NTP client to perform time synchronization, but I can't find much information about how is it impemented in ROS.

As far as I know, there's an initial time synchronization which can produce a big time change and, from then onwards, the time is synchronized in small steps.

How long does the initial sinchronization take? What happens if there's no network access to the NTP server when starting the robot? Is the initial synchronization delayed and it is done later? Or it is never performed?

Because running some tests, I've seen that making big changes in system time during execution can have a devastating effect on running software.

answered 2011-09-12 02:24:30 -0500

dornhege

31395 ●134 ●284 ●498

Actually it is not implemented in ROS at all, but running at the system level so ROS/any program can be agnostic and just use system time.

The initial sync via NTP is usually very quick, but this is something you would trigger. What chrony actually does is slow a clock slightly to match times, so that there are no big changes is system time for the exact reason that you recognized.

edit flag offensive delete link

Comments

Ok so the initial sync must be triggered, and is there some kind of policy defined of what should be done if the robot is started outside of NTP server range?

Victor Lopez ( 2011-09-12 02:38:54 -0500 )edit

I guess you want to synchronize your desktop on the robot's time and synchronize the robot on NTP time whenever possible. That means, it shouldn't really matter if the robot has access to NTP or not.

Lorenz ( 2011-09-12 04:29:43 -0500 )edit

I usually sync manually with NTP before I start the chrony service the first time and then forget about it. Chrony is good in that it doesn't jump the time and does a clock skew to converge. However initially that can be problematic if the time is completely wrong for it will slowly correct it.

tfoote ( 2011-09-12 05:06:14 -0500 )edit

The ultimate goal is to have the same (or a very similar) system time on one or more robots, and the desktop computers that connect to them. There's a NTP server in the LAN, but there's a chance that the robot is started outside of Wifi range. I guess that we'll skip the initial sync in that case.

Victor Lopez ( 2011-09-12 22:46:48 -0500 )edit

I think you are facing a logical problem here. Assuming the robot out of Wifi-range is out of sync: You can either do the initial hard-sync with a time jump and its problems or not do that but slowly correct the time - being out of sync for some time.

dornhege ( 2011-09-12 22:56:27 -0500 )edit

The only way out would be to include a permanent machine time offset, but that sound horrible to maintain.

dornhege ( 2011-09-12 22:57:20 -0500 )edit

Yes I agree, what I wanted to make sure is that the hard-sync was triggered by hand and it wouldn't be done as soon as the computer regained network access to the NTP server.

Victor Lopez ( 2011-09-12 23:22:25 -0500 )edit

add a comment

Chrony configuration and limitations

1 Answer

Comments

Question Tools

Stats

Related questions

Chrony configuration and limitations edit

1 Answer

Comments

Question Tools

Stats

Related questions

Chrony configuration and limitations