On Wed, 31 May 2000, Manuel Bouyer wrote:

> On Wed, May 31, 2000 at 01:37:08AM -0700, Hal Murray wrote:
> > 
> > Only one clock glitch so far:
> >   May 30 13:43:20 hgm80d ntpd[167]: time reset 15.640742 s
> >   May 30 13:43:20 hgm80d ntpd[167]: synchronisation lost
> >   May 30 14:06:58 hgm80d ntpd[167]: time reset -0.393921 s
> >   May 30 14:06:58 hgm80d ntpd[167]: synchronisation lost
> > I think that was during one of the "easy" parts of my testing so
> > I don't understand what happened.
> 
> Does the GENERIC kernel have 'options NTP' ?

Assuming "yes", it's normal for ntpd to jerk the clock around a little
until it settles down, especially if it was 15 seconds off at bootup.
How is it now that it's had time to stabilize?

For machines that lose time when powered off, you could try setting
`ntpd_flags="-g"' in /etc/rc.conf. What that does, ntpd collects stats
for a few minutes, then steps to the best server one time (even if it
were within 250ms of that server), but doesn't reset the drift value;
then it proceeds as without. This is preferred to running "ntpdate" at
boot time, because the daemon gets to collect information from all the
servers, eliminate false-tickers, and so on. It works good on i386,
because the clock is only set to the nearest second on boot-up, but
once running, the drift doesn't really change from day to day.