[systemd-devel] [PATCH] timedated: add configure option to set name of controlled NTP service

[Marcel Holtmann]

Hi Miroslav,

>>> To have timedated/timedatectl managing the right NTP service on
>>> distributions like Fedora.
>> 
>> I don't really think that timedated should manage an NTP server like
>> ntpd/chrony. 
> 
> I'm talking about NTP clients, not servers. Writing a good NTP client
> is the difficult part, making server from a client is just a matter of
> binding a socket to port 123 and replying to the requests with current
> time. Anyway, chronyd doesn't reply to NTP requests by default, so
> think of it as an NTP client in this context.

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.

>> timedated's primary job is to be a service to GNOME and
>> other DEs. But if an admin wants to upgrade to a full NTP server, then
>> he should really enable/disable that with "systemctl" or a similar
>> command.
> 
> Distributions usually have a full NTP client installed by default, why
> should GNOME try to enable/disable an SNTP client that happens to be
> distributed with systemd?

And that is the part that really needs to change. 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.

>> The code wasn't wrong for what it was supposed to do. We just didn't
>> think the complexity of it would be appropriate.
> 
> Ok, this patch to make it configurable at compilation time is
> extremely simple and there is zero runtime cost, so there should be no
> problem in including it, or not?
> 
>>> If your suggestion is to use timesyncd by default on all systems
>>> where systemd is included, that might not work. Even if you don't care
>>> much about accuracy, stability or monotonicity of the system clock,
>> 
>> I don't see why timesyncd would be any different regarding monotonicity
>> that chrony would...
> 
> After start chronyd uses only slewing to correct the clock, but timesyncd
> seems to step the clock when the offset is larger than 0.4 second and
> is not a spike. With an intermittent or congested internet connection
> suffering from bufferbloat it's pretty easy to get offsets larger than
> that.

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.

>>> there is a problem with reliability. As timesyncd currently implements
>>> only SNTP and not full NTP client, it doesn't compare times from
>>> multiple servers, so it can't know when a server is broken and another
>>> should be selected instead.
>> 
>> Well, if we start comparing features, then there's also some stuff that
>> timesyncd can do that chrony can't (such as getting NTP server info from
>> DHCP networkd, or support for offline clock monotonicity of RTC-less
>> systems). 
> 
> Ok, chronyd is usually used with NetworkManager and it relies on a
> dispatcher script to get the servers from DHCP. Adding support to get
> them from networkd doesn't sound like a very difficult task if it's
> needed. Or could be networkd modified to write the list of the servers
> to a file so any NTP client could use it?
> 
> As for systems without RTC, chronyd now has an option to restore the
> time similarly to the fake-hwclock script from Debian.

If you ever tried to control a NTP client from the network managing daemon, then you would realize that this is all not designed to be controlled by any form of automated system or desktop environments like Gnome.

Chrony and ntpd are for system administrators and systems that run with a basically static configuration in a datacenter. If you are thinking they are for anything else than you are kidding yourself. And that is exactly the point here. If you install a full blown high accuracy NTP client, then you know what you are doing and you know why you are doing it.

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. If you want to see a popular one then take a look at the Nest Labs thermostat.

Regards

Marcel