time to retire ntpdate?
Harlan Stenn
keep the existing ntpdate program around?
H
George Dau
]So with the new functionality of ntpd, is there any reason we should
]keep the existing ntpdate program around?
I use it. I sync one machine here once a week over the WAN using ntpdate. Other
things sync to it via normal ntpd. Can I get the new ntpd to "hard sync"
straight away like ntpdate does?
I can only use the WAN for this for a very short time (policy, not tech
problem).
Harlan Stenn
> I use it. I sync one machine here once a week over the WAN using
> ntpdate. Other things sync to it via normal ntpd. Can I get the new
> ntpd to "hard sync" straight away like ntpdate does?
Depends on your definition of "straight away".
Would you please try using the appropriate options to ntpd (it's
supposed to be documented on the web pages, and I believe that recent
releases of the code also have a man page conversion script) and see if
they work for you?
H
Nelson Minar
> So with the new functionality of ntpd, is there any reason we should
> keep the existing ntpdate program around?
I'm not sure what the new functionality of ntpd is, but having ntpdate
is really handy because you can run it without the overhead of a
stateful daemon. Some things I use it for:
Uses of ntpdate for setting clock:
1. Sync my clock on system startup, before starting ntpd.
2. Poor man's sync - "while true; do ntpdate host; sleep 3600; done"
(Sometimes this is preferable to a daemon)
Uses of ntpdate -q for testing clocks:
3. Check that my clock is reasonably well synchronized to a stratum 1
4. Check that my clock is synced well with another random NTP host that I
don't normally talk to.
I could probably do all these things with ntpd, but it's not always
convenient to do so.
PS - anyone else see that a New York Times Q&A article today
recommended talking directly to tick.usno.navy.mil? Oops.
nel...@monkey.org
. . . . . . . . http://www.media.mit.edu/~nelson/
David L. Mills
We really, really want to deepsix ntpdate. It is a pain to maintain, the
code is twelve years old and the algorithms magnificently flawed. What
we need is a plain simple SNTP client which does nothing whatsoever
other than send out a packet, receive the reply, arm adjtime() and go
away. It would do absolutely nothing fancy except maybe prettypring the
reply packet for debug. Any takers?
Dave
Per Hedeland
<mi...@udel.edu> writes:
>
>We really, really want to deepsix ntpdate. It is a pain to maintain, the
>code is twelve years old and the algorithms magnificently flawed. What
>we need is a plain simple SNTP client which does nothing whatsoever
>other than send out a packet, receive the reply, arm adjtime() and go
>away. It would do absolutely nothing fancy except maybe prettypring the
>reply packet for debug. Any takers?
Sorry, I'm not a taker, but to give my personal answer to Harlan's
question in light of the above: Once an actual replacement for ntpdate
is available, I have no objection to retiring ntpdate (though I guess it
would make the most sense to let that replacement inherit the name
"ntpdate"). Since the replacement doesn't currently exist, I think
retirement of ntpdate at this point would be a Bad Idea.
And no, 'ntpd -q' is not a realistic replacement for ntpdate. When I
tried it on my system with a "vanilla" ntp.conf, it used 3 minutes and
20 seconds to do the job that ntpdate does in under a second, which is
simply absurd. Adding 'iburst' to my server lines gets that time down to
43 seconds, which is still ridiculously long - it would about double the
boot time for a typical Unix-PC, with no gain that would interest the
average user ((s)he would probably think that the boot has hung).
If I'm missing something in how ntpd is supposed to replace ntpdate's
functionality of quickly setting a "mostly correct" time at boot (before
starting ntpd in "normal" mode), please enlighten me. And in case it
isn't obvious from the above, I do make the assumption that the
reference NTP implementation is intended to be useful for the "average
user".
--Per Hedeland
p...@hedeland.org
George Dau
I have worked around it using minpoll and the burst stuff. Still creates more
traffic than ntpdate and takes longer to sync, but I think it will be Ok so
long as it doesn't loose sync very often - and I don't think it will.
--
,-,_|\ George Dau.
/ * \ gedau at isa dot mim dot com
\_,--\_/ I live in .au, you need to add that
v to the end of my e-mail address above.
David L. Mills
The ntpd -q scheme was never intended for casual PC use. There are
several sources for SNTP clients for those machines. Sadly, there is no
portable Unix equivalent known to me, for if there were and it could be
included in the NTP software distribution, ntpdate would be gone
tomorrow.
Actually, ntpdate is welcome to stay, but only if it was stripped to the
bone, used only the hard core I/O and did't do anything at all other
than send a packet, receive a packet and set the clock. That's what it
originally did, but over the years millions of evil fingers poked the
code, fiddled broken approximations to the ntpd algorithms and generally
made it near impossible to maintain.
Now, lets hear it for ntptime. I don't know how it got in the
distribution, but I want to off it, too. When you maintain this bag of
tricks over almost two decades, you really, really, need to simplify
life.
Dave
David L. Mills
The ntpdate sends four packets at one-second intervals; the ntpd -q
normally requires only four packets, and these are sent at two-second
intervals. Try the Windows XP client; for some reason it waits 30 s
before sending a sincle packet. The ntpd -q with three servers sets the
clock with four packets to each server in 17 s.
Something is being lost here. The ntpd design philospohy has always been
rock-hard reliability, security, diversity and redundancy, even in the
face of broken networks or servers or bad hearted villians. The ntpdate
hardness on these ilities is something less than a rock and rather more
like a sponge. The ntpd model places certain constraints on the design
to allow the algorithms to function as intended. The intent of ntpd -q
(with iburst) was to provide the same security and reliability in
one-off mode as in ordinary continuous mode.
There are lots of folks who don't need, or think they don't need until
something wicked happens and their database cache disappears, something
as heavy and for them there is SNTP and that's why I wrote the RFC and
expected a zillion Unix SNTPs to erupt within the fortnight. Actually
they did; but all, so far as I know, are shareware for the PC.
Dave
George Dau
]George,
]
]The ntpdate sends four packets at one-second intervals; the ntpd -q
]normally requires only four packets, and these are sent at two-second
]intervals. Try the Windows XP client; for some reason it waits 30 s
]before sending a sincle packet. The ntpd -q with three servers sets the
]clock with four packets to each server in 17 s.
]
]Something is being lost here.
<snip>
Yes, it was. Thanks for the update. I now have a new version of ntpd and have
decided to move away from the one-off sync model to a low traffic, low impact
permanant sync. Our requirement was that the times be similar, as opposed to
correct.
Last time I messed around with this, nptd took much longer to sync.
David L. Mills
I've found ways to speed things up in recent versions without
compromising ilities and without abusing servers. I've got it down to
something like five seconds now with multiple servers and all the
algorithms lit. That will be in the developement repository soon.
One of the things slowing things has been a wait for modems to connect.
I put in a calldelay command that sets the delay between the first and
second packets sent, which defaults to two seconds. Modem users will
need a calldelay command to set that delay to match the callup time.
Dave
David L. Mills
I've found ways to speed things up in recent versions without
compromising ilities and without abusing servers. I've got it down to
something like five seconds now with multiple servers and all the
algorithms lit. That will be in the developement repository soon.
One of the things slowing things has been a wait for modems to connect.
I put in a calldelay command that sets the delay between the first and
second packets sent, which defaults to two seconds. Modem users will
need a calldelay command to set that delay to match the callup time.
Dave
Per Hedeland
<mi...@udel.edu> writes:
>
>The ntpd -q scheme was never intended for casual PC use. There are
>several sources for SNTP clients for those machines. Sadly, there is no
>portable Unix equivalent known to me, for if there were and it could be
>included in the NTP software distribution, ntpdate would be gone
>tomorrow.
Well, I wasn't talking about "casual" PCs (whatever that may be:-) in
particular, and specifically mentioned ones running Unix (of course it's
really more interesting how long it takes for a Windows box to boot
since it will happen way more often, but I don't care about that).
For better or worse, the vast majority of computers these days, whether
"personal" or small-to-medium servers, seem to be of the architecture
that is commonly called "PC". Thus I think it's a reasonable requirement
on such a "server PC" (as well as on any other server of course) that a)
it doesn't take forever to boot, and b) time doesn't jump around after
applications have started - which is what the traditional ntpdate+ntpd
approach normally achieves.
>Actually, ntpdate is welcome to stay, but only if it was stripped to the
>bone, used only the hard core I/O and did't do anything at all other
>than send a packet, receive a packet and set the clock.
That sounds like an excellent model to me, though perhaps a little more
than one packet may be needed:-) - the packet may get lost, the server
that is supposed to respond may be down... *That* part of ntpdate seems
reasonable to me - four packets (maybe two would be enough) to each of a
specified list of servers (maybe read from ntp.conf), and at least my
version sends the next packet as soon as the previous response has come
in, the 1-second being a timeout in case no response comes back (sending
to all servers in parallell would be an obvious improvement).
>Now, lets hear it for ntptime. I don't know how it got in the
>distribution, but I want to off it, too. When you maintain this bag of
>tricks over almost two decades, you really, really, need to simplify
>life.
I've never used it.:-)
--Per Hedeland
p...@hedeland.org
Rob MacGregor
> You don't understand my level of pique. My ideal SNTP client sends _one_
> packet and expects _one_ reponse and then goes away. No retries, no
> multiple servers, nada. It runs on everything from Unix to Windows to
> toaster ovens. Same model as Windows XP client, for that matter. You
> want something more than that, then you run the whole enchilada.
How about a compromise to support the case when that single server is
down/unavailable/whatever?
Either send *up to* 4 packets to that single host (stopping as soon as you get
a response), or supporting up to 4 servers, each getting a single packet sent
to them? No fancy calculations done, the first returned time packet is the one
that's assumed to be valid and is used.
That should keep it simple while retaining some protection from dead hosts,
losing packets or whatever.
--
Rob MacGregor (MCSE)
The light at the end of the tunnel is an oncoming dragon.
David L. Mills
Let's use tftp as example. I wouldn't mind retransmiting a few times,
since even the most primitive program would have to wait for a packet to
come back and give up if nothing heard. However, I'm against anything
further than that, because then you have to defend judgement calls and
defend against feature creep.
Dave
David L. Mills
Let's use tftp as example. I wouldn't mind retransmiting a few times,
since even the most primitive program would have to wait for a packet to
come back and give up if nothing heard. However, I'm against anything
further than that, because then you have to defend judgement calls and
defend against feature creep.
Dave
Rob MacGregor
> Rob,
>
> Let's use tftp as example. I wouldn't mind retransmiting a few times,
> since even the most primitive program would have to wait for a packet to
> come back and give up if nothing heard. However, I'm against anything
> further than that, because then you have to defend judgement calls and
> defend against feature creep.
IHMO that would be sufficient, especially as I always use ntpdate against a single
host. Avoids the risk of packet loss nicely.
Terje Mathisen
>
> "David L. Mills" wrote:
>
> > Rob,
> >
> > Let's use tftp as example. I wouldn't mind retransmiting a few times,
> > since even the most primitive program would have to wait for a packet to
> > come back and give up if nothing heard. However, I'm against anything
> > further than that, because then you have to defend judgement calls and
> > defend against feature creep.
>
> IHMO that would be sufficient, especially as I always use ntpdate against a single
> host. Avoids the risk of packet loss nicely.
IMHO, a good ntpdate would read ntp.conf, locate the N first server/peer
lines and immediately send out queries to all of them in parallel. (Skip
any 127.* addresses)
The first packet to return would cause the clock to be set, and the
program to exit.
If there are less than N servers, start again from the top after a 100
ms wait.
It seems like this should be doable in less than 200 lines of code,
modulo cross-platform #ifdef's, with half the code in the ntp.conf
parsing, which could be shared with the main ntpd program.
Alternatively, allow a list of servers on the command line, and use perl
to construct this on-the-fly, based on the ntp.conf contents.
Acceptable feature creep would be an option to specify maximum waiting
time (say 1000 ms), and accept all replies which arrive within this time
frame, before throwing out outliers/false-tickers.
This would keep the impatient users happy, while avoiding the kind of
trouble we had here where a server was rebooted, and the primary server
had just suffered a Y2K-related bug in leap year handling: This caused
the time to be 24 hours wrong, which meant that the server would from
then on see the false-ticker as the only sane time server, and all
others as hopelessly bad.
Terje
--
- <Terje.M...@hda.hydro.com>
"almost all programming can be viewed as an exercise in caching"
David L. Mills
You just gave a wonderful description of ntpd -q. However, '-q is a
little more clever than that; it runs the mitigation algorithms along
thw way to toss out falsetickers, etc.
So, I rest my case. Dumb tftp model at the low end, '-q at the high end.
No need for anything in the middle. You either get fast food or a
banquet.
Dave
David L. Mills
You just gave a wonderful description of ntpd -q. However, '-q is a
little more clever than that; it runs the mitigation algorithms along
thw way to toss out falsetickers, etc.
So, I rest my case. Dumb tftp model at the low end, '-q at the high end.
No need for anything in the middle. You either get fast food or a
banquet.
Dave
Terje Mathisen
>
> Terje,
>
> You just gave a wonderful description of ntpd -q. However, '-q is a
> little more clever than that; it runs the mitigation algorithms along
> thw way to toss out falsetickers, etc.
Sorry, I don't agree: Afaik running the mitigation algorithms is exactly
what cause it to have a minimum running time far in excess of a second
or so. (If this has changed, I'll apologize.)
> So, I rest my case. Dumb tftp model at the low end, '-q at the high end.
If something like
ntpd -qq
could cause it to actually run in a second, while still detect and
discard a badly wrong falseticker, I would be very happy.
> No need for anything in the middle. You either get fast food or a
> banquet.
Personally a prefer a regular place most of the time, the $150 dollar
menues at top restaurants are seldom required.
:-)
Bob Rahe
Terje Mathisen <terje.m...@hda.hydro.com> wrote:
>"David L. Mills" wrote:
>>
>> Terje,
>>
>> You just gave a wonderful description of ntpd -q. However, '-q is a
>> little more clever than that; it runs the mitigation algorithms along
>> thw way to toss out falsetickers, etc.
>
>Sorry, I don't agree: Afaik running the mitigation algorithms is exactly
>what cause it to have a minimum running time far in excess of a second
>or so. (If this has changed, I'll apologize.)
>
>> So, I rest my case. Dumb tftp model at the low end, '-q at the high end.
>
>If something like
>
> ntpd -qq
>
>could cause it to actually run in a second, while still detect and
>discard a badly wrong falseticker, I would be very happy.
I would agree. I use, and I think others do also, an init script
for when the system reboots that does an ntpdate with a couple of
servers specified and then runs the daemon. This only takes a couple
of seconds to do. Running ntpd -q takes about 4 minutes or so as it
collects packets. I'd rather not have to wait the 4 minutes during boot
time. A quick set would be nice.
--
----------------------------------------------------------------------------
|Bob Rahe, Delaware Tech&Comm Coll. / |
|Computer Center, Dover, Delaware / |
|Internet: b...@dtcc.edu (RWR50) / |
----------------------------------------------------------------------------
Harlan Stenn
> ... Running ntpd -q takes about 4 minutes or so as it
> collects packets. I'd rather not have to wait the 4 minutes during boot
> time. A quick set would be nice.
I bet you are not using iburst.
I haven't used -q yet; I fire up "ntpd -g -N high" as early as possible
in the boot sequence and then run "ntp-wait -v" as late as possible in
the boot sequence (before starting step-sensitive applications).
Once ntp.drift is OK I find that it takes about 30 seconds for ntp-wait
to indicate that ntpd is in state 4. The clock has been set before
that, however.
H
Terje Mathisen
>
> In article <3D5906DF...@hda.hydro.com>,
> Terje Mathisen <terje.m...@hda.hydro.com> wrote:
> >If something like
> >
> > ntpd -qq
> >
> >could cause it to actually run in a second, while still detect and
> >discard a badly wrong falseticker, I would be very happy.
>
> I would agree. I use, and I think others do also, an init script
> for when the system reboots that does an ntpdate with a couple of
> servers specified and then runs the daemon. This only takes a couple
> of seconds to do. Running ntpd -q takes about 4 minutes or so as it
> collects packets. I'd rather not have to wait the 4 minutes during boot
> time. A quick set would be nice.
Since I mostly have one nearby (internal) server where I set minpoll 4,
as well as burst and iburst, this startup time isn't nearly that long,
but still significantly more than the ntpdate that it is supposed to
replace.
Rob MacGregor
> I would agree. I use, and I think others do also, an init script
> for when the system reboots that does an ntpdate with a couple of
> servers specified and then runs the daemon. This only takes a couple
> of seconds to do. Running ntpd -q takes about 4 minutes or so as it
> collects packets. I'd rather not have to wait the 4 minutes during boot
> time. A quick set would be nice.
Which is what's being discussed. The aim (from what I understand) is that the
ntpdate replacement will be simple and compact. It's just designed to get the
time "about right", quickly. Then you'll start ntpd (probably with the -g
option so it'll correct large time errors) and get the time set accurately.
Bob Rahe
>> ... Running ntpd -q takes about 4 minutes or so as it
>> collects packets. I'd rather not have to wait the 4 minutes during boot
>> time. A quick set would be nice.
>I bet you are not using iburst.
Yeppers. Set it on one of the server lines and it's just about 33
seconds. I'll use it! Tnx,
Bob
Harlan Stenn
"ntpd -g -N high" early in the boot sequence and, if needed, ntp-wait
before starting step-intolerant services late in the startup sequence?
H
David L. Mills
Current development version takes less than ten seconds at two seconds
between polls. I would think nude SNTP would take just as long, assuming
it coddles the server as I think necessary.
Dave
David L. Mills
While I do admit the development version has had a few tweaks that
reduce the joy time to less than ten seconds, it never took four minutes
if you followed advice and set the iburst configuration option. For like
40 seconds.
Dave
Joe Doupnik
A candid answer contains these elements:
ntpdate is fast, does just what we expect, and is simple to run.
ntpd -gibberish is poorly documented at best and has a reputation
for not doing the job quickly. Html docs might as well not exist when
we get to the crunch phase of things; man pages do exist.
I think a bunch of the community wants time set correctly, right
now, not waiting minutes for nicities and curiosity effects to disappear.
It means what it says: set the darned thing, bang, and don't expect some
other gibberish command to be required later in a script. Complexity at
the operator level for this activity is to almost guarantee it won't
happen.
You did ask. We do think this way.
Joe D.
Harlan Stenn
> In article <o4fzxg3...@whimsy.udel.edu>, Harlan Stenn <st...@whimsy.udel.edu> writes:
> > Why do folks want to use ntpd -q (whatever) followed by ntpd instead of
> > "ntpd -g -N high" early in the boot sequence and, if needed, ntp-wait
> > before starting step-intolerant services late in the startup sequence?
> >
> > H
> --------
> A candid answer contains these elements:
> ntpdate is fast, does just what we expect, and is simple to run.
But I wasn't asking that question...
> ntpd -gibberish is poorly documented at best and has a reputation
> for not doing the job quickly. Html docs might as well not exist when
> we get to the crunch phase of things; man pages do exist.
The current ntp release will produce man pages. If the content is not
what you want, somebody can volunteer to fix it.
> now, not waiting minutes for nicities and curiosity effects to disappear.
> It means what it says: set the darned thing, bang, and don't expect some
> other gibberish command to be required later in a script. Complexity at
> the operator level for this activity is to almost guarantee it won't
> happen.
> You did ask. We do think this way.
No problem.
The ntp-wait is not required in most cases. It's only there for folks
with "higher" needs. When it is needed, its use can (and probably
should) be scripted.
If this stuff was easy/trivial, it wouldn't be hard.
The use of ntpdate and an "instantaneous" set can and has caused
problems when it does the wrong thing (because of an insane server).
One is just trading one set of problems for another.
H
David L. Mills
I read your message and carefully crafted what I thought was a
reasonable reply. Upon reading it and your message again, I conclude we
are indeed talking right past each other and any response would simply
restate the issues raised earlier in this thread.
Dave sends
John Lu
"ntpdate -u server_name" ? I imagine it's difficult for ntpd being a server
and client at the same time. But this feature of "ntpdate" is quite useful
for some boxes behind firewall.
Thanks!
John
"David L. Mills" <mi...@udel.edu> wrote in message
news:3D5C3D83...@udel.edu...
Harlan Stenn
How would one emulate "ntpdate -d somehost", with the intent being to
determine "how far off is my clock from that of somehost?"
H