[systemd-devel] [PATCH] timedated: add configure option to set name of controlled NTP service
mlichvar at redhat.com
Tue Aug 26 08:45:57 PDT 2014
On Tue, Aug 26, 2014 at 07:50:23AM -0700, Marcel Holtmann wrote:
> and writing a good DHCP client was supposedly also really hard.
> Guess what we have done that twice now and both of our clients are
> better than everything else out there. And guess what, we did the
> same for NTP.
Are you saying timesyncd is already better than chronyd or ntpd? In
what criteria? To me it looks like the only advantage currently is the
integration with networkd. I see some trivial bugs in the code, I'll
> Desktop systems using a high accuracy NTP client instead of just
> using SNTP is a bad idea. Especially using NTP clients that are not
> aware of network states and/or states like Hotspot portals. Or think
> about systems using 3G/LTE connections.
An NTP client can be aware of network states too, I'm not sure why
should be SNTP preferred over NTP. On mobile networks I'd probably
want to use a client that can work well with intermittent connections,
not something using the kernel PLL as it's unstable when undersampled.
> The adjtime system call is limited by the kernel and how much it can
> adjust. I do not remember that actual details, but at some point you
> are required to skip time. Trying to emulate that in userspace is a
> bad idea. Either the kernel can do it for you or you just skip to
> the next synchronized time you have.
The adjtime() offset isn't limited, but adjtimex() in PLL mode limits
the offset to 0.5 second. chronyd controls the kernel frequency
directly and if an update is late, the next correction is compensated
for that. From what I can tell it works very well.
> Even inside ConnMan, we decided to include a SNTP client directly
> into ConnMan. In earlier days, we had ConnMan controlling ntpd's
> client. Ugly and complicated and also full of race conditions. We
> looked into Chrony and it was no better at all. We tried to write
> our own SNTP client that we control and can feed DHCP information
> into it. Worked beautifully and is still in use today and actual
> consumer products.
Ok, how exactly are you feeding the NTP client? Perhaps it's something
we could use in chronyd too.
More information about the systemd-devel