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.

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.

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.

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.

Nov 20 15:30:06 ntpd[4969]: ntpd [email protected] Tue Feb 10 22:33:50 UTC 
2009 (1)
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
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
Nov 20 15:55:34 ntpd[4971]: synchronized to 192.90.175.9, stratum 2

If Notes or I don't get this message correctly into the thread, I 
apologize.

_______________________________________________
questions mailing list
[email protected]
http://lists.ntp.org/listinfo/questions

Reply via email to