[ntp:questions] ntpd (4.2.2p1) stays "synchronized to LOCAL"

David Woolley david at djwhome.demon.co.uk
Tue Dec 5 07:52:00 UTC 2006

In article <tLadnW4n2o3aQOnYnZ2dnUVZ_qqdnZ2d at comcast.com>,
Richard B. Gilbert <rgilbert88 at comcast.net> wrote:
> Jordan Russell wrote:

>      remote           refid      st t when poll reach   delay   offset
> jitter

>  ntp-2.gw.uiuc.e   2 u  442 1024  377   56.901  16496.2
> 8492.19
> *LOCAL(0)        .LOCL.          10 l   49   64  377    0.000    0.000
>  0.001

> Another odd thing is that your poll interval seems locked at 1024 
> seconds when, given the humongous offset, I'd expect to see polling at 
> 64 second intervals.  With a polling interval that large, it may take 

The poll interval is 64 seconds.  ntpd sets the poll intervals of 
rejected sources to maxpoll.  They are being rejected because the jitter
appears too high, which is a result of the high time slew rate (frequency
error) causing different samples to vary greatly in offset.

This also raises the question of why the local clock was configured
in the first place.  If it had not been, ntpd would have correctly
detected that it was in a hopeless situation and would have reported
unsynchronised and eventually shut down.  In my view, most people shouldn't
configure the local clock, and those that do should have thought carefully
about it.

More information about the questions mailing list