On Wed, 11 Jul 2001, Alex Zepeda wrote:

> On Wed, Jul 11, 2001 at 01:23:00AM -0400, John wrote:
>
> > I've heard that some systems won't run ntpd if the time is off too much  -
> > that ntpd gets confused or something. Anyone else care to speak of
> > experiences of running ntpd on machines with really screwed clocks?
>
>
> Well I get:
>
> Jun 21 17:58:54 sproing ntpd[151]: Connection re-established to 192.6.38.127
> Jun 21 18:18:33 sproing ntpd[151]: time reset -9.894210 s
> Jun 21 18:18:33 sproing ntpd[151]: synchronisation lost
> Jun 21 18:45:53 sproing ntpd[151]: time reset 5.757709 s
> Jun 21 18:45:53 sproing ntpd[151]: synchronisation lost
> Jun 21 19:05:33 sproing ntpd[151]: time reset 5.845915 s
> Jun 21 19:05:33 sproing ntpd[151]: synchronisation lost
> Jun 21 19:15:34 sproing ntpd[151]: synchronisation lost
> Jun 21 20:04:58 sproing ntpd[151]: time reset 16.222224 s
> Jun 21 20:04:58 sproing ntpd[151]: synchronisation lost
> Jun 21 20:24:20 sproing ntpd[151]: time reset 4.055793 s
> Jun 21 20:24:20 sproing ntpd[151]: synchronisation lost
> Jun 21 20:43:46 sproing ntpd[151]: time reset 4.663886 s
> Jun 21 20:43:46 sproing ntpd[151]: synchronisation lost
>
> and such...
>
> But ntpd seems to keep it in check pretty well.

What's happening is that you get over the "step" interval -- about
128mS -- so quickly that the PLL basically does nothing. The failsafe
(if you want to call it that) kicks in after the "step-out" interval
-- about 20 minutes -- of free-wheeling, steps to the very next sync,
and pegs out the frequency correction to the maximum of +500mS (which
is why you actually step backwards from time to time).

With performance like that, you're no better off running "ntpd", than
running "ntpdate" periodically.


Frederick