Notes on clock synchronization

[fra-p]

@edwardalee and I have been investigating the problems that the techniques to synchronize the system clock over the network may create to Lingua Franca programs at runtime. We have been targeting mostly NTP, as it is common to be found in nowadays devices. To configure NTP, we installed on our laptops ntpd, a daemon compatible with Linux-based OSes.

NTP essentially synchronizes the system clock of a device with a worldwide time reference through the internet, so that the calls to clock_gettime for the CLOCK_REALTIME time representation always return a precise wall time within a few milliseconds. By default, when the time difference between the device time and the reference time is more than 128ms, NTP adjusts the local time by stepping to the reference time (apparently even backwards). These abrupt background time jumps may create problems in Lingua Franca programs, especially when going backwards. For example, if the LF worker threads are sleeping waiting for the physical time to catch up with the next tag, and in the meanwhile NTP adjusts the time, the worker threads may wake up earlier or later than expected.

From the man page, the ntpd CLI provides the -x option to enable the slew mode:

Slew up to 600 seconds. Normally, the time is slewed if the offset is less than the step threshold, which is 128 ms by default, and stepped if above the threshold. This option sets the threshold to 600 s, which is well within the accuracy window to set the clock manually. Note: Since the slew rate of typical Unix kernels is limited to 0.5 ms/s, each second of adjustment requires an amortization interval of 2000 s. Thus, an adjustment as much as 600s will take 14 days to complete. This option can be used with the -g and -q options. See the tinker configuration file directive for other options. Note: The kernel time discipline is disabled with this option.

The man page does not fully specify its behaviour, like if the time is anyway allowed to go backwards (even if slowly). Apparently[1], this is in details how the slew mode is supposed to work:

NTP slew mode is useful because the clock gets adjusted by changing the tick rate of the clock. The clock runs slightly faster or slower depending on the direction of the offset. In slew mode, time will never go backwards. This addresses the leap second problem.

In the end, the NTP slew mode looks like the desirable behaviour for clock synchronization during the execution of Lingua Franca programs: the local time is adjusted slowly and never goes backwards (guaranteeing monotonicity).

According to another source, the -x option might enable the slew mode only to avoid backward jumps, so forward jumps might still happen (this needs to be verified though). To enable the slew mode in both directions, it is necessary to add the following line to the /etc/ntp.conf configuration file:

slewalways yes

Another option we analyzed for time synchronization is PTM, coupled with PTP. PTM is essentially a protocol that allows to retrieve with a precision of tens of nanoseconds the reference time synchronized with PTP. This talk gives an overview of the protocol. However, PTM requires a specific hardware support (here is the list of compatible products), and our laptops do not provide it.

[cmnrd]

I don't understand the specific relationship between PTM and PTP, but in my experience, it is not a problem to run ptp on off-the-shelf hardware. I have used it several times with simple devices and switches and achieved us scale accuracy.

As far as I understand, ptp also slows down or speeds up the system clock and does not jump. At least it did that in my setup, with an initial offset between clocks in the range of 10s to a few minutes. One has to explicitly enable syncing the system clock, though.