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 [email protected] 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 _______________________________________________ questions mailing list [email protected] http://lists.ntp.org/listinfo/questions
