[Bug 1278359] Re: ntpdate call frequency

[C de-Avillez]

* "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

-- 
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to ntp in Ubuntu.
https://bugs.launchpad.net/bugs/1278359

Title:
  ntpdate call frequency

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ntp/+bug/1278359/+subscriptions