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

[Marcel Holtmann]

Hi Miroslav,

>> 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 need the first clock update to happen milliseconds after the
> network is up? Seriously? I agree that's not possible with chronyd or
> ntpd even if they were listening to networkd, but I don't think it's a
> requirement on any desktop system.

start building a media client. Then you will see that the faster you have your IP address and the faster you have your clocks synchronized, the better your user experience gets. So this is all crucial.

Until we fixed DHCP, everybody was fine waiting for many seconds to get an IP address. Now you get the IP in a few 100 milliseconds. But sure, lets go back to 10 years ago where everything took forever. And lets have a boot take 10 minutes.

>> 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.
> 
> I'm not convinced. I think uninformed users should be using the best
> tool for the typical use case they have at hand.
> 
> Trading falseticker detection, stable clock control with intermittent
> connections, ability to drift through when network is congested,
> ability to deal with broken clocks (as in some virtual machines) and
> monotonic time just for a super fast update seems like a bad choice to
> me.

Seriously? That is what desktop users want. Cool, can you show me the desktop users that do care about this. I am actually curious now on how you justify doing all that with the expected battery life.

> I'm sure timesyncd will be significantly improved over time, but
> currently I'd not describe it as "more than appropriate for most
> installations".

That is the beauty of open source. If enough users care it will get added to timesyncd. So people will just start sending patches.

Regards

Marcel