NTP switch in gnome-control-center is broken

[Lennart Poettering]

On Thu, 09.10.14 13:45, Miroslav Lichvar (mlichvar at redhat.com) wrote:

> - reliability, timesyncd is an SNTP client and not a full NTP client,
>   it doesn't compare data from multiple serverss, so it's not able to
>   detect broken servers and will blindly follow almost any reply

Well, while it is certainly nice to be resiliant to such things, I am
not convinced though that for a normal client this is really a
necessity. The commonly used NTP servers are good enough for most
cases and are used in SNTP mode by a multitude of devices and
operating systems, and if people really care they can install a full
NTP implementation easily. But somehow I have the suspicion that
people who need this extra resiliance would probably run PTP or
something like that anyway.

And if this is about security: neither NTP nor SNTP really can
guarantee anything there.

> - no guarantees on monotonicity of the clock, time jumping back and
>   forth with network connections suffering from bufferbloat

Well, that's not precisely true. There's a threshold in place, to use
clock_settime() instead of the PLL if the time difference is too
large. But as long as the network is not completely borked we should
easily stay below that threshold, especially since the measurements
are actually filtered for spikes before we pass them into the PLL. Only
if a continuous stream of bogus measurements is collected the PLL
might be trashed, but even that will not cause time to go backwards...

Also note that timesyncd saves and restores the clock on disk, to
improve behaviour on RTC-less devices, and keep the clock monotonic
even for them. Since it may run during early boot (in contrast to
chrony) it will actually apply this during early boot, so that normal
daemons will never see an uninitialized clock.

> - no integration with NetworkManager, unaware of NTP servers from
>   DHCP

Well it is not hooked up with NM but it *is* hooked up with networkd
via its native API, and hence even picks up manually configured
per-connection NTP servers.

I wasn't aware though that chrony and NM were integrated like that?
What interface is used there?

> - dependency on systemd-networkd, which is not enabled by default

There is no hard dependency. If you run both in conjunction, then
timesyncd will pick up the DHCP supplied NTP servers, and the ones
explicitly configured in the network configuration. If you don't run
them in conjunction both will work fine independently.

In general: we try to make timesyncd a good *client* for NTP, and
focus on that. Unlike ntpd or chrony it will not accept NTP requests,
it will not contain drivers for hardware clocks. timesyncd is supposed
to be a generic daemon for everything the 99% of devices that just
need correct time, and nothing more.

In this light our plans are actually to add a minimal PTP client as
well, that is supposed to just work, if PTP is supported on a
LAN. Also, in contrast to ntpd we really want to make sure to optimize
timesyncd for power management, and reduce wakeups. In fact, we are
looking to syncing about the NTP syncs to wakeups of the network hw,
so that we never end up waking up hardware for the clock.

So, anyway, I am pretty sure that timesyncd at least in the middle
term is the way to go for all clients.

Lennart

-- 
Lennart Poettering, Red Hat