Page MenuHomeVyOS Platform

Migrate from ntpd to chronyd
Closed, ResolvedPublicFEATURE REQUEST

Assigned To
Authored By
Oct 21 2020, 9:12 PM
Referenced Files
F972277: 图片.png
Oct 22 2020, 6:16 PM
F972275: 图片.png
Oct 22 2020, 6:16 PM
"Like" token, awarded by jack9603301."Like" token, awarded by Georgiy-Tugai."Like" token, awarded by yog.


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.

Example config file:

# These servers were defined in the installation:
pool iburst
pool iburst
pool iburst
pool 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).

# 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.

# 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 2001:db8::/32


Difficulty level
Normal (likely a few hours)
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

图片.png (754×1 px, 114 KB)

图片.png (499×1 px, 60 KB)

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.

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 (
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


图片.png (754×1 px, 114 KB)

图片.png (499×1 px, 60 KB)

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.

c-po triaged this task as Wishlist priority.
c-po changed Difficulty level from Unknown (require assessment) to Normal (likely a few hours).

Change Summary

  • Replace ntpd with chrony
  • Move CLI from "system ntp" -> "service ntp"
  • Drop NTP server option preempt as not supported by chrony

I believe this change had an unintended side effect:

$ show ntp system
506 Cannot talk to daemon

$ show version
Version: VyOS 1.4-rolling-202301151434
Release train: current

Built by: [email protected]
Built on: Sun 15 Jan 2023 14:34 UTC
Build UUID: 0b5a5058-ba0b-4a31-a6ce-81eb91b1107b
Build commit ID: a7ab213d74e4f1

Architecture: x86_64
Boot via: installed image
System type: KVM guest

Hardware vendor: QEMU
Hardware model: Standard PC (i440FX + PIIX, 1996)
Hardware S/N:
Hardware UUID: c853f94e-bed9-460e-804e-041facee7e76

Copyright: VyOS maintainers and contributors

Discovered a couple of problems with chrony using the existing CLI.

bindaddress has the following note in documentation:

Currently, for each of the IPv4 and IPv6 protocols, only one bindaddress directive can be specified. Therefore, it is not useful on computers which should serve NTP on multiple network interfaces.

binddevice also has the following:

The binddevice directive binds the NTP and NTS-KE server sockets to a network device specified by the interface name. This directive can specify only one interface and it is supported on Linux only.

Both listen-address and interface nodes in VyOS are multi value nodes, chrony will only use the first value of each node.