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

[Marcel Holtmann]

Hi Miroslav,

>> 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
> send patches. 

for a desktop environment like Gnome, yes timesyncd is already a huge step into the right direction. The integration with networkd or any kind of network management software is a huge advantage. Especially if you are looking at mobile devices like phones and laptops.

>> 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 under sampled.

The question is what costs to be aware of network states. So first of all you need to watch operational states and do that correctly. Then you need to understand routing tables to see if you can actually get anywhere. Then you need to know if you can resolve addresses. If you are on a per interface level, then you need to know which DNS servers are valid for that interface. Not all DNS servers are valid for each interface. At the end of the day anything else other than timesyncd would need to duplicate a lot of functionality that is in networkd and resolved.

And I think that is precisely the point here. If you are in a datacenter, and you need Chrony or ntpd level of NTP time synchronization, then just install it. Otherwise let the desktop run SNTP via timesyncd.

>> 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.

If you are in the datacenter, by all means, try to be as smart as you want to be. However bothering the general user with this is just crazy stuff. And if you think that networkd, resolved, timedated and timesyncd are doing anything new, then you are pretty much mistaken. We have been through this with ConnMan a few years back already. All of this needs to be tightly integrated.

So this means that you get a really good basis where clocks are synchronized. If you want something better, you can install it. It is a waste of time trying to integrate anything else than timesyncd since if you use anything else, you will manually configure it and use its advanced options. If you do not need the advanced features, then why install other NTP clients in the first place.

>> 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.

ConnMan is a single daemon solution doing NTP, DHCP and DNS all in one place. Any sort of callouts are costing time. And that is time that has a visible user impact. There is nothing that justifies to have a bit more nanosecond accuracy of synchronized time than making the user wait for extra milliseconds to get their network connection and time.

You might realize that a theme shows up here. If you are building a server, then by all means install ntpd or Chrony and configure it. You are the admin, you know what you are doing. If you do not know what are doing or do not care, then keep it simple.

Regards

Marcel