ntpdate call frequency

[itzeme]

Currently ntpdate is started every time the network interface changes to up.
On systems that have a hardware clock this is not nessesary, causeing unnessesary traffic and load on ntp servers.

If easily possible ntpdate shold rather be called daily or weekly via cron, if there is a hardware clock present.

(affects all Ubuntu versions)

[Robie Basak (racb)]

Thank you for taking the time to report this bug and helping to make Ubuntu better.

I recently dealt with this area of ntpdate's operation.

> On systems that have a hardware clock this is not nessesary, causeing unnessesary traffic and load on ntp servers.

Can you quantify this, please? I believe this functionality was added on that basis that network interfaces are brought up only infrequently.

I don't think it is appropriate for Ubuntu to differ from Debian on the behaviour here. Please can you seek the opinion of the Debian ntp maintainers in this area and petition for a change there instead? Ubuntu will then sync or merge any changes made in Debian.

See this Debian bug in a related area: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=731352

As this bug describes behaviour that is by design, and I believe that your "unnecessary traffic and load" presents no significant impact to a majority of Ubuntu users, I'm marking this bug as Importance: Low. I don't think this bug will make any progress in Ubuntu without consensus from Debian ntp maintainers.

[itzeme (launchacc)]

I agree.
Regarding the aspect that most systems will be booted only once a day or less it will probably affect only a few people as it is.

[C de-Avillez (hggdh2)]

I cannot see how making time sync calls even more sparse would not cause even more drift.

ntpdate is obsolete. I am not even sure why we still deploy it instead of ntp. Inertia, perhaps?

But this would not solve your issue: the replacement, be it NTP or openntpd, or whatever, still needs to keep the clock synchronised, so would still need to call NTP lock servers every so often. How often will depend, specifically, on the quality of your computer's RTC, and the importance you give to clock synchronisation. I do not think, in general, once per day is good enough. I think -- depending on the quality of your RTC -- from around one hour to, perhaps, a few hours would be good enough. If your RTC is so bad you need a sync call every few minutes, better get a more reliable machine. Certainly, and never, more than a day.

My personal view, and problem I see on using ntpdate, is actually the opposite of yours: I think ntpdate does NOT maintain clock synchronisation. Granted, it *does* sync the RTC at network up. Then, the RTC will slowly but surely drift. Given machines that more and more stay powered on & connected, one sync per network up is NOT enough. Instead, we should move to ntp or openntpd.

[itzeme (launchacc)]

Regarding the choice between ntp and ntpdate, I suspect that ntpdate is a smaller package then ntp. Even if configurable as client, ntp still also is a server package. I do not know for sure but this might be the reason behind the use of ntpdate.

To raise the sync frequency to several times a day does not seem like a good Idea to me, nor does it really seem necessary as most systems will only suffer minor time fluctuations. If you or anyone needs to sync more often then once per network up I think you should use an individual configuration that applies to your needs.

The number of systems that will suffer major time differences is probably very small, even a raspberry pi which does not even have a hardware clock, keeps an acurate time for weeks.

Considering that most desktop systems will be booted once a day or every few days, this seems a good configuration as it is.

To solve this issue for more individual needs, it might be a good idea to create an option in the ntp (or ntpdate) configuration file, that defines to sync frequency. As far as I know this is not yet the case.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[C de-Avillez (hggdh2)]

* "Disclaimer: The functionality of this program is now available in the ntpd program. See the -q command line option in the ntpd - Network Time Protocol (NTP) daemon page." After a suitable period of mourning, the ntpdate program is to be retired from this distribution" [1]. This page was last updated on Nov 2012, but I would expect mourning to take longer.

In other words: I would not expect ntpdate to be changed.

"I suspect that ntpdate is a smaller package then ntp."

ntpdate is indeed smaller than ntp, by a factor of 10 (590k for ntp, 63k for ntpdate). Generically, both of them are small enough not to be an issue.

"ntp still also is a server package"

Yes indeed. ntp can be used as a source for clock (when you build your own stratum), or as a consumer (client). Even as a source you still need another source for clock (be it a stratum 1, or a local GPS, or whatever). In my case, I usually deploy one ntp "server" syncing to upstream strata, and all the machines in my network will sync with my ntp server (as a result there is one -- perhaps two -- ntp servers in my network, and -- except for these ntp servers -- all clock sync is local to my network.

"this might be the reason behind the use of ntpdate"

Most probably (before my time, so not really sure) ntpdate was written because (at the time) *most* non-server machines were rarely connected. So a program that could attempt time sync when the network was up again would help a lot. Of course, given the (usually) long interval between network connects, the local clock would be off by a larger margin.

Also, ntp itself lacked the ability to make large changes "instantly", like ntpdate does. This is now available, via the "-g" parameter.

As for "minor time fluctuations": well, it all depends on what you see as minor and major. You do not see clock fluctuation as major; I do not see it as minor. But it all depends if your machines are providing services or not, I guess.

"...It might be a good idea to create an option in the ntp (or ntpdate)..."

It is already there. For the poll interval, please see " Poll Interval Management" at [2]. In other words: you can manage your poll as you wish, with intervals as large as 36 hours. Of course, doing that just because one does not want " frequent" clock sync sort of throws NTP's poll management off. <shrug/>, this is an user option, and any consequences will be at the user's computer.

But, I guess, my whole issue here is that -- for me -- it does not make sense to have the ability to maintain time synced, and not use it. The cost, in terms of CPU cycles, and packets exchange is not that significant (and most probably smaller than the load of a not-simple web page).

[1] http://www.eecis.udel.edu/~mills/ntp/html/ntpdate.html
[2] http://www.eecis.udel.edu/~mills/ntp/html/assoc.html

[Ross Vandegrift (ross-kallisti)]

If ntpd is running, ntpdate should never run - doing so causes clock jumps. In Trusty, /etc/network/if-up.d/ntpdate actually stops ntpd so ntpdate can run. Debian jessie doesn't do this, so if this was from upstream, it's been fixed.

From /etc/network/if-up.d/ntpdate:
-----
if [ -e /usr/sbin/openntpd ]; then
    service='openntpd'
else
    service='ntp'
fi

invoke-rc.d --quiet $service stop >/dev/null 2>&1 || true

/usr/sbin/ntpdate-debian -s $OPTS 2>/dev/null || :

invoke-rc.d --quiet $service start >/dev/null 2>&1 || true
------

Workaround:
sudo mkdir /etc/network/if-up.d.disabled
sudo dpkg-divert --divert /etc/network/if-up.d.disabled/ntpdate --rename /etc/network/if-up.d/ntpdate

[Christian Ehrhardt  (paelzer)]

There are other bugs open to care about the two "subelements" of this bug:
1. actually on a server time shouldn't step, so (by default) it shouldn't set time via ntpdate anymore
2. even if so other than on boot it should drift instead of set time, like bug 75347 (yeah that old)

Cleaning up open bugs I'll be closing the bug as dup for the first to a patch which will discuss if we want it default-disabled.