[ntp:questions] ntpdate removal is coming
Harlan Stenn
stenn at ntp.org
Sat Dec 17 22:36:06 UTC 2011
Chad wrote:
> The scenario I'm worried about somewhat different from what has been
> described in this thread. I though I would add it to the chain as a use
> case developers should be aware of.
>
> I frequently see incorrect time after a system has been powered off or
> even just booted. The amount of time varies and typically less than a
> second, but sometimes much more.
This has nothing to do with the current ntpdate code being deprecated.
You are seeing the problem of a bad (or no) TOD clock.
Current ntpd handles this just fine.
There's more...
> Following is an example of why I want to just quickly set the time on a
> boot. Booting up around 15:30, ntpd starts. Twenty minutes later, ntpd
> is ready to use its -g option and resets time. This fixes the error that
> occurred while the system was down. Before and after the boot, ntpd
> manages time with small drift values and no time resets.
I'm real curious why it takes 20 minutes for ntpd to set the time.
> But I can not afford to have time reset by -4 seconds after my
> applications have been running for 20 minutes. I also can not wait for 20
> minutes to start running applications.
Right.
> I don't care if the command to set system time from the timeservers is
> ntpdate or ntpd -gq. My two requirements are 1) to set a time that will
> be close enough for ntpd to manage without resets and 2) to set that time
> within a few seconds of being run.
Should be pretty easy, depending on your definition of "a few
seconds"...
> Nov 20 15:30:06 ntpd[4969]: ntpd 4.2.2p1 at 1.1570-o Tue Feb 10 22:33:50 UTC
> 2009 (1)
This version of NTP was released in June of 2006. There have been 2
major releases of NTP since then - 4.2.4 and 4.2.6. *Many* bugs have
been fixed sinc then.
> Nov 20 15:30:06 ntpd[4971]: precision = 1.000 usec
> . . .
> Nov 20 15:30:06 ntpd[4971]: kernel time sync status 0040
> Nov 20 15:30:06 ntpd[4971]: frequency initialized 18.666 PPM from
> /var/lib/ntp/drift
> Nov 20 15:34:00 ntpd[4971]: synchronized to LOCAL(0), stratum 10
Why are you running a LOCAL refclock? This is the reason it is taking
you 20 minutes to sync when you have found another time source.
> Nov 20 15:34:00 ntpd[4971]: kernel time sync enabled 0001
> Nov 20 15:35:05 ntpd[4971]: synchronized to 192.90.175.9, stratum 2
> Nov 20 15:49:57 ntpd[4971]: time reset -4.358850 s
> Nov 20 15:53:23 ntpd[4971]: synchronized to LOCAL(0), stratum 10
Again, I'm not seeing why you should be running the LOCAL refclock - its
presence is causing you problems.
> Nov 20 15:55:34 ntpd[4971]: synchronized to 192.90.175.9, stratum 2
I recommend you try the latest ntp-dev code and fix your ntp.conf file.
H
More information about the questions
mailing list