Ubuntu will use ntpd-rs (and benchmark it against chrony)

Hi all, this is my first post in this community. I am running an little IPv6 openwrt router with chrony as time server on a low level traffic setting (I have no idea if its adress is linked to my profile). Now I read an announcement and wanted to share it:

Ubuntu will use ntpd-rs in future and they want to improve it. Additionally they want to benchmark it against chrony. Sounds interesting.

  • Benchmarking & Testing: Comprehensive benchmarking of long-term memory, CPU usage, and synchronization performance against chrony to give our cloud partners and enterprise users complete confidence in the transition.

Is there a list of public NTP servers running ntpd-rs?

I tried ntp-rs. Not feature compatible with chrony or ntpd for a server. Might be good enough for a client.

To be honest, I read this german newsticker which has an english translation. They state they want to improve ntpd-rs, so maybe it will be feature compatible in future, uniting NTP, NTS and PTP under one roof. High claims, though. At least this means active development and given that ubuntu is a bigger player, this cannot be bad for the ntp protocol itself, can it? OK, they did things like snap and so… but let’s be optimistic.

I used to run one on one of my few IPv4-only servers. My IPv6-enabled servers typically have multiple IPv6 addresses, a primary, often “native” one (e.g., stably autogenerated via SLAAC), and a “vanity” one for the NTP service. That multi-homing scenario is not supported today (as also mentioned in the announcement), which to me severely limits the current usefulness as server in “production” environments.

It did not have something like the iburst option, so after each restart, it took quite a while to reach the synchronized state. It often had trouble synchronizing at all, even with enough samples (admittedly in a challenging zone, though). Neither is helpful in a server role.

From pool monitoring perspective, time stability did seem less good than established alternatives, but again, might have been skewed by the zone it was in being a bit challenging in general.

My interest is not so much in the low-level timekeeping behavior, rather in the overall system and network architecture, so I didn’t do any systematic performance investigation of this implementation. If interested, I could set up an IPv4-only server in the US zone for someone else to run tests against.