-
Notifications
You must be signed in to change notification settings - Fork 2
Time Synchronization (NTP)
This tutorial was created by Simon-Pierre Deschênes (Thanks 🎉).
Typically, a robotic system is composed of multiple sensors, each streaming data with their own timestamps. In order to put in relation these different measurements, it is important that they are timestamped in a coherent way. For instance, if a camera detects that a car must take a left turn in 5 seconds and that the command is sent 6 seconds later, a crash can occur. In order to ensure coherent timestamping of all the data, the clocks of the different devices on the robot must be synchronized.
This protocol is used to synchronize the clocks of multiple devices over a network. To do so, packets are sent between devices with information about the current time of their clock.
To estimate the quality of the time delivered by a time server, a stratum is assigned to each time source. The stratum of a source is the number of leaps it takes to get to the original clock that computed the delivered time.
Chrony is an implementation of NTP. It is a tool for Unix that allows to synchronize the clocks of multiple devices. Once the time offset of a computer with a time source is computed using NTP, this computer can be synchronized by speeding up or slowing down its clock. Chrony will not instantly correct the clock of the computer, because a jump in time could lead to inconsistent behavior in time-dependent programs running on this computer, especially if the jump is in the past. The only exception to this rule is during the initialization of the computer. Only then can Chrony directly set the time of the clock to the correct time. Once the initialization phase is passed, jumps in time are not allowed. During normal operation, Chrony will select the best time source in its list (i.e., the one with the lowest stratum) and synchronize with it regularly. Chrony can also combine the information coming from multiple time sources to estimate a better time.
Chrony can be installed using the following command in a terminal on Ubuntu:
sudo apt install chrony
In order to synchronize a client to a server, Chrony must be installed on both computers. When Chrony is installed, a service that runs at startup is created. To query the status of this service, use the following command:
sudo systemctl status chrony
The following subsections will detail the configuration needed on a client and server computer that we would like to synchronize together.
To edit the configuration file of the server, run this command in a terminal on the server computer:
sudo vim /etc/chrony/chrony.conf
The following lines detail the time sources with which this computer is synchronized:
pool ntp.ubuntu.com iburst maxsources 4
pool 0.ubuntu.pool.ntp.org iburst maxsources 1
pool 1.ubuntu.pool.ntp.org iburst maxsources 1
pool 2.ubuntu.pool.ntp.org iburst maxsources 2
They can be removed if no outside time synchronization is wanted. The following line describes the conditions under which Chrony can perform a jump in time during initialization. In this case, a jump in time is allowed on the three first clock updates if the offset is greater than one second.
makestep 1 3
The following line must be added at the end of the file to allow time synchronization requests coming from the 192.168.0.0
sub-network.
allow 192.168.0.0/24
The following line must also be added if time synchronization is still wanted when internet is not available on the server. It specifies that when no outside time source is available, the stratum of the server computer is assumed to be 10.
local stratum 10
Once we are done editing the configuration file, the Chrony service needs to be restarted for the changes to take effect. It can be done using the following command:
sudo systemctl restart chrony
To edit the configuration file of the server, run this command in a terminal on the server computer:
sudo vim /etc/chrony/chrony.conf
The following lines detail the time sources with which this computer is synchronized:
pool ntp.ubuntu.com iburst maxsources 4
pool 0.ubuntu.pool.ntp.org iburst maxsources 1
pool 1.ubuntu.pool.ntp.org iburst maxsources 1
pool 2.ubuntu.pool.ntp.org iburst maxsources 2
They can be removed if no outside time synchronization is wanted. The following line describes the conditions under which chrony can perform a jump in time during initialization. In this case, a jump in time is allowed on the three first clock updates if the offset is greater than one second.
makestep 1 3
The following line must be added at the end of the file to allow time synchronization with the server computer that we set up previously.
server 192.168.0.2 iburst prefer
In this case, the IP address of the server computer was 192.168.0.2
, but it needs to be adjusted.
The iburst
parameter tells it that it must wait two seconds before making four-request bursts when synchronizing.
The prefer
parameters tells it that this time source is to be preferred over other sources that don't have this flag.
Once we are done editing the configuration file, the Chrony service needs to be restarted for the changes to take effect.
It can be done using the following command:
sudo systemctl restart chrony
The current time of the software clock (or system clock), which is the clock Chrony synchronizes, can retrieved using the following command:
date
The current time of the hardware clock, which can also be synchronized by Chrony if the parameters are set accordingly, can be retrieved using the following command:
sudo hwclock
It is possible to see which time sources are used by using the following command:
chronyc sources -v
If more information about time synchronization is wanted, the following command can be used:
chronyc tracking
- Warthog
- Common problems Warthog
- Marmotte
- Castor
- Husky
- Backpack
- UR10E Robotic Arm
- Robotic Total Stations (RTS)
- SSH Config
- Warthog Teach and Repeat (ROS1)
- Warthog Teach and Repeat (ROS2)
- Time Synchronization (NTP)
- Time Synchronization (PTP)
- Deployment of Robotic Total Stations (RTS)
- Deployment of the backpack GPS
- Warthog Emlid GPS
- Atlans-C INS
- How to use a CB Radio when going in the forest
- IP forwarding
- Emlid Data Postprocessing (PPK)
- Zenoh‐DDS bridge
- Setting up a reliable robot communication with Zenoh‐RMW
- Lessons Learned
- Robots' 3D Models
- Order Management
- Fast track Master → PhD
- Intellectual Property
- Repository Guidelines
- TF Cheatsheet
- Montmorency Forest Wintertime Dataset
- RTS-GT Dataset 2023
- Deschenes2021 Dataset
- TIGS Dataset
- DRIVE Datasets
- BorealHDR
- TimberSeg 1.0
- DARPA Subterranean Challenge - Urban Dataset
- How to upload a dataset to VALERIA
- ROS1 Bridge
- Migrating a repository to ROS2 (Humble)
- ROS2 and rosbags
- MCAP rosbags
- DDS Configuration (work in progress)
- Using a USB Microphone with ROS2
- ROS2 in VSCode
- ROS2 Troubleshooting
- Installing CUDA
- Installing ParaView
- Installing Mendeley Reference Manager
- Installing MT Manager (Ubuntu 22.04)
- Setup a VLAN on a Linux network interface
- NoMachine Setup for Headless Server
- Using 10Gbit Eth‐thunderbolt adapter with Bigfoot NAS