On Tue, Aug 26, 2014 at 02:21:10PM +0200, Lennart Poettering wrote: > On Tue, 26.08.14 11:41, Miroslav Lichvar (mlich...@redhat.com) wrote: > > 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. > 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? > 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. > > 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. > > When the client is configured to use just one trusted NTP server, > > that's ok. However, when public servers are used, a full NTP client is > > preferred to avoid tracking a server whose clock is completely off or > > is too slow/fast and is being periodically reset. > > Well, I don't see why a Linux client should implement a full NTP server > if no other OS does that... Vendors of other systems (at least Apple and Microsoft) can afford to run their own NTP servers. SNTP is probably good enough for them. > This is really about being a *client*, and > not trying to outsmart servers. Outsmart servers how exactly? > > You may want to consider getting a vendor zone for systemd at > > pool.ntp.org and use it in the default list instead (after making sure > > there are no problems with frequent polling, etc.). > > we are not a vendor, as we don't really do products. Vendors may use > systemd to build a product, but in that case they should use > --with-ntp-servers= and set their own NTP servers of choice... Did you ask them? I think they would be ok with systemd having its own vendor zone, systemd is not that far to be considered a Linux distribution. :) -- Miroslav Lichvar _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel