[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