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

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

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

In T3008#78303, @jack9603301 wrote:

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.

Draft PR https://github.com/vyos/vyos-1x/pull/1758

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.