On Thu, Oct 09, 2014 at 05:46:19PM +0200, Lennart Poettering wrote: > On Thu, 09.10.14 13:45, Miroslav Lichvar (mlichvar@xxxxxxxxxx) 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 Which major operating systems do use by default a SNTP client with pool.ntp.org? Microsoft and Apple use SNTP, but they have their own trusted NTP servers. In the Linux world, I think the most popular choice is the reference NTP implementation and on smaller devices it's the busybox NTP client. > and if people really care they can install a full > NTP implementation easily. Most people don't understand how NTP works and what it needs to do to work reliably. Most people also don't know much about filesystems, so for default installations we choose one that has journaling, has features we need, is reliable and performs well, not the simplest one, even if it can be good enough in some situations. > But somehow I have the suspicion that > people who need this extra resiliance would probably run PTP or > something like that anyway. PTP is actually worse than NTP in this respect as there is only one master, which is selected by a fixed algorithm (BMC) and slaves don't have a choice. The main advantage of PTP over NTP is hardware support in network cards, which eliminates most of the jitter and allows submicrosecond accuracy. > And if this is about security: neither NTP nor SNTP really can > guarantee anything there. NTP has authentication mechanisms for that. With pool.ntp.org that would not be very useful, however, as anyone could join it and serve false timestamps. > > - 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. When the network is congested, the offset can easily reach the threshold (0.4 second) and timesyncd will step the clock by the adjtimex(ADJ_SETOFFSET) call. When the network is good again, timesyncd will measure an opposite offset and step the clock back to where it was before. People with slow ADSL often complain about this with ntpd. There is an option to handle this better (the huff-n'-puff filter), but it's not enabled by default as it makes things worse in normal conditions. chronyd doesn't use the PLL, so it can simply drop the measurements and drift through. Also, it controls the frequency of the clock directly and can correct any offset by slewing. > 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. chronyd can do that too and even more, it can compensate for the RTC drift. > 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. The clock is initialized from the RTC or the save file, but it's not set from NTP yet, so the daemons started later can still observe a step backwards. With chronyd, you can use the chrony-wait service or block start of the chronyd service by using the initstepslew directive in chrony.conf to guarantee services started later won't see any steps. > I wasn't aware though that chrony and NM were integrated like that? > What interface is used there? There is an NM dispatcher script which calls the chrony dhclient script, which uses chronyc to configure chronyd with the server from DHCP. For ntpd there is a similar script. Not very elegant, but it works. > 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. Ok, I'm interested in how it will compare to ptp4l from linuxptp. > 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. That sounds interesting. I'm not sure if this was already fixed, but the last time I was testing timesyncd I noticed it was woken up due to updates from systemd-networkd every few seconds, even when there were no interesting changes in the network configuration. > So, anyway, I am pretty sure that timesyncd at least in the middle > term is the way to go for all clients. If you can show timesyncd is better than chronyd in the typical use cases, I will be ok with that. Switching to something worse probably wouldn't make much sense to me. -- Miroslav Lichvar -- desktop mailing list desktop@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/desktop
