Discussion:
[PATCH] timedated: add configure option to set name of controlled NTP service
(too old to reply)
Miroslav Lichvar
2014-08-21 10:49:49 UTC
Permalink
This is useful for installations where some other service than
systemd-timesyncd is used to synchronize the system clock.
---
configure.ac | 9 +++++++++
src/timedate/timedated.c | 10 +++++-----
2 files changed, 14 insertions(+), 5 deletions(-)

diff --git a/configure.ac b/configure.ac
index 18b7198..d9f95d9 100644
--- a/configure.ac
+++ b/configure.ac
@@ -948,6 +948,15 @@ if test "x$enable_timedated" != "xno"; then
fi
AM_CONDITIONAL(ENABLE_TIMEDATED, [test "$have_timedated" = "yes"])

+AC_ARG_WITH(ntp-service,
+ AS_HELP_STRING([--with-ntp-service=NTPSERVICE],
+ [NTP service controlled by timedated]),
+ [NTP_SERVICE="$withval"],
+ [NTP_SERVICE="systemd-timesyncd.service"])
+
+AC_DEFINE_UNQUOTED(NTP_SERVICE, ["$NTP_SERVICE"], [NTP service controlled by timedated])
+AC_SUBST(NTP_SERVICE)
+
# ------------------------------------------------------------------------------
have_timesyncd=no
AC_ARG_ENABLE(timesyncd, AS_HELP_STRING([--disable-timesyncd], [disable timesync daemon]))
diff --git a/src/timedate/timedated.c b/src/timedate/timedated.c
index fa3f947..cdd16e6 100644
--- a/src/timedate/timedated.c
+++ b/src/timedate/timedated.c
@@ -198,7 +198,7 @@ static int context_read_ntp(Context *c, sd_bus *bus) {
&error,
&reply,
"s",
- "systemd-timesyncd.service");
+ NTP_SERVICE);

if (r < 0) {
if (sd_bus_error_has_name(&error, SD_BUS_ERROR_FILE_NOT_FOUND) ||
@@ -236,7 +236,7 @@ static int context_start_ntp(Context *c, sd_bus *bus, sd_bus_error *error) {
error,
NULL,
"ss",
- "systemd-timesyncd.service",
+ NTP_SERVICE,
"replace");
else
r = sd_bus_call_method(
@@ -248,7 +248,7 @@ static int context_start_ntp(Context *c, sd_bus *bus, sd_bus_error *error) {
error,
NULL,
"ss",
- "systemd-timesyncd.service",
+ NTP_SERVICE,
"replace");

if (r < 0) {
@@ -282,7 +282,7 @@ static int context_enable_ntp(Context*c, sd_bus *bus, sd_bus_error *error) {
error,
NULL,
"asbb", 1,
- "systemd-timesyncd.service",
+ NTP_SERVICE,
false, true);
else
r = sd_bus_call_method(
@@ -294,7 +294,7 @@ static int context_enable_ntp(Context*c, sd_bus *bus, sd_bus_error *error) {
error,
NULL,
"asb", 1,
- "systemd-timesyncd.service",
+ NTP_SERVICE,
false);

if (r < 0) {
--
1.9.3
Lennart Poettering
2014-08-26 01:27:10 UTC
Permalink
Post by Miroslav Lichvar
This is useful for installations where some other service than
systemd-timesyncd is used to synchronize the system clock.
What's the rationale here?

We recently removed support for configuring arbitrary NTP servers from
timedated, see b72ddf0f4f552dd53d6404b6ddbc9f17d02b8e12. YOu patch would
undo this change, but in a very limited way...

We decided to make timedated only manage timesyncd and nothing else, and
treat all other NTP servers as real servers that when installed and
enabled replace timesyncd. Hence: every other NTP server should really
take precedence over timesyncd, but only timesyncd is managable via
timedated. This sounds like the right thing to do, after all timesyncd
is really the simplest option to run for clients, and hence really is
what should be managed by GNOME.

Hope that makes some sense,

Lennart
--
Lennart Poettering, Red Hat
Miroslav Lichvar
2014-08-26 09:41:42 UTC
Permalink
Post by Lennart Poettering
Post by Miroslav Lichvar
This is useful for installations where some other service than
systemd-timesyncd is used to synchronize the system clock.
What's the rationale here?
To have timedated/timedatectl managing the right NTP service on
distributions like Fedora.
Post by Lennart Poettering
We recently removed support for configuring arbitrary NTP servers from
timedated, see b72ddf0f4f552dd53d6404b6ddbc9f17d02b8e12. YOu patch would
undo this change, but in a very limited way...
Yes, it's meant to be a cheap replacement for the removed functionality.
Perhaps I could prepare something better if I knew what exactly was
wrong with the old code.
Post by Lennart Poettering
We decided to make timedated only manage timesyncd and nothing else, and
treat all other NTP servers as real servers that when installed and
enabled replace timesyncd. Hence: every other NTP server should really
take precedence over timesyncd, but only timesyncd is managable via
timedated.
The problem is timedated doesn't see or control the other NTP service.
It may report the "NTP enabled" status incorrectly and "set-ntp false"
may not actually disable NTP. Enabling NTP starts timesyncd, but after
reboot there is the other NTP service running again. This is
confusing.
Post by Lennart Poettering
This sounds like the right thing to do, after all timesyncd
is really the simplest option to run for clients, and hence really is
what should be managed by GNOME.
I think GNOME should be managing the NTP service which is normally
used on the system, i.e. chronyd on Fedora.

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

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.

BTW, is there an agreement with Google on using their NTP servers?
Lennart Poettering
2014-08-26 12:21:10 UTC
Permalink
Post by Miroslav Lichvar
Post by Lennart Poettering
Post by Miroslav Lichvar
This is useful for installations where some other service than
systemd-timesyncd is used to synchronize the system clock.
What's the rationale here?
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. 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.

The idea is that timesyncd is the default, and what the DEs control. But
if the admin installs any othr package, then that takes precedence.
Post by Miroslav Lichvar
Post by Lennart Poettering
We recently removed support for configuring arbitrary NTP servers from
timedated, see b72ddf0f4f552dd53d6404b6ddbc9f17d02b8e12. YOu patch would
undo this change, but in a very limited way...
Yes, it's meant to be a cheap replacement for the removed functionality.
Perhaps I could prepare something better if I knew what exactly was
wrong with the old code.
The code wasn't wrong for what it was supposed to do. We just didn't
think the complexity of it would be appropriate.
Post by Miroslav Lichvar
Post by Lennart Poettering
We decided to make timedated only manage timesyncd and nothing else, and
treat all other NTP servers as real servers that when installed and
enabled replace timesyncd. Hence: every other NTP server should really
take precedence over timesyncd, but only timesyncd is managable via
timedated.
The problem is timedated doesn't see or control the other NTP service.
It may report the "NTP enabled" status incorrectly and "set-ntp false"
may not actually disable NTP. Enabling NTP starts timesyncd, but after
reboot there is the other NTP service running again. This is
confusing.
Well, if admins installed a full NTP server, then they should control it
with "systemctl enable" and "systemctl disable", and it should take
precedence, but "timedatectl" is really not supposed to be that.
Post by Miroslav Lichvar
Post by Lennart Poettering
This sounds like the right thing to do, after all timesyncd
is really the simplest option to run for clients, and hence really is
what should be managed by GNOME.
I think GNOME should be managing the NTP service which is normally
used on the system, i.e. chronyd on Fedora.
I disagree. GNOME is client software, timesyncd is client
software, and not more. I am really not convinced that GNOME should be a
frontend for a full NTP server suite.
Post by Miroslav Lichvar
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...
Post by Miroslav Lichvar
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). But it isn't really about that. It's really just about
whether "timedatectl" should manage arbitrary NTP serves, or just the
one minimal SNTP client that we provide.
Post by Miroslav Lichvar
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... This is really about being a *client*, and
not trying to outsmart servers.
Post by Miroslav Lichvar
BTW, is there an agreement with Google on using their NTP servers?
Well, but the pool.ntp.org site makes clear that there's no way we can
use theirs, Google at least doesn't do that, so we default to that.

The idea is actually that at configure time the distros specify which
NTP server to use by default, and use their distro-specific vendor
zone from pool.ntp.org. However I simply forgot adding that to the
configure line in the fedora package so far (note that timesyncd is very
recent addition). Or in other words: nobody should really use google's
servers in the distros. They should use their own pools.
Post by Miroslav Lichvar
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...

Lennart
--
Lennart Poettering, Red Hat
Andrei Borzenkov
2014-08-26 12:34:41 UTC
Permalink
On Tue, Aug 26, 2014 at 4:21 PM, Lennart Poettering
Post by Lennart Poettering
Post by Miroslav Lichvar
Post by Lennart Poettering
Post by Miroslav Lichvar
This is useful for installations where some other service than
systemd-timesyncd is used to synchronize the system clock.
What's the rationale here?
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. 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.
What's wrong with having standard API for querying whether NTP is
enabled on a system? Is it better if every DE has to use home-grown
checks multiplied by number of NTP implementations?
Lennart Poettering
2014-08-26 12:37:33 UTC
Permalink
Post by Andrei Borzenkov
Post by Lennart Poettering
I don't really think that timedated should manage an NTP server like
ntpd/chrony. 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.
What's wrong with having standard API for querying whether NTP is
enabled on a system? Is it better if every DE has to use home-grown
checks multiplied by number of NTP implementations?
We are simply not in that business. I mean, we don't provide the same
for HTTP implementations, FTP implementations, webdav implementations,
and so on either...

Lennart
--
Lennart Poettering, Red Hat
Simon Peeters
2014-08-26 13:56:38 UTC
Permalink
Post by Lennart Poettering
Post by Andrei Borzenkov
Post by Lennart Poettering
I don't really think that timedated should manage an NTP server like
ntpd/chrony. 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.
What's wrong with having standard API for querying whether NTP is
enabled on a system? Is it better if every DE has to use home-grown
checks multiplied by number of NTP implementations?
We are simply not in that business. I mean, we don't provide the same
for HTTP implementations, FTP implementations, webdav implementations,
and so on either...
But we do for display managers, so maybe we can go the same way here:
- have al (s)ntp clients include Alias=timesync.service
- timedated uses timesync.service for:
- checking wether ntp is enabled.
- disabling ntp if requested.
- timedated still uses systemd-timesyncd.service to enable ntp.

I think this achieves what both sides want here:
- it allows the admin to systemctl enable somentpd.service
- it is quiet minimal in changes with what we have now (except the
Alias part in all other ntp service files)
- it allows timedated to check and controll ntp even if an other ntp
server is used
(with the caveat that disable and then enable will result in
switching to systemd-timesyncd)

just my 2c, if you think it is a good way to go, i'll be happy to write a patch.


Simon
Lennart Poettering
2014-08-26 17:27:11 UTC
Permalink
Post by Simon Peeters
Post by Lennart Poettering
Post by Andrei Borzenkov
Post by Lennart Poettering
I don't really think that timedated should manage an NTP server like
ntpd/chrony. 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.
What's wrong with having standard API for querying whether NTP is
enabled on a system? Is it better if every DE has to use home-grown
checks multiplied by number of NTP implementations?
We are simply not in that business. I mean, we don't provide the same
for HTTP implementations, FTP implementations, webdav implementations,
and so on either...
- have al (s)ntp clients include Alias=timesync.service
- checking wether ntp is enabled.
- disabling ntp if requested.
- timedated still uses systemd-timesyncd.service to enable ntp.
- it allows the admin to systemctl enable somentpd.service
- it is quiet minimal in changes with what we have now (except the
Alias part in all other ntp service files)
- it allows timedated to check and controll ntp even if an other ntp
server is used
(with the caveat that disable and then enable will result in
switching to systemd-timesyncd)
just my 2c, if you think it is a good way to go, i'll be happy to write a patch.
I am not too convinced about this idea, since the semantics are too
different. I mean, timesyncd is something that actually can run in early
boot which the implementations really can't. If we have a generic name
for this then people might end up depending on it, which will usually
work on timesyncd, but will have completely different semantics on other
implementations...

I think we should simply document for timedatectl that it controls
timesyncd, so that people can easily find that.

(Also, we currently don't allow disabling units via their alias, only
via their main name, so it's not that easy...)

Lennart
--
Lennart Poettering, Red Hat
Miroslav Lichvar
2014-08-26 13:44:58 UTC
Permalink
Post by Lennart Poettering
Post by Miroslav Lichvar
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.
Post by Lennart Poettering
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?
Post by Lennart Poettering
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?
Post by Lennart Poettering
Post by Miroslav Lichvar
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.
Post by Lennart Poettering
Post by Miroslav Lichvar
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.
Post by Lennart Poettering
Post by Miroslav Lichvar
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.
Post by Lennart Poettering
This is really about being a *client*, and
not trying to outsmart servers.
Outsmart servers how exactly?
Post by Lennart Poettering
Post by Miroslav Lichvar
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
Marcel Holtmann
2014-08-26 14:50:23 UTC
Permalink
Hi Miroslav,
Post by Miroslav Lichvar
Post by Lennart Poettering
Post by Miroslav Lichvar
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.
Post by Miroslav Lichvar
Post by Lennart Poettering
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.
Post by Miroslav Lichvar
Post by Lennart Poettering
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?
Post by Lennart Poettering
Post by Miroslav Lichvar
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.
Post by Miroslav Lichvar
Post by Lennart Poettering
Post by Miroslav Lichvar
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
Miroslav Lichvar
2014-08-26 15:45:57 UTC
Permalink
Post by Marcel Holtmann
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.
Post by Marcel Holtmann
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.
Post by Marcel Holtmann
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.
Marcel Holtmann
2014-08-26 16:08:47 UTC
Permalink
Hi Miroslav,
Post by Miroslav Lichvar
Post by Marcel Holtmann
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.
Post by Miroslav Lichvar
Post by Marcel Holtmann
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.
Post by Miroslav Lichvar
Post by Marcel Holtmann
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.
Post by Miroslav Lichvar
Post by Marcel Holtmann
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
Miroslav Lichvar
2014-08-27 09:48:01 UTC
Permalink
Post by Marcel Holtmann
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.
Post by Marcel Holtmann
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.

I'm sure timesyncd will be significantly improved over time, but
currently I'd not describe it as "more than appropriate for most
installations".
--
Miroslav Lichvar
Marcel Holtmann
2014-08-27 16:22:10 UTC
Permalink
Hi Miroslav,
Post by Miroslav Lichvar
Post by Marcel Holtmann
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.
Post by Miroslav Lichvar
Post by Marcel Holtmann
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.
Post by Miroslav Lichvar
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

Lennart Poettering
2014-08-26 17:19:01 UTC
Permalink
Post by Miroslav Lichvar
Post by Marcel Holtmann
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.
First of all, tiemsyncd is *very* new. timesyncd is supposed to be a
minimal client side SNTP implementation. It's not suitable for
super-accurate industrial time-keeping or anything like that, but it is
simple, minimal, and supposed to *just work*. It focusses strictly on the
client side of things, and doesn't lose itself in details RTC skews and
whatnot. It's supposed to cover the 90% that the vast majority of
devices need, and for the rest of 10% we want it to easily be replacable
with a full NTP server solution. It's not supposed to be a fancy project
of its own, it's supposed to just be that bit that is there, and is good
enough, and unless you really need super-high precision there you don't
need to install any additional package.
Post by Miroslav Lichvar
I see some trivial bugs in the code, I'll send patches.
Thanks, please do! Appreciated!

Lennart
--
Lennart Poettering, Red Hat
Andrei Borzenkov
2014-08-26 17:44:58 UTC
Permalink
В Tue, 26 Aug 2014 19:19:01 +0200
Post by Lennart Poettering
Post by Miroslav Lichvar
Post by Marcel Holtmann
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.
First of all, tiemsyncd is *very* new. timesyncd is supposed to be a
minimal client side SNTP implementation. It's not suitable for
super-accurate industrial time-keeping or anything like that, but it is
simple, minimal, and supposed to *just work*. It focusses strictly on the
client side of things, and doesn't lose itself in details RTC skews and
whatnot. It's supposed to cover the 90% that the vast majority of
devices need, and for the rest of 10% we want it to easily be replacable
with a full NTP server solution. It's not supposed to be a fancy project
of its own, it's supposed to just be that bit that is there, and is good
enough, and unless you really need super-high precision there you don't
need to install any additional package.
I suspect part of confusion stems from the fact that timedatectl states
"NTP is enabled", while it actually means "timesyncd is enabled". For
me "NTP enabled" really implies something different from "running sntp
client periodically". Rephrasing it as "time synchronization is
enabled" and "time synchronized" would convey the same information
without implying anything about implementation.
Lennart Poettering
2014-08-26 17:10:13 UTC
Permalink
Post by Miroslav Lichvar
Post by Lennart Poettering
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?
Well, "usually" means right *now*, little else.

But quite frankly, we added timesyncd because we believe that installing
a full DNS server like ntpd/chrony on all client machines is absolute
overkill, but we believe that something fixing up the clock basically
needs to be installed on every system, even the most trivial ones,
embedded ones, and clients. And for all of those a minimal SNTP client
like timesyncd sounds absolutely appropriate.

If Fedora decides to install chrony/ntp by default, then that's totally
OK, but that's a Fedora decision, but it doesn't need to be something we
explicitly support with the highest possible integration in system
upstream.
Post by Miroslav Lichvar
Post by Lennart Poettering
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?
No. We don't add configuration options for a thousand different
things. This is really not something I want to see in systemd upstream.
Post by Miroslav Lichvar
Post by Lennart Poettering
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?
Sure, we have an C API for this already, which allows subscribing to NTP
servers coming and going, but we are not exporting that yet, since we
don't want to make any API stability guarantees yet.
Post by Miroslav Lichvar
Post by Lennart Poettering
This is really about being a *client*, and
not trying to outsmart servers.
Outsmart servers how exactly?
By not trusting them...
Post by Miroslav Lichvar
Post by Lennart Poettering
Post by Miroslav Lichvar
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. :)
We don#t want to be a vendor, we don't want to be a product, and hence
we don't want a vendor zone. Distros need to take the responsibility for
this, not us....

If it makes you happy, then I can add a big warning to configure, if
people build things and don't specify their own NTP servers...

Lennart
--
Lennart Poettering, Red Hat
Marco d'Itri
2014-08-26 17:32:26 UTC
Permalink
Post by Lennart Poettering
If it makes you happy, then I can add a big warning to configure, if
people build things and don't specify their own NTP servers...
The history is full of people who got burned by using somebody's else
NTP servers without permission, so unless Google will give an explicit
permission to use their server I urge you to remove this default.
--
ciao,
Marco
Continue reading on narkive:
Loading...