On Thu, 09.10.14 13:45, Miroslav Lichvar (mlichvar@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