[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