Page MenuHomeVyOS Platform

Migrate from ntpd to chronyd
Open, Requires assessmentPublicFEATURE REQUEST

Description

I would like to suggest a migration from ntpd to chronyd.

Easier to support vrf's, simpler config file, no need to listen on port 123 to sync time unless you intend to accept inbound connections, no need to listen on localhost to check status.

https://chrony.tuxfamily.org/comparison.html

Example config file:

# These servers were defined in the installation:
pool 0.pool.ntp.org. iburst
pool 1.pool.ntp.org. iburst
pool 2.pool.ntp.org. iburst
pool 3.pool.ntp.org. iburst

# Record the rate at which the system clock gains/losses time.
driftfile /var/lib/chrony/drift

# Allow the system clock to be stepped in the first three updates
# if its offset is larger than 1 second.
makestep 1.0 3

# Enable kernel synchronization of the real-time clock (RTC).
rtcsync

# Increase the minimum number of selectable sources required to adjust
# the system clock.
#minsources 2

# Get TAI-UTC offset and leap seconds from the system tz database.
leapsectz right/UTC

# You can include data from any files in a directory.
#include /etc/chrony.d/*.conf

# Binds the socket on which chronyd listens for NTP requests to a local address of the computer.
#bindaddress 192.168.1.1

# The allow directive is used to designate a particular subnet from which NTP clients are allowed to access the computer as an NTP server.
#allow 192.168.0.0/16
#allow 2001:db8::/32

Details

Difficulty level
Unknown (require assessment)
Version
-
Why the issue appeared?
Will be filled on close
Is it a breaking change?
Perfectly compatible
Issue type
Internal change (not visible to end users)

Event Timeline

Gunni updated the task description. (Show Details)

Can chronyd completely replace NTP?

Yes, absolutely, and if you visit the link in the post you'll see a comparison of them, and at the bottom is some explanation.

  1. 1. When the user's data source uses NTP cluster, whether switching to the new service may lead to the compatibility problem of NTP cluster network
  1. The NTP client feature of the new service just does not support extra timestamp validation

Does anyone understand the meaning of these performance data? I don’t know the unit of these data

  1. If the user configures his cluster as a "pool" or a bunch of "server" they should work fine, he can also "allow" them to connect to him if he wishes. I would recommend connecting to a good pool myself, or a low stratum device hosted locally, instead of making some kind of cluster.
  2. https://listengine.tuxfamily.org/chrony.tuxfamily.org/chrony-users/2016/03/msg00001.html

Regarding the units in the tables, it is probably microseconds.

Here is the output from my laptop chronyc tracking command:

$ chronyc tracking
Reference ID    : EC76EF1F (ht-time01.isnic.is)
Stratum         : 2
Ref time (UTC)  : Thu Oct 22 18:16:28 2020
System time     : 0.000072870 seconds fast of NTP time
Last offset     : +0.000046314 seconds
RMS offset      : 0.000053620 seconds
Frequency       : 16.529 ppm slow
Residual freq   : +0.000 ppm
Skew            : 0.011 ppm
Root delay      : 0.003382422 seconds
Root dispersion : 0.000307402 seconds
Update interval : 2059.1 seconds
Leap status     : Normal

It looks good, I want to ask how other people in the community think about this?

I've been running chronyd for some time in a number of environments without any noticeable issues. I do think the clock on the hosts seems to be a bit more stable, but not something that is overly remarkable one way or the other. I'd have no problem with the change.

erkin set Issue type to Internal change (not visible to end users).Aug 29 2021, 12:29 PM
erkin removed a subscriber: Active contributors.

Hey @erkin why hide this ticket? I'm still hoping for this change.

@Gunni I didn't hide it, I just pruned an obsolete subscriber group and assigned a task label. :-)

oh sorry, just misunderstood the

not visible to end users

sorry

Does anyone understand the meaning of these performance data? I don’t know the unit of these data

From the paragraph above "Test 1"

The results are mean values and standard deviations from 100 simulations. The values are in microseconds.

My understanding is that the values in the table are, thus, the difference between ground truth (the reference clock) and the client clock as synchronised by the three different NTP implementations, under various network conditions.

In regards to the chrony-ntp comparison in general;

Things ntp can do that chrony can’t:

  • ntp supports all operating modes from RFC 5905, including broadcast, multicast, and manycast server/client. However, the broadcast and multicast modes are inherently less accurate and less secure (even with authentication) than the ordinary server/client mode, and should generally be avoided.
  • ntp supports the Autokey protocol (RFC 5906) to authenticate servers with public-key cryptography. Note that the protocol has been shown to be insecure and has been obsoleted by NTS (RFC 8915).
  • ntp has been ported to more operating systems.
  • ntp includes a large number of drivers for various hardware reference clocks. chrony requires other programs (e.g. gpsd or ntp-refclock) to provide reference time via the SHM or SOCK interface.

I don't know whether there are platforms which VyOS supports but Chrony does not.

I assume that the VyOS project is not likely to care deeply about arcane NTP modes or local hardware clocks, but I thought those points were worth mentioning anyway.