On Thu, Oct 09, 2014 at 05:46:19PM +0200, Lennart Poettering wrote:
On Thu, 09.10.14 13:45, Miroslav Lichvar (mlichvar(a)redhat.com)
> - 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
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
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
would not be very useful, however, as anyone could join it and serve
> - no guarantees on monotonicity of the clock, time jumping back
> 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
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
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
I wasn't aware though that chrony and NM were integrated like
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
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
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.