networks//time synchronization

Time synchronization is the practice of giving every device in a system a common clock and every measurement a trustworthy timestamp, so that data from different sensors can be combined at the instant each one describes. It deals with three things. **Latency** is the time between a physical event and the number being available (or the action being applied). Jitter is the variation of that latency or of the sampling period. **Clock offset** is the disagreement between devices: each has its own quartz oscillator, with typical tolerances of 20 to 50 ppm, and 50 ppm is 4.3 seconds a day of **clock drift**.

Time synchronization is the practice of giving every device in a system a common clock and every measurement a trustworthy timestamp, so that data from different sensors can be combined at the instant each one describes. It deals with three things. Latency is the time between a physical event and the number being available (or the action being applied). Jitter is the variation of that latency or of the sampling period. Clock offset is the disagreement between devices: each has its own quartz oscillator, with typical tolerances of 20 to 50 ppm, and 50 ppm is 4.3 seconds a day of clock drift.

The error a timing mistake causes is, to first order, speed times time:

δp≈v δt.\delta p \approx v\,\delta t .δp≈vδt.

A drone at 10 m/s whose camera and IMU disagree by 20 ms makes a 20 cm error when it fuses them; turning at 200 °/s, 5 ms is one degree of attitude. No filter sees that error as noise, because it is a bias that grows with speed (error budget).

A measurement without a reliable timestamp is half a measurement.

Stamp it at acquisition, with a common clock and as close to the hardware as possible (the sensor's interrupt, the DMA transfer, the chip's own counter), never when the message reaches the application.

To make separate clocks agree, NTP gives about a millisecond on a local network, PTP (IEEE 1588) with hardware timestamping goes below a microsecond, and the pulse per second of a GNSS receiver marks the second to tens of nanoseconds. A common hardware trigger that fires the camera and samples the IMU together removes the problem at its root.

In ROS 2 every message carries a header with a time; it must hold the acquisition time, not the publication time. A general-purpose Linux under load can add milliseconds of scheduling delay between the two, which is one reason fast loops run on a microcontroller (real-time computing).

With honest timestamps a late measurement is still useful: the estimator fuses it at the instant it describes and projects forward (delayed measurements). A message freshness check (sequence numbers and an age limit) protects the receiver from the opposite mistake, an old value delivered late that looks new.