[ntp:questions] Re: Help needed with excessive drift

Tom Smith smith at cag.lkg.hp.com
Thu May 5 23:32:56 UTC 2005


mlawdawg at yahoo.com wrote:
> I'm running on vxWorks, which doesn't have adjtime().
> 
> All the hw I run has a battery backed RTC, so the time is "close" to
> correct after system reboots. In all my tests, the system's time before
> starting ntpd is within ~200secs of the correct time.

Yes, well that's not close enough. You should be within 128 msec
before you start ntpd.

> 
> For the record, I'm was doing the following:
> 
>>reboot
>>delete ntp.drift
>>start ntpd

You need to insert "ntpdate -b [server]" before you start ntpd.
If you don't have an ntpdate, insert an "ntpd -gq" before you
delete ntp.drift. Note, however, that if the initial offset is
already less than 128 msec, "ntpd -gq", as far as I know, can exit
with the time not actually set, but with a slew active that, only
when completed, will have set the time. There is no way I know of
to wait until that slew is completed before starting ntpd normally,
but in most cases it shouldn't matter.

> 
> 
> Within 15 minutes, the system time would be "stepped", via
> "step_systime" adjustment. On vxWorks, this results in a call to
> clock_settime(). After 8-16 hours, I would see the freq drift to -500.

That's quite common if you don't get the time close enough before
ntpd starts and/or if the stored drift is already bad.

> 
> I don't have the ntpdate program ported, but I can run ntpd with "-q"
> to simulate ntpdate. Doing so after a reboot results in the time being
> stepped by less than 200 secs, which correlates with what I saw by
> visually comparing times.
> 

And if you then delete ntp.drift and _then_ start ntpd?

-Tom



More information about the questions mailing list