"ntpd -q" is slow compared to ntpdate
Mohit Aron
I've ready in numerous places that ntpdate is going to be deprecated and
that one should use 'ntpd -q -g' instead. I have also read complaints by
people that 'ntpd -q -g' is slow, but I haven't read about any suitable
resolution to this issue. My own system uses 'ntpd -q -g' to synchronize
with an Internal time server and the call to 'ntpd -q -g' takes more than 3
minutes to complete. This slows up the startup of my machine.
Here's the /etc/ntp.conf of my client machine (where the our local ntp
server has the IP 10.50.33.100):
logfile /var/log/ntp.log
driftfile /var/log/ntp.drift
restrict default notrust nomodify notrap noquery
restrict 10.50.33.100
restrict 127.127.1.0
server 10.50.33.100 iburst minpoll 4
server 127.127.1.0
fudge 127.127.1.0 stratum 11
I also ran a tcpdump to capture the ntp packets being exchanged between the
client and the server. It seems the client sends a total of 13 requests to
the server - each of which is responded to immediately. The first 9 requests
are spaced at period of 2 seconds each. The 10th one is sent one second
after the 9th request. The 11th one is sent 18s after then 10th. The 12th
one is sent 65 seconds after the 11th. Finally, the 13th one is sent 66s
after the 12th one. Personally, I would have been extremely happy if 'ntpd
-q -g' terminated after the first request was sent and the reply was
received.
Issuing 'ntpdate 10.50.33.100' completes almost instantaneously. Before the
ntp maintainers deprecate ntpdate, it would be wise to provide the
equivalent functionality in ntpd. The current speed of 'ntpd -q -g' is
unacceptably slow. I think it is also unwise to mention in the docs (e.g.,
the man page) that ntpdate is deprecated without providing equivalent
functionality. I've wasted a lot of time configuring our machines to use
'ntpd -q -g' and now all that needs to be reverted back to use ntpdate. If
ntpdate is indeed removed from a later ntp release, I'd have to just compile
ntpdate from an older source version rather than use the dog slow 'ntpd -q
-g' command.
- Mohit
Unruh
>Hello,
>I've ready in numerous places that ntpdate is going to be deprecated and
>that one should use 'ntpd -q -g' instead. I have also read complaints by
That does not help if the time difference is less than 128ms, as then ntp
will simply use its algorithm ( which is very slow) to get the right time.
But why in the world are you using the -q? Just let ntpd run and discipline
your clock! Why in theworld do you want it to exit?
>people that 'ntpd -q -g' is slow, but I haven't read about any suitable
>resolution to this issue. My own system uses 'ntpd -q -g' to synchronize
>with an Internal time server and the call to 'ntpd -q -g' takes more than 3
What internal time server?
>minutes to complete. This slows up the startup of my machine.
????? what are you doing?
>Here's the /etc/ntp.conf of my client machine (where the our local ntp
>server has the IP 10.50.33.100):
>logfile /var/log/ntp.log
>driftfile /var/log/ntp.drift
>restrict default notrust nomodify notrap noquery
>restrict 10.50.33.100
>restrict 127.127.1.0
You have this localclock why? It is idiotic, doubly so because of the way
you are using ntp. What the hell are are telling you machine it can use
itself as a time source for?
>server 10.50.33.100 iburst minpoll 4
>server 127.127.1.0
>fudge 127.127.1.0 stratum 11
>I also ran a tcpdump to capture the ntp packets being exchanged between the
>client and the server. It seems the client sends a total of 13 requests to
>the server - each of which is responded to immediately. The first 9 requests
>are spaced at period of 2 seconds each. The 10th one is sent one second
>after the 9th request. The 11th one is sent 18s after then 10th. The 12th
>one is sent 65 seconds after the 11th. Finally, the 13th one is sent 66s
>after the 12th one. Personally, I would have been extremely happy if 'ntpd
>-q -g' terminated after the first request was sent and the reply was
>received.
And I have absolutely no idea what you are trying to do.
>Issuing 'ntpdate 10.50.33.100' completes almost instantaneously. Before the
>ntp maintainers deprecate ntpdate, it would be wise to provide the
>equivalent functionality in ntpd. The current speed of 'ntpd -q -g' is
>unacceptably slow. I think it is also unwise to mention in the docs (e.g.,
>the man page) that ntpdate is deprecated without providing equivalent
>functionality. I've wasted a lot of time configuring our machines to use
>'ntpd -q -g' and now all that needs to be reverted back to use ntpdate. If
>ntpdate is indeed removed from a later ntp release, I'd have to just compile
>ntpdate from an older source version rather than use the dog slow 'ntpd -q
>-g' command.
Perhaps you should learn to use ntp instead.
>- Mohit
Steve Kostecke
> I've ready in numerous places that ntpdate is going to be deprecated
> and that one should use 'ntpd -q -g' instead. I have also read
> complaints by people that 'ntpd -q -g' is slow, but I haven't read
> about any suitable resolution to this issue. My own system uses 'ntpd
> -q -g' to synchronize with an Internal time server and the call to
> 'ntpd -q -g' takes more than 3 minutes to complete.
In my tests 'ntpd -gq' takes all of 11 seconds to run with an ntp.conf
which just specifies a time server on the LAN.
>This slows up the startup of my machine.
If you don't need to block the boot process while the clock is initially
set there is no need to use 'ntpq -gq'. Starting ntpd with '-g' is
enough to ensure that the time will be set correctly no matter how far
off the system clock may be.
> Here's the /etc/ntp.conf of my client machine (where the our local ntp
> server has the IP 10.50.33.100):
Reordered for clarity ...
> logfile /var/log/ntp.log
> driftfile /var/log/ntp.drift
> restrict default notrust nomodify notrap noquery
>
> server 10.50.33.100 iburst minpoll 4
> restrict 10.50.33.100
>
> server 127.127.1.0
> fudge 127.127.1.0 stratum 11
> restrict 127.127.1.0
The Undisciplined Local Clock (127.127.1.x) is not needed unless this
ntpd is serving time to others. However this has nothing to do with your
slow start-up.
> I also ran a tcpdump to capture the ntp packets being exchanged between the
> client and the server. It seems the client sends a total of 13 requests to
> the server - each of which is responded to immediately. The first 9 requests
> are spaced at period of 2 seconds each. The 10th one is sent one second
> after the 9th request. The 11th one is sent 18s after then 10th. The 12th
> one is sent 65 seconds after the 11th. Finally, the 13th one is sent 66s
> after the 12th one. Personally, I would have been extremely happy if 'ntpd
> -q -g' terminated after the first request was sent and the reply was
> received.
ntpd has to collect a certain amount of data before it will believe a
particular time source. The first volley of polls are generally more
than enough to allow ntpd to determine a close approximation of the
correct time. If the clock is more than 128ms off it will be stepped
otherwise a slew will be initiated; ntpd exits immediately after the
step or the initiation of the slew.
> Issuing 'ntpdate 10.50.33.100' completes almost instantaneously.
That's because ntpdate blindly accepts the first reply it receives.
--
Steve Kostecke <kost...@ntp.org>
NTP Public Services Project - http://support.ntp.org/
Garrett Wollman
Unruh <unruh...@physics.ubc.ca> wrote:
>extp...@gmail.com (Mohit Aron) writes:
>>I've ready in numerous places that ntpdate is going to be deprecated and
>>that one should use 'ntpd -q -g' instead. I have also read complaints by
>
>That does not help if the time difference is less than 128ms, as then ntp
>will simply use its algorithm ( which is very slow) to get the right time.
>But why in the world are you using the -q? Just let ntpd run and discipline
>your clock! Why in theworld do you want it to exit?
If you care about having reasonably correct timestamps in your logs,
you need to get a reasonably correct time established at boot time
before anything important starts. Once the system time is validated,
the rest of the system may be permitted to start, possibly including a
long-running ntpd. You don't want that initial step happening after
anything else has been started, and the only way to convey this
information to traditional /etc/rc scripts is to have the program
exit.
That is how most systems use ntpdate(1) now, and that is why
distributors are so resistant to change (the well-known problems of
ntpdate notwithstanding).
What they probably actually want is a flag that says "delay
daemonizing until the first time the clock is set".
-GAWollman
--
Garrett A. Wollman | The real tragedy of human existence is not that we are
wol...@csail.mit.edu| nasty by nature, but that a cruel structural asymmetry
Opinions not those | grants to rare events of meanness such power to shape
of MIT or CSAIL. | our history. - S.J. Gould, Ten Thousand Acts of Kindness
euge...@sbcglobal.net
Suppose you want to reduce the time offset to (nearly) zero as rapidly
as possible on start-up and this causes you to be dissatisfied with
the behavior of ntpd when it it starts up and calculates an initial
offset of slightly less than the default step threshold of 128ms. If
you run "ntpd -g" with something like "tinker step 0.001" in the
configuration file to insure that a step will occur on start-up, then
you are stuck with that step threshold indefinitely. You might want to
run ntpd twice -- the first time in "one-shot" mode with the tinker
in the config, and the second time with a different configuration file
lacking the tinker.
Gene Miller
Harlan Stenn
--
Harlan Stenn <st...@ntp.org>
http://ntpforum.isc.org - be a member!
Rick Jones
> If you care about having reasonably correct timestamps in your logs,
> you need to get a reasonably correct time established at boot time
> before anything important starts.
Would it be fair to say that "today" anyway, having the time be within
a (large fraction of a) second (IIRC that is the precision of most
system logs still today?) be sufficient?
> Once the system time is validated, the rest of the system may be
> permitted to start, possibly including a long-running ntpd. You
> don't want that initial step happening after anything else has been
> started, and the only way to convey this information to traditional
> /etc/rc scripts is to have the program exit.
And people (not just performance geeks :) are indeed concerned about
the speed at which a system is up and running. Adding minutes to that
is right out. Where in the realm of added seconds things are is a
very fertile area for discussion.
> That is how most systems use ntpdate(1) now, and that is why
> distributors are so resistant to change (the well-known problems of
> ntpdate notwithstanding).
> What they probably actually want is a flag that says "delay
> daemonizing until the first time the clock is set".
But still want things to happen "quickly" for some relative definition
of quickly that probably does not encompass the length of time most
(and I do mean the term affectionately) time geeks would wait.
rick jones
--
Process shall set you free from the need for rational thought.
these opinions are mine, all mine; HP might not want them anyway... :)
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...
Richard B. Gilbert
Much of the pain can be alleviated by not rebooting. I dunno about
Vista but W/XP can run for weeks or even months between reboots. If you
must shut down to save electricity or something, you'll just have to
start the machines a few minutes before they need to have the correct time.
Unruh
>Gene Miller
date -s "Jan 1 2000 10:15:00"
ntpd -g
should do it. the first ensures that the time is way way way off and a step
will definitely occur. The
second does a step to the correct time.
David Woolley
> Much of the pain can be alleviated by not rebooting. I dunno about
That's not a socially responsible option any longer. For many systems,
one should be doing at least suspend to disk and total power down.
David J Taylor
[]
> Much of the pain can be alleviated by not rebooting. I dunno about
> Vista but W/XP can run for weeks or even months between reboots. If
> you must shut down to save electricity or something, you'll just have
> to start the machines a few minutes before they need to have the correct
> time.
Yes, Vista is as stable as XP and can run for weeks or months at a time.
My main Vista system is usually rebooted for the monthly security updates,
though. When the systems (2000, XP and Vista) are rebooted, they come up
within a second or so of correct time simply by running NTP as a service -
no special action required. The time is correct as soon as the user logs
in.
David
euge...@sbcglobal.net
One minor addition would be required: Before executing date, the
current date/time would have to be saved. A check would have to be
made to verify that ntpd found a suitable server for sync, and if that
failed, the previous time would have to be restored.
Gene Miller
Mohit Aron
> See http://support.ntp.org/bin/view/Dev/DeprecatingNtpdate .
>
Thanks. It seems 'sntp -r <server>' is the appropriate replacement for
ntpdate.
- Mohit
Mohit Aron
questions asked by others on my original mail. It'll be great if people can
write constructively rather than using keywords like 'idiotic' etc which
serve no useful purpose and only motivate me to just ignore your email.
* There were some questions on why my ntp.conf uses the local time source
127.127.1.0. This question is irrelevant to this discussion, which focuses
on why 'ntpd -q -g' is slow. Anyways, the reason this was added was because
if the server at 10.50.33.100 is down, then we found that ntpd would hang -
but if the lines concerning 127.127.1.0 was there, the ntpd would still make
progress if the external NTP server was down.
* Someone suggested just running 'ntpd' and not the oneshot 'ntpd -q -g'.
Again, not relevant to this discussion. But the answer is that the machine
needs to start with the clock roughly synchronized - its ok to be running
'ntpd' in the background later.
* There were some questions on what I'm trying to do here. Basically we sell
a distributed platform containing multiple machines arrange in a
master-slave architecture. The slaves need to be sync'd with the master when
they start up. Slow bootup times are unacceptable - specially wasting 3
minutes just to synchronize clocks is not ok. So the slaves need to quickly
update the clock to roughly the same time as the master, and then later its
ok for them to run ntp in the background. Since this is a custom
environment, the slaves are totally willing to accept the master as the NTP
source (the master is at IP address 10.50.33.100). So there's no reason for
the ntp client at the slaves to not believe the first reply they see from
the master.
* Someone mentioned that they're seeing sync'up times of 11s with 'ntpd -q
-g'. Well, congratulations - unfortunately I'm not. And even if I was, I'd
even call that slow. Wasting 11s on time synchronization during bootup is
still unacceptable - this translates into the equivalent amount of downtime
for our clients. I'm using ntpd version 4.2.4p4 running on Gentoo Linux -
seems like that's a pretty recent version.
I can imagine a huge hue and cry if ntpdate is actually removed - given the
current slowness of 'ntpd -q -g'. The maintainers are welcome to remove it -
but given the current state, people will just dig up the old source, or hack
up a new one and keep using that until ntpd itself provides equivalent
support inside it.
- Mohit
Steve Kostecke
> * There were some questions on what I'm trying to do here. Basically
> we sell a distributed platform containing multiple machines arrange
> in a master-slave architecture. The slaves need to be sync'd with
> the master when they start up. Slow bootup times are unacceptable -
> specially wasting 3 minutes just to synchronize clocks is not ok.
> So the slaves need to quickly update the clock to roughly the same
> time as the master, and then later its ok for them to run ntp in the
> background.
If you're just interested in synchronizing all of these systems to a
common network time you may find that 'timed' is better suited to your
application than ntpd.
http://gentoo-portage.com/net-misc/netkit-timed/
Unruh
>Thanks to everyone for responding on this thread. I'll attempt to answer the
>questions asked by others on my original mail. It'll be great if people can
>write constructively rather than using keywords like 'idiotic' etc which
>serve no useful purpose and only motivate me to just ignore your email.
>* There were some questions on why my ntp.conf uses the local time source
>127.127.1.0. This question is irrelevant to this discussion, which focuses
>on why 'ntpd -q -g' is slow. Anyways, the reason this was added was because
>if the server at 10.50.33.100 is down, then we found that ntpd would hang -
>but if the lines concerning 127.127.1.0 was there, the ntpd would still make
>progress if the external NTP server was down.
>* Someone suggested just running 'ntpd' and not the oneshot 'ntpd -q -g'.
>Again, not relevant to this discussion. But the answer is that the machine
>needs to start with the clock roughly synchronized - its ok to be running
>'ntpd' in the background later.
If you run ntp -g, it WILL roughly synchronize it in exactly the same way
as ntpd -g -q does. The -q does nothing to affect the behaviour of ntp,
except once it first sets the clock, it exits.
>* There were some questions on what I'm trying to do here. Basically we sell
>a distributed platform containing multiple machines arrange in a
>master-slave architecture. The slaves need to be sync'd with the master when
>they start up. Slow bootup times are unacceptable - specially wasting 3
>minutes just to synchronize clocks is not ok. So the slaves need to quickly
>update the clock to roughly the same time as the master, and then later its
>ok for them to run ntp in the background. Since this is a custom
>environment, the slaves are totally willing to accept the master as the NTP
>source (the master is at IP address 10.50.33.100). So there's no reason for
>the ntp client at the slaves to not believe the first reply they see from
>the master.
Except that ntp does NOT believe the first reply, since it has no idea what
the network is doing.
Are you running on Linux or windows? If on Linux, you might want to look at
chrony, which is much faster in converging to the right time, and
furthermore is better at disciplining the clocks once it is running.
If you are on Windows, chrony does not work.
ntp has a very bad habit of throwing away 7/8 of the packets it receives.
This is to account for assymmetric network delays, but to me is like
amputating a leg because you might have athelete's foot. It does this even
if there is no evidence whatsoever that there are such assymetric delays,
and despite the fact that they now have the huff and puff filter to account
for assymetric delays.
>* Someone mentioned that they're seeing sync'up times of 11s with 'ntpd -q
>-g'. Well, congratulations - unfortunately I'm not. And even if I was, I'd
>even call that slow. Wasting 11s on time synchronization during bootup is
>still unacceptable - this translates into the equivalent amount of downtime
>for our clients. I'm using ntpd version 4.2.4p4 running on Gentoo Linux -
>seems like that's a pretty recent version.
The usual way of starting up machines is to use the machine's own rtc to
start up the clock. Using a recent hwclock, this use can be quite accurate
( better than a second after a day's downtime). Not sure what your
requirements are.
Rick Jones
> If you must shut down to save electricity or something, you'll just
> have to start the machines a few minutes before they need to have
> the correct time.
While I'm sure there are lots of cases where the start time may be
known well enough in advance, I don't think that can be relied
upon. Yes, there is a counter argument that "if they need such quick
reaction they should have a warm standby" but "green" issues may often
trump that.
rick jones
--
a wide gulf separates "what if" from "if only"
Rick Jones
I'm sure I'm about to soil my shoe in what may be an old and
well-trodden pile, but if sntp can set the time as well and as quickly
as ntpdate, why a new program rather than fixes/enhancements to the
old one? Command-name inertia can be rather strong. Eg nslookup vs
dig or host.
rick jones
--
Wisdom Teeth are impacted, people are affected by the effects of events.
Harlan Stenn
ntpdate has been broken for a long time and nobody would step up to fix it.
There seem to be two sets of folks who wanted to use ntpdate, those who
wanted the time to be set "well" and those who wanted to set the time
"quickly".
ntpd can set the time well, and sntp can set the time quickly.
See http://support.ntp.org/bin/view/Dev/DeprecatingNtpdate for more
information.
Richard B. Gilbert
> Mohit Aron <extp...@gmail.com> wrote:
>> On Tue, Oct 14, 2008 at 4:19 PM, Harlan Stenn <st...@ntp.org> wrote:
>>> See http://support.ntp.org/bin/view/Dev/DeprecatingNtpdate .
>
>> Thanks. It seems 'sntp -r <server>' is the appropriate replacement
>> for ntpdate.
>
> I'm sure I'm about to soil my shoe in what may be an old and
> well-trodden pile, but if sntp can set the time as well and as quickly
> as ntpdate, why a new program rather than fixes/enhancements to the
> old one? Command-name inertia can be rather strong. Eg nslookup vs
> dig or host.
>
SOME programs can be easily fixed, enhanced, etc. Other programs,
thanks to such things as great age, poor initial design, or "too many
cooks" can be a nightmare to maintain.
I've got a copy of ntpdate that I use and will go on using. It does
what I want it to do! If it fails I'll consider using something else.
Harlan Stenn
the ability to determine the 'synchronization status' of ntpd.
Toward that end, http://support.ntp.org/bin/view/Dev/NtpdsSyncStatus has
been created.
I'd appreciate folks taking a look at that page, commenting and discussing
the issues.
Hal Murray
>It seems to me a topic related to initially getting the time set on a box is
>the ability to determine the 'synchronization status' of ntpd.
There is another can of worms in this area. What do you do if
it doesn't get synchronized within X seconds? (say because
your network link is down)
--
These are my opinions, not necessarily my employer's. I hate spam.
Rick Jones
> It seems to me a topic related to initially getting the time set on
> a box is the ability to determine the 'synchronization status' of
> ntpd.
> Toward that end, http://support.ntp.org/bin/view/Dev/NtpdsSyncStatus
> has been created.
> I'd appreciate folks taking a look at that page, commenting and
> discussing the issues.
The definition of 'correct' time
How about the following:
* The decoded system status bits contain sync_ntp
* (obsolete) ntpd is in state S_SYNC (which Dave is renaming to EVNT_SYNC)
* any slew adjustment in-process is under X (where X is configurable)
* Do we care about the root dispersion?
If this is in the context of a quick, initial time setting I would
wonder if I (for some number of I's) "really" care if none of the time
sources I ask aren't yet synced? I'm wondering if being set to a time
close to that of an unsynced server above me in the tree is better
than no time setting at all.
Mohit Aron
> > for ntpdate.
>
> I'm sure I'm about to soil my shoe in what may be an old and
> well-trodden pile, but if sntp can set the time as well and as quickly
> as ntpdate, why a new program rather than fixes/enhancements to the
> old one? Command-name inertia can be rather strong. Eg nslookup vs
> dig or host.
>
Good question. I'd much rather just keep using ntpdate. The ntpd man page is
obviously wrong when it suggests that 'ntpd -q' mimics the behavior of
ntpdate - it doesn't - 'ntpd -q' is dog slow. Along comes 'sntp -r' to the
rescue.
Very interestingly, 'sntp' is distributed in the ntp emerge package on
Gentoo. However, on Ubuntu, the ntp deb package does not include sntp. In
fact, it doesn't seem like sntp even exists in any package in Ubuntu. I did
find the deb package 'msntp' on Ubuntu, which has the binary 'msntp' which
seems to perform exactly like the 'sntp' binary on Gentoo. The man pages
also look suspiciously similar. Go figure.
- Mohit
Mohit Aron
> as ntpd -g -q does. The -q does nothing to affect the behaviour of ntp,
> except once it first sets the clock, it exits.
>
Yes, I realize that. However, it does mean that the time will be
synchronized after a long time - the machine needs to do lots of startup
stuff when it starts and its essential that the time be approximately
correct when this happens. For example, it needs to log messages about
various things - the timestamps on these log messages cannot be out of
whack. That's why its important to update the time quickly in a single shot,
and then run something like 'ntpd -g' which can keep the time in sync in the
background.
>
>
> Are you running on Linux or windows? If on Linux, you might want to look at
> chrony, which is much faster in converging to the right time, and
> furthermore is better at disciplining the clocks once it is running.
> If you are on Windows, chrony does not work.
>
I'm running on Linux. One of the links posted in this thread helped me find
a good alternative to ntpdate - which is 'sntp -r <server>'. I'll check out
chrony too, but it seems sntp will probably serve my purpose.
> The usual way of starting up machines is to use the machine's own rtc to
> start up the clock. Using a recent hwclock, this use can be quite accurate
> ( better than a second after a day's downtime). Not sure what your
> requirements are.
>
The issue is that when new machines are added to the cluster, their times
might be completely out of whack. So hwclock can in general not be relied
upon. Also, we use VMware based virtual machines for internal testing - such
machines can't keep their hwclock ticking while they are powered down.
- Mohit
Steve Kostecke
> obviously wrong when it suggests that 'ntpd -q' mimics the behavior of
> ntpdate - it doesn't - 'ntpd -q' is dog slow.
In your experience.
> Very interestingly, 'sntp' is distributed in the ntp emerge package
> on Gentoo. However, on Ubuntu, the ntp deb package does not include
> sntp. In fact, it doesn't seem like sntp even exists in any package in
> Ubuntu.
sntp first appeared in the NTP Reference Implementation Stable Release
at version 4.2.2
The current NTP Stable Release is 4.2.4p5. It is possible that Unbuntu
ships an older version. Debian stable, for instance, ships 4.2.2p4.
> I did find the deb package 'msntp' on Ubuntu, which has the binary
> 'msntp' which seems to perform exactly like the 'sntp' binary on
> Gentoo.
MSNTP an independent implementation of sntp by Nick Maclaren at the
University of Cambridge. It is aparently licensed under the GPL. Here is
the description for the Debian msntp package:
Description: A very simple and portable SNTP client/server
MSNTP is intended to be a straightforward SNTP (Simple Network Time
Protocol) daemon/utility that is easy to build on any reasonable
Unix platform (and most near-Unix ones), whether or not it has ever
been ported to them before. It is intended to answer the following
requirements, either by challenge and response or the less reliable
broadcast method:
A simple command to run on Unix systems that will check the time and
optionally drift compared with a known, local and reliable NTP time
server. No privilege is required just to read the time and estimate the
drift.
A client for Unix systems that will synchronise the time from a known,
local and reliable NTP time server.
A server for Unix systems that are synchronised other than by NTP
methods and that need to synchronise other systems by NTP. It is NOT
intended to work as a peer with true NTP servers, and won't.
Homepage: http://www.hpcf.cam.ac.uk/export/
Steve Kostecke
> ATTRIBUTION MISSING said:
>
>> If you run ntp -g, it WILL roughly synchronize it in exactly the same
>> way as ntpd -g -q does. The -q does nothing to affect the behaviour
>> of ntp, except once it first sets the clock, it exits.
>
> Yes, I realize that. However, it does mean that the time will be
> synchronized after a long time - the machine needs to do lots of
> startup stuff when it starts and its essential that the time be
> approximately correct when this happens. For example, it needs to log
> messages about various things - the timestamps on these log messages
> cannot be out of whack. That's why its important to update the time
> quickly in a single shot, and then run something like 'ntpd -g' which
> can keep the time in sync in the background.
Here's a possible explanation for your report of 'ntpd -gq' taking 3
minutes to sync:
When older versions of ntpd start up the Undisciplined Local Clock
(LocalCLK) will not be accepted as a "time source" until 4 polls have
elapsed. The first poll occurs at start up and the subsequent polls
occur at 64 second intervals using the default settings. So, using the
dafults, the quickest that ntpd can "sync" to the LocalCLK is a bit
over 3 * 64 seconds (192 sceonds or 3.2 minutes). When ntpd is started
with '-gq' and only has the LocalCLK as a time source it _will_ block
for a bit over 3 minutes. This "sync" time may be reduced a bit (to
about 50 seconds) by setting minpoll for the LocalCLK to 4 (i.e. 'server
127.127.1.0 minpoll 4).
Along the same vein, if the server is using the Undisciplined Local
Clock (LocalCLK) as it's time source _none_ of the client systems will
be able to sync to it for _at_ _least_ 3 minutes after it boots.
So using sntp at client start up may not be the panacea it appears to
be.
Even though it appears that sntp, or ntpdate, are "done" because they
return almost immediately the initial clock setting may have silently
failed because ntpd on the server is not available (whether it is
because the server is down or the server's ntpd is not synced is not
important). The client systems may be "free wheeling" for some time
before their ntpds are are able to poll the server and step their
clocks or initate the first slew.
David Woolley
> The issue is that when new machines are added to the cluster, their times
> might be completely out of whack. So hwclock can in general not be relied
> upon. Also, we use VMware based virtual machines for internal testing - such
> machines can't keep their hwclock ticking while they are powered down.
VMWare plays tricks with time and the only way of maintaining sensible
time on a guest is to synchronise the host and then use VMWare tools.
Even then, I seem to remember, that only the simulated hardware clock
maintains true time; the timer ticks can be grouped and can slow down or
speed up, in the short term.
Do not run ntpd, or chrony, on a VMWare guest.
David Woolley
>
> MSNTP an independent implementation of sntp by Nick Maclaren at the
> University of Cambridge. It is aparently licensed under the GPL. Here is
> the description for the Debian msntp package:
Nick Maclaren is a statistician (he was statistics programming adviser
when I was a student). When he contributed to this newsgroup, he was a
strong proponent of the linear regression strategy also used by chrony.
I hadn't heard of MSNTP before, so I don't know if it is also a linear
regression tracker.
Richard B. Gilbert
> It seems to me a topic related to initially getting the time set on a box is
> the ability to determine the 'synchronization status' of ntpd.
>
> Toward that end, http://support.ntp.org/bin/view/Dev/NtpdsSyncStatus has
> been created.
>
> I'd appreciate folks taking a look at that page, commenting and discussing
> the issues.
"Do we care about root dispersion?"
As I understand it, "root dispersion" is the difference between my clock
and the atomic clock at the root. If my understanding is correct, I
think we do care about it. If the absolute value is greater than about
100 microseconds I would begin to be concerned. Others might choose
some other value.
It's probably worth noting that some people care about the correct time
while others only care that all their clocks are within a few
milliseconds of each other.
David Woolley
> * any slew adjustment in-process is under X (where X is configurable)
I'm not sure that is a meaningful concept for ntpd. If ntpd does have
an explicit concept of slewing, it would only be when correcting an
error greater than 128ms, with stepping forbidden. If it does have such
a state, I don't think being in the state would be enough to disqualify
the time.
Richard B. Gilbert
>> It seems to me a topic related to initially getting the time set on a box is
>> the ability to determine the 'synchronization status' of ntpd.
>
> There is another can of worms in this area. What do you do if
> it doesn't get synchronized within X seconds? (say because
> your network link is down)
>
Is there anything you CAN do? It would seem that with the network down
your options are to live with whatever time the system clock has or to
set the time to that of the best available source, be it your wrist
watch, cell phone, sun dial, etc. Even if your source is perfect, your
ability to set the clock using "date" or the equivalent on some non
Unix/Linux system is probably going to leave your clock off by 500
milliseconds or more.
If you MUST have the correct time whether the network is working or not,
you probably should have a "hardware reference clock" such as a GPS
timing receiver, WWV receiver, etc.
David Woolley
> As I understand it, "root dispersion" is the difference between my clock
> and the atomic clock at the root. If my understanding is correct, I
It's not the difference. It is a somewhat worst case estimate of the
part of the difference due to the time elapsed since the root clock time
was measured and certain other measurement uncertainties.
> think we do care about it. If the absolute value is greater than about
> 100 microseconds I would begin to be concerned. Others might choose
> some other value.
ntpd uses 1,000,000 microseconds (I can't remember if root delay is
included in root dispersion, or whether the limit is on the sum of the
two). A value of 100 microseconds would require an excessively high
poll rate, especially for a high stratum client.
By default, (root) dispersion grows at 15 microseconds per second, so
one would need to use a root measurement which was less than 7 seconds
old, if this were the only term in root dispersion. Standard minpoll is
64 seconds, of which only 1 in 8 samples may be effective, i.e. a
stratum 2 server at minpoll will already have accumulated up to 3840
microseconds. At maxpoll, it will be more like 120ms. This ignore
dispersion from the reference clock polling interval.
At stratum 15, and assuming the polls average half way between the
interval for the previous server, I believe you will have used the full
one second budget!
Unruh
>Harlan Stenn wrote:
>> It seems to me a topic related to initially getting the time set on a box is
>> the ability to determine the 'synchronization status' of ntpd.
>>
>> Toward that end, http://support.ntp.org/bin/view/Dev/NtpdsSyncStatus has
>> been created.
>>
>> I'd appreciate folks taking a look at that page, commenting and discussing
>> the issues.
>"Do we care about root dispersion?"
>As I understand it, "root dispersion" is the difference between my clock
>and the atomic clock at the root. If my understanding is correct, I
>think we do care about it. If the absolute value is greater than about
>100 microseconds I would begin to be concerned. Others might choose
>some other value.
Well, no, since if we knew the difference between my clock and the atomic
clock at root, we would get rid of it. It is a very conserative estimate of
what the difference at worst could be. As such it is a piece of
information but does not allow you to do anything with it, except maybe
find a new server. 100us is a very vary short time and it had better be on
a local net. (Ie, the network transport time on my local net is about
140usec, and that sets a limit on the accuracy estimate of my clock.)
Since I have an atomic clock, I can look at a remote clock gps clock. the
network delay is 45ms, but the offset is only .2ms. The root delay my
system would have to report would be 45ms, even though it would be
disciplining my local clock to better than 1ms.
Harlan Stenn
Rick> Harlan Stenn <st...@ntp.org> wrote:
>> It seems to me a topic related to initially getting the time set on a box
>> is the ability to determine the 'synchronization status' of ntpd.
>> Toward that end, http://support.ntp.org/bin/view/Dev/NtpdsSyncStatus has
>> been created.
>> I'd appreciate folks taking a look at that page, commenting and
>> discussing the issues.
That page says:
The definition of 'correct' time
How about the following:
* The decoded system status bits contain sync_ntp
* (obsolete) ntpd is in state S_SYNC (which Dave is renaming to EVNT_SYNC)
* any slew adjustment in-process is under X (where X is configurable)
* Do we care about the root dispersion?
Rick> If this is in the context of a quick, initial time setting I would
Rick> wonder if I (for some number of I's) "really" care if none of the time
Rick> sources I ask aren't yet synced? I'm wondering if being set to a time
Rick> close to that of an unsynced server above me in the tree is better
Rick> than no time setting at all.
The definition is general.
If your time sources are not sync'd, how can they offer time to the client?
The rest of your choices are "local policy", as best I can tell.
Harlan Stenn
> * any slew adjustment in-process is under X (where X is configurable)
David> I'm not sure that is a meaningful concept for ntpd. If ntpd does
David> have an explicit concept of slewing, it would only be when correcting
David> an error greater than 128ms, with stepping forbidden. If it does
David> have such a state, I don't think being in the state would be enough
David> to disqualify the time.
I don't see your point.
Regardless of the original reason, a given instance of ntpd may be applying
a slew that will take "noticeable time" to complete.
In the old days, I recall (and I could be mistaken) that ntpd would report
its idea of the time that included any pending slew correction. I believe
Dave fixed this, saying something like "now, ntpd does not lie about the
time".
If this is incorrect, please let me know and Ill be sure to document it.
But the bottom line is that if ntpd is reporting the time on the machine and
a slew is in progress, I think it is important *in the context of this
thread* to be able to have ntpd say "I think the time is X and any
correction I may be applying is under X".
If this is not needed because the pending correction is included in some
other statistic, that's fine too (and should be documented).
Harlan Stenn
>> If you run ntp -g, it WILL roughly synchronize it in exactly the same way
>> as ntpd -g -q does. The -q does nothing to affect the behaviour of ntp,
>> except once it first sets the clock, it exits.
Mohit> Yes, I realize that. However, it does mean that the time will be
Mohit> synchronized after a long time - the machine needs to do lots of
Mohit> startup stuff when it starts and its essential that the time be
Mohit> approximately correct when this happens.
See http://support.ntp.org/bin/view/Support/StartingNTP
Harlan Stenn
>> > Thanks. It seems 'sntp -r <server>' is the appropriate replacement >
>> for ntpdate.
>>
>> I'm sure I'm about to soil my shoe in what may be an old and well-trodden
>> pile, but if sntp can set the time as well and as quickly as ntpdate, why
>> a new program rather than fixes/enhancements to the old one?
I thought we answered this already.
ntpdate is broken, and has been for a very long time.
Folks have used ntpdate to initially set the time for ntpd.
This is generally no longer needed.
Please see:
http://support.ntp.org/bin/view/Support/StartingNTP
and
http://support.ntp.org/bin/view/Dev/DeprecatingNtpdate
for a discussion of the issues.
Mohit> Good question. I'd much rather just keep using ntpdate. The ntpd man
Mohit> page is obviously wrong when it suggests that 'ntpd -q' mimics the
Mohit> behavior of ntpdate - it doesn't - 'ntpd -q' is dog slow. Along comes
Mohit> 'sntp -r' to the rescue.
Eventually the ntpd man page will be updated. But for a certain class of
situation, yes ntpd -q does mimic ntpdate.
Please remembere that I mentioned that ntpdate is broken and has been for a
long time.
Mohit> ... I did find the deb package 'msntp' on Ubuntu, which has
Mohit> the binary 'msntp' which seems to perform exactly like the 'sntp'
Mohit> binary on Gentoo. The man pages also look suspiciously similar. Go
Mohit> figure.
The currently distributed sntp is the msntp package. That package is being
replaced by an sntp implementation that is up-to-date with the current RFC.
Harlan Stenn
Harlan> The currently distributed sntp is the msntp package. That package
Harlan> is being replaced by an sntp implementation that is up-to-date with
Harlan> the current RFC.
More precisely, the sntp code in the current distribution is effectively the
msntp package with a bunch of inappropriate things turned off.
I'm hoping the new sntp code will be in the 4.2.6 release, which will happen
as soon as somebody can fix the blocking bugs. For info on that, please
see:
http://support.ntp.org/bin/view/Dev/ReleaseSchedule
http://support.ntp.org/bin/view/Support/NetworkCodeWizardsWanted
Unruh
>>>> In article <976d969e0810151552y27b...@mail.gmail.com>, extp...@gmail.com (Mohit Aron) writes:
>>> > Thanks. It seems 'sntp -r <server>' is the appropriate replacement >
>>> for ntpdate.
>>>
>>> I'm sure I'm about to soil my shoe in what may be an old and well-trodden
>>> pile, but if sntp can set the time as well and as quickly as ntpdate, why
>>> a new program rather than fixes/enhancements to the old one?
>I thought we answered this already.
>ntpdate is broken, and has been for a very long time.
>Folks have used ntpdate to initially set the time for ntpd.
>This is generally no longer needed.
>Please see:
> http://support.ntp.org/bin/view/Support/StartingNTP
>and
> http://support.ntp.org/bin/view/Dev/DeprecatingNtpdate
>for a discussion of the issues.
>Mohit> Good question. I'd much rather just keep using ntpdate. The ntpd man
>Mohit> page is obviously wrong when it suggests that 'ntpd -q' mimics the
>Mohit> behavior of ntpdate - it doesn't - 'ntpd -q' is dog slow. Along comes
>Mohit> 'sntp -r' to the rescue.
>Eventually the ntpd man page will be updated. But for a certain class of
>situation, yes ntpd -q does mimic ntpdate.
>Please remembere that I mentioned that ntpdate is broken and has been for a
>long time.
It would probably help if you said exactly how ntpdate is broken. It is
obviously not broken so badly that it does not run. So what subtle issues
are there about ntpdate
David Woolley
>>>> In article <48f7b877$0$501$5a6a...@news.aaisp.net.uk>, David Woolley <da...@ex.djwhome.demon.co.uk.invalid> writes:
>
>> * any slew adjustment in-process is under X (where X is configurable)
>
> David> I'm not sure that is a meaningful concept for ntpd. If ntpd does
> David> have an explicit concept of slewing, it would only be when correcting
> David> an error greater than 128ms, with stepping forbidden. If it does
> David> have such a state, I don't think being in the state would be enough
> David> to disqualify the time.
>
> I don't see your point.
>
> Regardless of the original reason, a given instance of ntpd may be applying
> a slew that will take "noticeable time" to complete.
NTPv4 can do one of two things to the local clock:
- step the time (and possibly the frequency);
- apply the normal phase lock loop algorithm.
When doing the latter, it has no idea whether a large offset is a
statistical fluke or a real error. (There is a limit on the frequency
correction applied, and it could be argued, that exceeding that puts the
time in question.)
There is no concept of a distinct slewing state.
NTPv3 had a third option, a sub class of stepping, in which the time
seen by clients stepped, but the time seen by the system on which it was
running was slewed at 500ppm. The option that enabled that mode, simply
sets the value of offset which will trigger a step very high (10
minutes, I think) on NTPv4.
NTPv4 does ignore large offsets for about 15 minutes, before initiating
a step (that's in addition to the delay imposed by the best of 8
filter). However, the presumption is that the clock is right and there
is a temporary disturbance in the measurements.
Richard B. Gilbert
I do not use ntpdate very often but, when I do, it DOES SEEM TO WORK!
It does not, however, offer the defenses against diseased servers that
ntpd does. You had better believe that there are servers out there and
responding to NTP queries that do not even know the correct YEAR!!!!!
Unruh
But with ntpdate, the server is under your control. So this is hardly
something I would call "broken".
Harlan insists that it is broken-- mentioned it twice-- but never said how
and why it is broken. What he calls broken may be a feature other people
never use.
Steve Kostecke
> But with ntpdate, the server is under your control. So this is hardly
> something I would call "broken". Harlan insists that it is broken--
> mentioned it twice-- but never said how and why it is broken. What he
> calls broken may be a feature other people never use.
This discussion dates back to August, 2002.
Please see
http://groups.google.com/group/comp.protocols.time.ntp/msg/3387eda49518407a?dmode=source
Harlan Stenn
Unruh> But with ntpdate, the server is under your control. So this is hardly
Unruh> something I would call "broken". Harlan insists that it is broken--
Unruh> mentioned it twice-- but never said how and why it is broken. What he
Unruh> calls broken may be a feature other people never use.
Yawn.
As a troll attempt, that was pretty lame. And there are enough trolls.
Believe me or not, your choice.
I recommend searching the archives - the status of ntpdate is pretty old
news, and predates the support twiki (as I recall), and the decision to
deprecate ntpdate may even predate our use of bugzilla.
I'm probably done with this thread.
David Woolley
> This discussion dates back to August, 2002.
>
> Please see
> http://groups.google.com/group/comp.protocols.time.ntp/msg/3387eda49518407a?dmode=source
>
The argument there seems to be not that ntpdate is worse than SNTP, but
that there is an implied promise that it is almost as good as ntpd. The
reason for having SNTP is to have something which has no pretensions of
being anything other than crude.
Unruh
>On 2008-10-18, Unruh <unruh...@physics.ubc.ca> wrote:
>> But with ntpdate, the server is under your control. So this is hardly
>> something I would call "broken". Harlan insists that it is broken--
>> mentioned it twice-- but never said how and why it is broken. What he
>> calls broken may be a feature other people never use.
>This discussion dates back to August, 2002.
>Please see
>http://groups.google.com/group/comp.protocols.time.ntp/msg/3387eda49518407a?dmode=source
Sorry, not very helpful. It is David Mills complaining that ntpdate is hard to
maintain and is flawed, but no indication of what the flaw is and in
particular if that flaw(s) would bother anyone except David.
Unruh
>>>> In article <GQoKk.2334$%%2.337@edtnps82>, Unruh <unruh...@physics.ubc.ca> writes:
>Unruh> But with ntpdate, the server is under your control. So this is hardly
>Unruh> something I would call "broken". Harlan insists that it is broken--
>Unruh> mentioned it twice-- but never said how and why it is broken. What he
>Unruh> calls broken may be a feature other people never use.
>Yawn.
>As a troll attempt, that was pretty lame. And there are enough trolls.
It was NOT a troll attempt. It was an attempt to learn what you consider
the flaws in ntpdate are, so that users can make up their own mind whether
or not to use it. I understand that there is a long long long running
desire to get rid of it ( which has apparently failed), but I do not
understand what the flaws are.
>Believe me or not, your choice.
I thought were were talking about facts, not beliefs.
>I recommend searching the archives - the status of ntpdate is pretty old
>news, and predates the support twiki (as I recall), and the decision to
>deprecate ntpdate may even predate our use of bugzilla.
Yes, it is old, and has apparently failed to have any effect. ntpdate is
still there, and thousands still rely on it.
>I'm probably done with this thread.
Ok, that is of course your choice. I would still like to know what the
flaws are.
Unruh
>Steve Kostecke wrote:
??? The rfc on sntp seems to say that sntp should be just as good as ntp in
disciplining a local clock, it just should not be used as a server (
uneless it gets its time from an atomic clock). Ie, the promises for sntp
seem far stronger than for ntpdate. ntpdate makes no promise to discipline
the frequency of a computer's clock. sntp does as far as I can see.
The claim is that ntpdate should be retired because a) it is written in a
way which is hard to maintain, and support, and b) it is flawed. The first
is a perfectly valid concern. The second I would like to know how it is
flawed. AFAIK all it does is to set the local clock to the time as
determined via ntp packet exchange from some server. it does not set the
frequency, it just sets the time. Is there some flaw in the way in which it
sets the time? Could I run ntpdate with a reliable server as a source and
suddenly discover that my local clock is out by 79 days, or that the
frequency has been reset to 1 tick per century? Ie, is there a flaw in what
it claims to do?
David Woolley
> David Woolley <da...@ex.djwhome.demon.co.uk.invalid> writes:
>> The argument there seems to be not that ntpdate is worse than SNTP, but
>> that there is an implied promise that it is almost as good as ntpd. The
>> reason for having SNTP is to have something which has no pretensions of
>> being anything other than crude.
>
> ??? The rfc on sntp seems to say that sntp should be just as good as ntp in
> disciplining a local clock, it just should not be used as a server (
The article wasn't talking about SNTP in general (which basically covers
anything, other than NTP, using the NTP wire formats), but rather about
the minimal SNTP implementation that should be included in the reference
implementation package.
Unruh
I would think that something called sntp, which as you say "which basically
covers anything, other than NTP, using the NTP wire formats" would hold out
far more promise of being "almost as good as ntpd" than does a program called ntpdate
(based on rdate) whose only purpose is to use the ntp wire protocol to set the time.
Ie, I do not believe that anyone thinks that ntpdate is as good as ntp (
although claims that you could run ntpdate every hour from a cron job as an
alternative to ntpd may convey that impression-- but that would also be
true of sntp).
ntpdate serves a useful purpose, something which ntpd -g -q does not do
(because for the purpose of setting the clock in a one-shot manner, ntpd is
seriously flawed, especially if the clock is already within 128ms of the
correct time). Now, sntp should be equally seriously flawed, since the
suggestion in the rfc is that it use the same algorithm for clock setting as ntp uses
I certainly would not overload the name sntp with yet another operating
mode. (sntp should not be used as a server, unless sntp is fed by a
hardware clock, in which case it can be. Now in addition-- sntp should
discipline the phase and frequency of the clock, unless it is used in a
oneshot manner when it should discipline only the phase.) I think it is far
better to have something called ntpdate to act in a oneshot manner, and be
clear that that is all that it is for, than to overload a name like sntp
with all kinds of incompatible operating modes.
David Woolley
> David Woolley <da...@ex.djwhome.demon.co.uk.invalid> writes:
>
>> Unruh wrote:
>>> David Woolley <da...@ex.djwhome.demon.co.uk.invalid> writes:
>
>>>> The argument there seems to be not that ntpdate is worse than SNTP, but
>>>> that there is an implied promise that it is almost as good as ntpd. The
>>>> reason for having SNTP is to have something which has no pretensions of
>>>> being anything other than crude.
>>> ??? The rfc on sntp seems to say that sntp should be just as good as ntp in
>>> disciplining a local clock, it just should not be used as a server (
>
>> The article wasn't talking about SNTP in general (which basically covers
>> anything, other than NTP, using the NTP wire formats), but rather about
>> the minimal SNTP implementation that should be included in the reference
>> implementation package.
>
> I would think that something called sntp, which as you say "which basically
> covers anything, other than NTP, using the NTP wire formats" would hold out
You didn't read what I wrote. I said that the meaning of sntp in this
context was a program that was a minimal SNTP implementation (it
performs a single exchange with a single server).
Harlan Stenn
Unruh> Harlan Stenn <st...@ntp.org> writes:
>>>>> In article <GQoKk.2334$%%2.337@edtnps82>, Unruh
>>>>> <unruh...@physics.ubc.ca> writes:
Unruh> But with ntpdate, the server is under your control. So this is hardly
Unruh> something I would call "broken". Harlan insists that it is broken--
Unruh> mentioned it twice-- but never said how and why it is broken. What he
Unruh> calls broken may be a feature other people never use.
>> Yawn.
>> As a troll attempt, that was pretty lame. And there are enough trolls.
Unruh> It was NOT a troll attempt. It was an attempt to learn what you
Unruh> consider the flaws in ntpdate are, so that users can make up their
Unruh> own mind whether or not to use it. I understand that there is a long
Unruh> long long running desire to get rid of it ( which has apparently
Unruh> failed), but I do not understand what the flaws are.
I do not choose to investigate the archives to find even a portion of the
"evidence". For folks who have "been around", I believe it is just accepted
that we remember that ntpdate has serious flaws and nobody wants to fix it,
especially now that ntpd has most of the needed functionality and sntp has
the rest. The only thing left before we "pull the trigger" is to finish
sntp and perhaps write a script called ntpdate to drop in for folks who just
don't care to make a more conscious choice.
At one time, ntpd and ntpdate contained duplicate code. If ntpdate was
given a single hostname, it sent the packet, got the response, and set the
time. If it was given more than one hostname it sent the request to each
host and originally ran the same algorithms as ntpd to set the time from the
"best" choice.
Over the years, many bugs were found and many improvements were made to
the selection algorithms and even the time-setting code in ntpd that were
*not* made to ntpdate.
It also became clear that there were at least two populations who used
ntpdate, and they had conflicting goals.
One wanted the time set ASAP, with "less" consideration for the quality of
the time.
The other wanted the time set *well*, with "less" consideration for the
speed with which that was done.
Each of these groups wanted to do this before ntpd, because in most cases
they wanted to start ntpd after the time was set (because we didn't have
enough knobs to offer the variety of policy choices users wanted in ntpd
alone).
The best solution to this mess was to deprecate ntpdate, once there was a
way to provide all of the intended *and assumed* functionality of ntpdate by
some other way.
The first set was removing the need to set the time with ntpdate before
starting ntpd. The solution to this problem is -g, and perhaps calling
ntp-wait (which actually implemented a missing feature that had been needed
before).
The next step was to decide which was more important for local policy,
setting the time, once, well (ntpd -q) or setting the time, once, quickly
(sntp).
If people think the current ntpdate is working well I would bet (and I
believe I'd win the bet) that they are not getting the behavior they think
they are getting, and they are oblivious to the (occasional?) problems they
are having.
>> Believe me or not, your choice.
Unruh> I thought were were talking about facts, not beliefs.
It has been my experience that any "link" between facts->beliefs is heavily
tainted with ... hallucination. But things mostly work out anyway. Mostly.
As Samuel Johnson said: Subsequence does not imply consequence.
>> I recommend searching the archives - the status of ntpdate is pretty old
>> news, and predates the support twiki (as I recall), and the decision to
>> deprecate ntpdate may even predate our use of bugzilla.
Unruh> Yes, it is old, and has apparently failed to have any effect. ntpdate
Unruh> is still there, and thousands still rely on it.
There will be a script called "ntpdate" for those folks who want to keep
running a program by that name.
But I don't see how your point relates to the underlying issue.
I think the biggest reason ntpdate has stuck around is we have not forced
the issue. When we remove the old code and include a new script, I bet most
folks will simply not notice.
The ones who *do* notice will be the ones who (think they) care enough to
make a choice and override whatever behavior they do not like.
>> I'm probably done with this thread.
Unruh> Ok, that is of course your choice. I would still like to know what
Unruh> the flaws are.
I'm not sure I have answered to your satisfaction, but I hope this is at
least a sufficient step in the right direction.
Richard B. Gilbert
I believe that one of the biggest problems with ntpdate is that it has
no volunteer maintainer; no one is responsible for it. Wrapping your
mind around someone else's code can be damned near impossible unless the
code is well written and well documented. I haven't looked at the code
but I suspect that both attributes are lacking.
Since sntp can do most, if not all, of what ntpdate does, there is
little or no incentive to bring ntpdate up to standard!
Since ntpdate does something useful and at least appears to do it
correctly, it will probably be around for quite a while.
Mohit Aron
> way to provide all of the intended *and assumed* functionality of ntpdate
> by
> some other way.
>
> The first set was removing the need to set the time with ntpdate before
> starting ntpd. The solution to this problem is -g, and perhaps calling
> ntp-wait (which actually implemented a missing feature that had been needed
> before).
>
I don't think '-g' option to ntpd is a practical solution - since it takes
way too long to set the local time. Given this, people will continue to use
ntpdate or sntp to set the time in a one-shot way before actually running
ntpd.
> There will be a script called "ntpdate" for those folks who want to keep
> running a program by that name.
>
That will be great. It'll also be super if the ntpd man page can be fixed so
it doesn't say ntpdate is to be retired and that 'ntpd -q' is an alternative
to using ntpdate. This is spreading a lot of misinformation and causing
waste of time. My company changed all the configs in our product to use
'ntpd -q', only to realize the hard way that it is way slower than 'ntpdate'
and then we had to revert back.
- Mohit
Mohit Aron
>
>
Can someone tell us what in ntpdate is broken. And since 'ntpdate <server>'
seems to do exactly the same thing as 'sntp -r <server>', why is the latter
not broken ?
I'm sure there are tons of configurations out there that use ntpdate. Rather
than deprecating it and making people replace it with 'sntp -r <server>', it
might be better to just fix what's broken in ntpdate. Another option is to
make 'ntpdate' a hardlink or symbolic link to 'sntp' and the latter can
mimic 'ntpdate' behavior when it realizes it is being called with the name
'ntpdate'.
- Mohit
Harlan Stenn
Bill, you are off in the weeds. The conjectures to not match reality.
"If we had ham, we could have ham and eggs. If we had eggs."
H
--
>>> In article <GmLKk.2567$%%2.1526@edtnps82>, Unruh <unruh...@physics.ubc.ca> writes:
Unruh> David Woolley <da...@ex.djwhome.demon.co.uk.invalid> writes:
>> Unruh wrote:
>>> David Woolley <da...@ex.djwhome.demon.co.uk.invalid> writes:
>>> The argument there seems to be not that ntpdate is worse than SNTP, but
>>> that there is an implied promise that it is almost as good as ntpd. The
>>> reason for having SNTP is to have something which has no pretensions of
>>> being anything other than crude.
>>> ??? The rfc on sntp seems to say that sntp should be just as good as
>>> ntp in disciplining a local clock, it just should not be used as a
>>> server (
>> The article wasn't talking about SNTP in general (which basically covers
>> anything, other than NTP, using the NTP wire formats), but rather about
>> the minimal SNTP implementation that should be included in the reference
>> implementation package.
Unruh> I would think that something called sntp, which as you say "which
Unruh> basically covers anything, other than NTP, using the NTP wire
Unruh> formats" would hold out far more promise of being "almost as good as
Unruh> ntpd" than does a program called ntpdate (based on rdate) whose only
Unruh> purpose is to use the ntp wire protocol to set the time.
Unruh> Ie, I do not believe that anyone thinks that ntpdate is as good as
Unruh> ntp ( although claims that you could run ntpdate every hour from a
Unruh> cron job as an alternative to ntpd may convey that impression-- but
Unruh> that would also be true of sntp).
Unruh> ntpdate serves a useful purpose, something which ntpd -g -q does not
Unruh> do (because for the purpose of setting the clock in a one-shot
Unruh> manner, ntpd is seriously flawed, especially if the clock is already
Unruh> within 128ms of the correct time). Now, sntp should be equally
Unruh> seriously flawed, since the suggestion in the rfc is that it use the
Unruh> same algorithm for clock setting as ntp uses I certainly would not
Unruh> overload the name sntp with yet another operating mode. (sntp should
Unruh> not be used as a server, unless sntp is fed by a hardware clock, in
Unruh> which case it can be. Now in addition-- sntp should discipline the
Unruh> phase and frequency of the clock, unless it is used in a oneshot
Unruh> manner when it should discipline only the phase.) I think it is far
Unruh> better to have something called ntpdate to act in a oneshot manner,
Unruh> and be clear that that is all that it is for, than to overload a name
Unruh> like sntp with all kinds of incompatible operating modes.
Harlan Stenn
>> The best solution to this mess was to deprecate ntpdate, once there was a
>> way to provide all of the intended *and assumed* functionality of ntpdate
>> by some other way.
>>
>> The first set was removing the need to set the time with ntpdate before
>> starting ntpd. The solution to this problem is -g, and perhaps calling
>> ntp-wait (which actually implemented a missing feature that had been
>> needed before).
Mohit> I don't think '-g' option to ntpd is a practical solution - since it
Mohit> takes way too long to set the local time. Given this, people will
Mohit> continue to use ntpdate or sntp to set the time in a one-shot way
Mohit> before actually running ntpd.
Please see http://support.ntp.org/bin/view/Dev/DeprecatingNtpdate and
http://support.ntp.org/bin/view/Support/StartingNTP .
Just because ntpd -g is not right for *your* application doesn't mean it is
wrong for everybody.
And in the instances I run, 'ntpd -g' has the machine sync'd and moving
along fine in about 11 seconds.
I recommend you:
- list each of your target goals
- identify various implementation choices
- identify the cost of implementing each target goal
- identify the cost of *not* being able to implement each target goal
>> There will be a script called "ntpdate" for those folks who want to keep
>> running a program by that name.
Mohit> That will be great. It'll also be super if the ntpd man page can be
Mohit> fixed so it doesn't say ntpdate is to be retired and that 'ntpd -q'
Mohit> is an alternative to using ntpdate. This is spreading a lot of
Mohit> misinformation and causing waste of time. My company changed all the
Mohit> configs in our product to use 'ntpd -q', only to realize the hard way
Mohit> that it is way slower than 'ntpdate' and then we had to revert back.
If your company would join the NTP Forum (see my .sig) you'd have the
ability to discuss things like this to make sure you were on the right
track, and if new functionality was needed you'd have a better avenue to get
that implemented, too.
Harlan Stenn
Unruh> ntpdate serves a useful purpose, something which ntpd -g -q does not
Unruh> do (because for the purpose of setting the clock in a one-shot
Unruh> manner, ntpd is seriously flawed, especially if the clock is already
Unruh> within 128ms of the correct time). Now, sntp should be equally
Unruh> seriously flawed, since the suggestion in the rfc is that it use the
Unruh> same algorithm for clock setting as ntp uses I certainly would not
Unruh> overload the name sntp with yet another operating mode.
It's comments like this that cause me to wonder if you are just being a
troll, and to wonder if I should invest effort in responding.
I certainly wonder what your goal is by writing things like this.
Mohit Aron
> Mohit> takes way too long to set the local time. Given this, people will
> Mohit> continue to use ntpdate or sntp to set the time in a one-shot way
> Mohit> before actually running ntpd.
>
> Please see http://support.ntp.org/bin/view/Dev/DeprecatingNtpdate and
> http://support.ntp.org/bin/view/Support/StartingNTP .
>
> Just because ntpd -g is not right for *your* application doesn't mean it is
> wrong for everybody.
>
> And in the instances I run, 'ntpd -g' has the machine sync'd and moving
> along fine in about 11 seconds.
>
An 11s delay during startup is also unsatisfactory. I've read the links
you've posted, and I realize that 'sntp -r <server>' might be an appropriate
replacement for ntpdate (if that binary were to go away). Ideally I'd prefer
that ntpdate just stays - in script form if nothing else. I'm merely
responding to your comment that 'ntpd -q -g' was chosen as a viable
replacement for 'ntpdate'.
> - list each of your target goals
> - identify various implementation choices
> - identify the cost of implementing each target goal
> - identify the cost of *not* being able to implement each target goal
>
I believe I've already done this in one of my priori emails on this thread.
Anyways, here it goes again.
My company sells a distributed platform where one machine acts as a time
server for the rest of the machines. These other machines (that act as ntp
clients) can be removed/replaced and it is highly desirable that these come
up again quickly on startup and synchronize their time with the server
machine. To do the time synchronization, we run 'ntpdate' to do a quick
one-shot update of time, and then 'ntpd' so that it takes care of
continuously synchronizing the time in the background. One of the admins
looked at the ntpd man page and decided to replace 'ntpdate' with 'ntpd -g
-q' - we started seeing 3 minute delays in starting up. I don't understand
why you only see 11s, but even if we were to see that, that'll still be a
problem.
All I'm suggesting is that the ntpd man page should be fixed since it is
clearly wrong when it says that 'ntpd -q' is an alternative for ntpdate.
> If your company would join the NTP Forum (see my .sig) you'd have the
> ability to discuss things like this to make sure you were on the right
> track, and if new functionality was needed you'd have a better avenue to
> get
> that implemented, too.
>
We are a small company and we don't have the bandwidth to join every forum
that's out there. I've raised the issue on this thread, and it seems others
are in agreement. I've also seen other threads that point out the same thing
(that 'ntpd -q' is too slow compared to ntpdate, and that deprecating
ntpdate is going to be a hassle). I hope the ntp maintainers find this
enough to guide their decisions than to require everyone to join a formal
forum.
- Mohit
Unruh
>Unruh wrote:
>> David Woolley <da...@ex.djwhome.demon.co.uk.invalid> writes:
>>
>>> Unruh wrote:
>>>> David Woolley <da...@ex.djwhome.demon.co.uk.invalid> writes:
>>
>>>>> The argument there seems to be not that ntpdate is worse than SNTP, but
>>>>> that there is an implied promise that it is almost as good as ntpd. The
>>>>> reason for having SNTP is to have something which has no pretensions of
>>>>> being anything other than crude.
>>>> ??? The rfc on sntp seems to say that sntp should be just as good as ntp in
>>>> disciplining a local clock, it just should not be used as a server (
>>
>>> The article wasn't talking about SNTP in general (which basically covers
>>> anything, other than NTP, using the NTP wire formats), but rather about
>>> the minimal SNTP implementation that should be included in the reference
>>> implementation package.
>>
>> I would think that something called sntp, which as you say "which basically
>> covers anything, other than NTP, using the NTP wire formats" would hold out
>You didn't read what I wrote. I said that the meaning of sntp in this
>context was a program that was a minimal SNTP implementation (it
>performs a single exchange with a single server).
I did read it and am objecting to using the program name sntp to refer to
something different from what the rfc says sntp is.
Unruh
>>> Yawn.
I assume you mean it ran the host selection algorithm, without the "filter"
or the frequency discipline algorithm.
>Over the years, many bugs were found and many improvements were made to
>the selection algorithms and even the time-setting code in ntpd that were
>*not* made to ntpdate.
>It also became clear that there were at least two populations who used
>ntpdate, and they had conflicting goals.
>One wanted the time set ASAP, with "less" consideration for the quality of
>the time.
>The other wanted the time set *well*, with "less" consideration for the
>speed with which that was done.
I would agree that ntpd subsumes this. But using ntpd for the first is just
not a good idea.
IF the script does the same thing as ntpdate did, then I agree with you, it
will not be noticed. If it does not, there will be screams.
>The ones who *do* notice will be the ones who (think they) care enough to
>make a choice and override whatever behavior they do not like.
>>> I'm probably done with this thread.
>Unruh> Ok, that is of course your choice. I would still like to know what
>Unruh> the flaws are.
>I'm not sure I have answered to your satisfaction, but I hope this is at
>least a sufficient step in the right direction.
Yes, thank you.
My only comment would be to please not use sntp as the name for the clock
quick setting program. It will only lead to confusion.
ntpdate was presumably chosen because it offered a better rdate. To call it
sntp, and then to have an SNTP protocol which does two incompatible things
as well is just guarenteed to confuse everyone.
When someone sells an atomic clock or gps clock with sntp server service,
people will think it is for setting computer times once quickly and not
very accurately. Or think that sntp is a replacement for ntpd for clients.
or....
Unruh
>> The best solution to this mess was to deprecate ntpdate, once there was a
>> way to provide all of the intended *and assumed* functionality of ntpdate
>> by
>> some other way.
>>
>> The first set was removing the need to set the time with ntpdate before
>> starting ntpd. The solution to this problem is -g, and perhaps calling
>> ntp-wait (which actually implemented a missing feature that had been needed
>> before).
>>
>I don't think '-g' option to ntpd is a practical solution - since it takes
>way too long to set the local time. Given this, people will continue to use
>ntpdate or sntp to set the time in a one-shot way before actually running
>ntpd.
No, it sets it fast. As long as the computer clock is way off. If the
computer clock is "almost OK" then problems arise.
There is absolutely no reason why ntp should take as long as it does to set
the time. But that will bring up the whole issue of chrony ( whichoperated
much more raplidly) and ntp algorithms. With the decision to use a
Markovian technique to discipline the clock, ntpd is probably the best you
can do.
Unruh
My goal is as a user to provide some input into ntp to make it better.
Using sntp as a name is not a good idea. I got very confused when I
originally thought that sntp was a client only protocol. Then I discovered
that it was both a client only protocol AND an atomic clock server
proptocol. And now it is the name of "set the clock once and quickly"
program as well.
That stikes me as a mess. Maybe it stikes noone else as a mess which is
fine. But as I found from my acting as a sysadmin, if noone complains, I
have no idea what stupidities I have institututed, or where things are
broken.
Harlan Stenn
Unruh> Using sntp as a name is not a good idea. I got very confused
Unruh> when I originally thought that sntp was a client only protocol. Then
Unruh> I discovered that it was both a client only protocol AND an atomic
Unruh> clock server proptocol. And now it is the name of "set the clock once
Unruh> and quickly" program as well. That stikes me as a mess. Maybe it
Unruh> stikes noone else as a mess which is fine. But as I found from my
Unruh> acting as a sysadmin, if noone complains, I have no idea what
Unruh> stupidities I have institututed, or where things are broken.
'sntp' seems to me to be a fine name for a program that implements the
client-side protocol that sets the time once and quickly.
If somebody wants to create an SNTP daemon and connects it to a time
reference, I would think 'sntpd' would be a good name for that.
I don't see the need for the 'sntpd' program described in the
implementation, but if that becomes useful it can certainly be added.
Harlan Stenn
Unruh> David Woolley <da...@ex.djwhome.demon.co.uk.invalid> writes:
>> You didn't read what I wrote. I said that the meaning of sntp in this
>> context was a program that was a minimal SNTP implementation (it performs
>> a single exchange with a single server).
Unruh> I did read it and am objecting to using the program name sntp to
Unruh> refer to something different from what the rfc says sntp is.
By my read and understanding of the RFC, SNTP as a protocol is designed to
be used to set the time once, quickly, and ordinarily would not have an
attached refclock (and therefore would not be a long-running daemon).
Therefore, 'sntp' seems to me to be a perfectly good name for a program that
does the work David describes.
It also matches what has been implemented.
I seem to be missing something you are seeing - what do you think the RFC
expects from an SNTP implementation? I'm talking about a client-only
implementation, not a barebones "I'm talking to a refclock and will answer
NTP queries" server.
Harlan Stenn
>> It also became clear that there were at least two populations who used
>> ntpdate, and they had conflicting goals.
>> One wanted the time set ASAP, with "less" consideration for the quality
>> of the time.
>> The other wanted the time set *well*, with "less" consideration for the
>> speed with which that was done.
Unruh> I would agree that ntpd subsumes this. But using ntpd for the first
Unruh> is just not a good idea.
Agreed, which is why http://support.ntp.org/bin/view/Dev/DeprecatingNtpdate
recommends using SNTP to set the time once quickly, and 'ntpd -gq' to set
the time once well.
Unruh> IF the script does the same thing as ntpdate did, then I agree with
Unruh> you, it will not be noticed. If it does not, there will be screams.
Well, there will be plenty of time for folks to check it out before I pull
the trigger.
Unruh> My only comment would be to please not use sntp as the name for the
Unruh> clock quick setting program. It will only lead to confusion.
I still don't see this - SNTP is primarily designed to support "client leaf"
applications, where the clock is not disciplined. The 'sntp' program does
this, and sure looks to me to be an accurate and faithful implementation of
the SNTP specification.
Unruh> ntpdate was presumably chosen because it offered a better rdate. To
Unruh> call it sntp, and then to have an SNTP protocol which does two
Unruh> incompatible things as well is just guarenteed to confuse everyone.
I'm still not getting your point. The 'sntp' program implements the SNTP
client protocol described in the RFC. ntpdate was once a good way to set
the time by querying some number of NTP servers.
Nobody is talking about taking existing ntpdate code and calling that
'sntp'.
And I don't yet see what you mean by "an SNTP protocol which does two
incompatible things".
Unruh> When someone sells an atomic clock or gps clock with sntp server
Unruh> service, people will think it is for setting computer times once
Unruh> quickly and not very accurately. Or think that sntp is a replacement
Unruh> for ntpd for clients. or....
There is no described way to determine if a server is implementing NTP or
SNTP. This is a feature.
There is no way to see if a "client" is an SNTP client or an NTP client.
The protocol is the same.
Frankly, I prefer the current nomenclature. If I see an appliance that
advertises itself as an SNTP server, I know it will only listen to itself
for time and will not be able to listen to other servers if a problem is
detected with its attached refclock.
This is also why I generally prefer to connect to a well-connected S2 NTP
server instead of an arbitrary S1 NTP server.
Unruh
It is clearly an alternative for ntpdate. It is just not an alternative
that you find acceptable.
When you set up ntpdate and then ntpd it is not at all clear that ntpd will
actually keep it on time. If the frequency is out, ntpd will take about
three hours to bring it back into line, and the time will also drift off
during that time. Ie, just because at t=0 the time is correct does not mean
that at t=1hr it still will be. Now it should not be out by too much, but
it depends on what you accept as "too much" Ie, if you are happy with 20ms
then everything is undoubtedly fine. If you need microseconds it may be
a concern.
>> If your company would join the NTP Forum (see my .sig) you'd have the
>> ability to discuss things like this to make sure you were on the right
>> track, and if new functionality was needed you'd have a better avenue to
>> get
>> that implemented, too.
>>
>We are a small company and we don't have the bandwidth to join every forum
>that's out there. I've raised the issue on this thread, and it seems others
>are in agreement. I've also seen other threads that point out the same thing
>(that 'ntpd -q' is too slow compared to ntpdate, and that deprecating
>ntpdate is going to be a hassle). I hope the ntp maintainers find this
>enough to guide their decisions than to require everyone to join a formal
>forum.
Time is of real concern to you, and the ntp forum is NOT "every forum
that's out there". You have strong views. You have spent a lot of time
here. It has been suggested that there is a vehicle for you to get directly
to the developers, and you now say it is too much to raise it in a forum
where you have direct access to the developers?
It is NOT a requirement. It was a suggestion about how you might be able to
have an influence.
>- Mohit
Unruh
It is an server (which other clients can use as a source for time) but one
which only does refclock and is not a client of any other ntp time source, or it is a
client which, in no case, should ever ever be used as a server.
Those are two incompatible things.
>Unruh> When someone sells an atomic clock or gps clock with sntp server
>Unruh> service, people will think it is for setting computer times once
>Unruh> quickly and not very accurately. Or think that sntp is a replacement
>Unruh> for ntpd for clients. or....
>There is no described way to determine if a server is implementing NTP or
>SNTP. This is a feature.
Agreed.
>There is no way to see if a "client" is an SNTP client or an NTP client.
Agreed.
>The protocol is the same.
>Frankly, I prefer the current nomenclature. If I see an appliance that
>advertises itself as an SNTP server, I know it will only listen to itself
>for time and will not be able to listen to other servers if a problem is
>detected with its attached refclock.
It does not in general advertise itself as an sntp server as you have just said.
>This is also why I generally prefer to connect to a well-connected S2 NTP
>server instead of an arbitrary S1 NTP server.
Agreed.
David J Taylor
[]
> By my read and understanding of the RFC, SNTP as a protocol is
> designed to be used to set the time once, quickly, and ordinarily
> would not have an attached refclock (and therefore would not be a
> long-running daemon).
>
> Therefore, 'sntp' seems to me to be a perfectly good name for a
> program that does the work David describes.
>
> It also matches what has been implemented.
>
> I seem to be missing something you are seeing - what do you think the
> RFC expects from an SNTP implementation? I'm talking about a
> client-only implementation, not a barebones "I'm talking to a
> refclock and will answer NTP queries" server.
Folks,
There are lots of "atomic time" programs out there which use SNTP as a
protocol for setting the clock on a similar semi-continuous basis to the
current NTPD program. The difference is that they don't use multiple
servers in the same way and the advanced phase and frequency algorithms of
NTP to produce a more stable, accurate and relaible result.
These programs run continuously, and to have a program which ran once only
and exited, but be called SNTP would, I think, be potentially rather
confusing.
If you have such a once-off program, why not call it by a meaningful name?
Starter suggestions:
ntpsnapshot
sntpsnapshot
ntpglance
sntpglance
remoteclocksnapshot
timeglance
clocksetandexit
clockboot
Cheers,
David
David Woolley
>
> By my read and understanding of the RFC, SNTP as a protocol is designed to
> be used to set the time once, quickly, and ordinarily would not have an
> attached refclock (and therefore would not be a long-running daemon).
>
application using it from actually making multiple reads, and typical
applications do make periodic reads. It also doesn't preclude
intelligent combination of the results of multiple reads.
Svein Skogen
Hash: SHA1
Mohit Aron wrote:
>>
>> Mohit> I don't think '-g' option to ntpd is a practical solution - since
it
>> Mohit> takes way too long to set the local time. Given this, people will
>> Mohit> continue to use ntpdate or sntp to set the time in a one-shot way
>> Mohit> before actually running ntpd.
>>
>> Please see http://support.ntp.org/bin/view/Dev/DeprecatingNtpdate and
>> http://support.ntp.org/bin/view/Support/StartingNTP .
>>
>> Just because ntpd -g is not right for *your* application doesn't mean it
is
>> wrong for everybody.
>>
>> And in the instances I run, 'ntpd -g' has the machine sync'd and moving
>> along fine in about 11 seconds.
>>
>
>
>
> An 11s delay during startup is also unsatisfactory. I've read the links
> you've posted, and I realize that 'sntp -r <server>' might be an
appropriate
> replacement for ntpdate (if that binary were to go away). Ideally I'd
prefer
> that ntpdate just stays - in script form if nothing else. I'm merely
> responding to your comment that 'ntpd -q -g' was chosen as a viable
> replacement for 'ntpdate'.
I've kept out of this topic on purpose, simply because I did not want to
add anything that people would take as a personal attack (and I failed
to see how I could vent my feelings without looking like I was starting
a flame war)
The way I see this, we're separated into two general camps here. In one
of the camps we find the purists who more or less on principle wants
ntpdate gone, because they want everybody to run ntpd. I can understand
them, even if I do not agree with them.
The other camp consists mostly of people in the operations environment.
A lot of them doing remote management of servers. In this camp, any
additional time in the boot sequence is both wasted time, and a
nightmare because you always have that nagging "what will go wrong THIS
time" when you remote reboot anything. I've been there, and I know the
feeling.
For the operations people, ntpdate is a supplement to ntpd, not a
replacement. They run ntpdate to get log timestamps +-1millennium
correct, then get on with their boot and throw ntpd into the background
to keep timestamps somewhat trusty.
Thus, they want ntpdate, or a script just as fast. 'ntpd -q -g' is NOT
the solution to their problem. Period. A script converting ntpdate
parameters into 'sntp -r' MAY be the solution.
However the real problem here is the fundamentalists that seem to want
ntpdate gone totally. This is a problem I'm afraid noone here can help
them with. If they have religious reasons for wanting something done or
gone, I suggest talking to a cleric about them. Sorry if I've insulted
anybody with this.
Just my ?0.02
//Svein
- --
- --------+-------------------+-----------------------------
/"\ |Svein Skogen | sv...@d80.iso100.no
\ / |Solberg Xstli 9 | PGP Key: 0xE5E76831
X |2020 Skedsmokorset | sv...@jernhuset.no
/ \ |Norway | PGP Key: 0xCE96CE13
| | sv...@stillbilde.net
ascii | | PGP Key: 0x58CD33B6
ribbon +-------------------+-----------------------------
Campaign|msn messenger: | Mobile Phone: +47 907 03 575
|sv...@jernhuset.no | RIPE handle: SS16503-RIPE
- --------+-------------------+-----------------------------
Picture Gallery: http://stillbilde.net/v/svein/
- ----------------------------------------------------------
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkj7xxIACgkQSBMQn1jNM7aXJQCfbB0jvvTfQe6pDVQMcf6h7nog
gukAnjyB8DeT87wX7U5zPaBwtX7duXCZ
=nCYx
-----END PGP SIGNATURE-----
Richard B. Gilbert
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Mohit Aron wrote:
>>> Mohit> I don't think '-g' option to ntpd is a practical solution - since
<snip>
There may be some aspects of "religious wars" but I think it's a good
deal simpler than it may appear!
Ntpdate is OLD code. There is no one able and willing to maintain it.
It has vulnerabilities not shared by ntpd or sntp. There are enough
copies of the source floating around that it will never disappear
completely.
"Deprecated" simply means "we no longer support it and you continue to
use it AT YOUR OWN RISK!"
If someone stepped up to maintain the code. . . .
Unruh
No, I think you are misinterpreting their position. They find ntpdate to be
badly written, and to be very difficult to maintain, and to have no
maintainer. They would thus like
to replace it with something quick and simple whose only job would be to
set the clock on the computer to the right time and then go away. They have
a candidate called (I think inappropriately) sntp and would like to
replace ntpdate with that program.
HOwever looking at the source code for sntp, it was written by Neil
Maclaren in 1996 as a competitor to xntp (the old ntpd) and has all sorts
of bells and whistles as a replacement to ntp, and it is not clear that he is maintaining it, or
who is.
"It supports the full SNTP (RFC 2030) client- and server-side challenge-response
and broadcast protocols."
Ie, it does not really look like an appropriate replacement for ntpdate,
although it does seem to be faster than ntpd -g -q.
See this sentence in the source code
"WARNING: this program has reached its 'hack count' and needs restructuring, badly."
(that was written I believe in 2000).
It also, like chrony, uses regression rather than ntp's markovian feedback
model in estimating rates and offsets. It is just bizzare to me that it
would be included in the ntp distribution, and being touted as a
replacement for ntpdate.
Harlan Stenn
by J. Max Kuehn as his GSoC project.
Bill Unruh
>Nick's SNTP code is about to be replaced with completely new code, written
>by J. Max Kuehn as his GSoC project.
Ah. OK. And this program will do what? Is it supposed to be a fully fledged
sntp (ie, act as a client only ntp program, or a server only if there is a
refclock source, and as a one shot program) or is it a one-shot replacement
for ntpdate?
And is it going to have the complete ntp filter/best source selection
algorithm? And will it have ntp's Markovian adjustment algorithm or a
regression algorithm (a la chrony an msntp), or...?
Harlan Stenn
Bill> Harlan Stenn <st...@ntp.org> writes:
>> Nick's SNTP code is about to be replaced with completely new code,
>> written by J. Max Kuehn as his GSoC project.
Bill> Ah. OK. And this program will do what? Is it supposed to be a fully
Bill> fledged sntp (ie, act as a client only ntp program, or a server only
Bill> if there is a refclock source, and as a one shot program) or is it a
Bill> one-shot replacement for ntpdate?
Bill> And is it going to have the complete ntp filter/best source selection
Bill> algorithm? And will it have ntp's Markovian adjustment algorithm or a
Bill> regression algorithm (a la chrony an msntp), or...?
The program implements the SNTP protocol as defined by the RFC, as a client.
It will not have support for attached refclocks.
Without my looking at the code or the RFC, I believe this means it will send
a request to the listed host(s) and set the time to the first answer it
receives, and then exit. If the time is stepped it will DTRT regarding
writing appropriate accounting messages (utmp/wtmp, as appropriate). It
will support at least one of the specified authentication mechanisms.
We are discussing if it should include a daemon mode that will just sleep a
while and re-ask, but that can be handled by a wrapper script or even a
small program that calls sntp.
The RFC should describe all of this.
There may be more, but this is what I remember off the top of my head.
Harlan Stenn
Svein> I've kept out of this topic on purpose, simply because I did not want
Svein> to add anything that people would take as a personal attack (and I
Svein> failed to see how I could vent my feelings without looking like I was
Svein> starting a flame war)
Svein> The way I see this, we're separated into two general camps here. In
Svein> one of the camps we find the purists who more or less on principle
Svein> wants ntpdate gone, because they want everybody to run ntpd. I can
Svein> understand them, even if I do not agree with them.
I'm curious how you got this impression - I'd be keeping ntpdate around if
it was working.
ntpdate originally used the same algorithms that ntpd used to "choose
wisely" but suffered from so much bitrot that the only choice was to find a
way to replace it. But there were also people screaming for a way to set
the time quickly. These are conflicting goals, so Dave (and some other
folks) went to a lot of work to make 'ntpd -q' do the "good" job ntpdate
did, and the SNTP spec was produced to make sure folks could get the time
set quickly.
Svein> The other camp consists mostly of people in the operations
Svein> environment. A lot of them doing remote management of servers. In
Svein> this camp, any additional time in the boot sequence is both wasted
Svein> time, and a nightmare because you always have that nagging "what will
Svein> go wrong THIS time" when you remote reboot anything. I've been there,
Svein> and I know the feeling.
Me too, and this is similar to Occam's Razor. We now have the variety of
tools (mechanism) to give folks what they need to make things work as
quickly as possible given the varying needs of their circumstances
(policy).
We are not dictating policy.
We are offering robust mechanism to let you choose the best way to
accomplish your goals.
If you (for some definition of 'you') think we are missing something, then
why has nothing more been added to the DeprecatingNtpdate page?
To my knowledge, we have addressed *all* of the concerns that have been
raised there.
Svein> For the operations people, ntpdate is a supplement to ntpd, not a
Svein> replacement. They run ntpdate to get log timestamps +-1millennium
Svein> correct, then get on with their boot and throw ntpd into the
Svein> background to keep timestamps somewhat trusty.
That is *your* need, and it can be done by using sntpd instead of ntpdate,
at least for the application you have described.
Some folks require stable time (for some definition of 'stable') before
declaring a machine ready for use. We have that capability too.
One thing that I think may be missing is an option to say "it's OK to step
time forward, but time cannot be stepped backward."
Svein> Thus, they want ntpdate, or a script just as fast. 'ntpd -q -g' is
Svein> NOT the solution to their problem. Period. A script converting
Svein> ntpdate parameters into 'sntp -r' MAY be the solution.
I think 'sntp -r' *is* the solution to setting the time once, quickly, and
if anybody disagrees then they should pipe up.
If folks want the time set *well* and they want the clock to be stable
before they release the machine to general use, we already have the ntp-wait
script.
This should all be covered in http://support.ntp.org/Support/StartingNTP4,
and if it is not it is easily corrected.
Svein> However the real problem here is the fundamentalists that seem to
Svein> want ntpdate gone totally. This is a problem I'm afraid noone here
Svein> can help them with. If they have religious reasons for wanting
Svein> something done or gone, I suggest talking to a cleric about
Svein> them. Sorry if I've insulted anybody with this.
I'm not sure exactly what you mean.
The current ntpdate program is broken. Nobody has offered to work on it.
This situation has been going on for *years*.
Conscientious people have studied the issues with great deliberation and
care, and have come up with more flexible and better quality solutions.
I expect there will be an ntpdate script that will "do the right thing" for
most of the cases.
If there is a case where the defaults are wrong, it will be pretty easy for
the local admin team to use the "robust mechanism" we are providing to
implement whatever local "policy" they require in a way that meets or
exceeds the way the current broken ntpdate does.
If you disagree with this I'm really curious to know why.
So far I've seen whining and FUD, but no tangible cases of counter-examples.
I have spent a Very Long Time in the sysadmin business, and I go many extra
miles to make sure that the mechanism we provide will handle as many cases
as we can. I believe we have already significantly increased the number of
cases we can support, and I would appreciate any contributions (either ideas
or code) to make things even better.
And there are cases where ntpd is just not the right answer for some people.
Lipstick on a pig, if I may use that metaphor.
David J Taylor
[]
> Without my looking at the code or the RFC, I believe this means it
> will send a request to the listed host(s) and set the time to the
> first answer it receives, and then exit. If the time is stepped it
> will DTRT regarding writing appropriate accounting messages
> (utmp/wtmp, as appropriate). It will support at least one of the
> specified authentication mechanisms.
Harlan,
DTRT = ?
David
Hal Murray
>DTRT = ?
Do The Right Thing
--
These are my opinions, not necessarily my employer's. I hate spam.
David J Taylor
>> DTRT = ?
>
> Do The Right Thing
Thanks, Hal. I've not seen that one before!
Cheers,
David