Clock synchronization

From Wiki for iCub and Friends
Revision as of 18:38, 18 August 2011 by Lorenzo (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

In a distributed network of machines it is important that clocks are maintained synchronized. Having an ntp client installed on all machines should be enough for this purpose.

The most common source of problems when clocks are not synchronized on the robot is the clock skew message produced by make when compiling the software. This happens form example on the pc104 (whose clock is reset at every boot). The pc104 mounts repositories from an external machine, which probably has a correct time. Since files in the repositories have correct time they are seen as having a time stamp in the future when accessed from the pc104.

Clock skew might seem a harmless warning message, however it is annoying and, in some cases, might produce partial code re-builds. We recommend you fix the clock skew problem.

First make sure clocks are synchronized

The opencall laptop comes with ntpd installed, if the laptop has network access this should be enough to:

  • have correct and synchronized clock on the laptop
  • allow the pc104 to synchronize time with the laptop

Make sure the laptop has correct time and allows synchronization

The pc104 can synchronize the clock with the laptop only if the former has previously synchronized its clock with another server. This happens automatically if the laptop has access to the external network. The ntp daemon server is responsible for this, but please consider that it might take some time. To check the status of the synchronization on the laptop you can type:

 ntpq -p

You should see something like:

remote          refid            st t when poll reach delay  offset jitter
kraken2.bilink. 193.204.114.232  2  u 48   64   77    12.780 -3.741 4.868 

By editing /etc/ntp.conf you can check the server with which ntp tries synchronization. This can be another ntp machine on your local network. If the internet is down it could be useful to point the laptop as clock manager so add those lines to the files /etc/ntp.conf

 server 10.0.0.1

Set clock on the pc104

The pc104 has a startup script that tries to synchronize the time with 10.0.0.1 (the laptop). This script runs for a certain amount of time after boot (~ 10 minutes) then gives up. At any time you can manually synchronize the time by running:

  sudo ntpdate 10.0.0.1

you can also substitute 10.0.0.1 with any reachable machine in your network that has ntp server running (or modify the startup script accordingly).

The pc104 can also host an ntp daemon client that could run periodically to maintain clock synchronized with an external server (the laptop). This does not run by default to avoid interferences with the robot operation. You can re-enable it at your own risk (ntpd is considered a very light process so probably nothing will happen):

 sudo apt-get install ntp
 /etc/init.d/ntpd stop/start 

If ntpdate fails, it means that the laptop (or the server you are connecting to) does not have a synchronized clock. Make sure the server has ntp, and it can connect to the network. Alternatively you can configure the laptop to trust its own internal clock. If you do this the laptop and the pc104 can have their own time; this is enough to avoid clock skew.

Fix timestamps in files

Once clocks are synchronized, if you still get clock skew messages it means that some files have wrong time stamp. You can finally fix this by running:

 sudo find ./ -exec touch {} \;

From the root of the repositories, in the laptop: /exports

Clock synchronization in the cluster

In general it appears to be a good idea to synchronize clocks within the cluster of machines that you use to control the robot. To a certain (unfortunately unknown) extent you can get precise clock synchronization so that calls to Time::now() return consistent values. This can be helpful.