[Bug 1278359] Re: ntpdate call frequency

2015-10-28 Thread Ross Vandegrift
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

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

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs


[Bug 1278359] Re: ntpdate call frequency

2014-05-12 Thread 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. , 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

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs


[Bug 1278359] Re: ntpdate call frequency

2014-05-08 Thread Launchpad Bug Tracker
Status changed to 'Confirmed' because the bug affects multiple users.

** Changed in: ntp (Ubuntu)
   Status: New => Confirmed

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

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs


[Bug 1278359] Re: ntpdate call frequency

2014-02-18 Thread itzeme
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.

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

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs


[Bug 1278359] Re: ntpdate call frequency

2014-02-11 Thread C de-Avillez
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.

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

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs


[Bug 1278359] Re: ntpdate call frequency

2014-02-11 Thread itzeme
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.

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

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs


[Bug 1278359] Re: ntpdate call frequency

2014-02-10 Thread Robie Basak
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.

** Bug watch added: Debian Bug tracker #731352
   http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=731352

** Changed in: ntp (Ubuntu)
   Importance: Undecided => Low

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

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs