[ntp:questions] ntpd keep trying preferred servers?

Seth Seeger sseeger at gmail.com
Wed Sep 7 13:21:07 UTC 2011


On Tuesday, September 6, 2011 4:12:01 PM UTC-4, David Woolley wrote:
> Seth Seeger wrote:
> 
> >      remote           refid      st t when poll reach   delay
> > offset  jitter
> > ==============================================================================
> > *LOCAL(1)        .LOCL.          12 l    6   64  377    0.000
> > 0.000   0.001
> >  rds1            10.1.3.2        14 u  538 1024  377    0.148
> > -0.474   0.065
> >  rds2            10.1.3.2        14 u  892 1024  377    0.138
> > -1.210   0.099
> 
> You need the billboards for rds1 and rds2.  It looks to me as though you 
> have a timing loop.  You do know that you should never have more than 
> one local clock driver in any loop cycle?  (These days you should use 
> orphan mode, instead.)

rds1 and rds2 are the two client machines, polling the server (10.1.3.2).

I'm pretty sure my problem was that the external DNS was not available at the time ntpd started up.  I now understand from some bug reports that ntpd won't re-try a host if it can't resolve the DNS name.  I've since restarted it, and it now looks like this, which I believe is right:

$ ntpq -pcrv mcc
assID=0 status=06c4 leap_none, sync_ntp, 12 events, event_peer/strat_chg,
version="ntpd 4.2.4p4 at 1.1520-o Sun Nov 22 16:14:34 UTC 2009 (1)",
processor="x86_64", system="Linux/2.6.26-2-amd64", leap=00, stratum=2,
precision=-20, rootdelay=240.335, rootdispersion=99.455, peer=824,
refid=192.148.93.25,
reftime=d211e6dc.84f8e1f8  Wed, Sep  7 2011 12:49:32.519, poll=10,
clock=d211eddd.5b1d8b56  Wed, Sep  7 2011 13:19:25.355, state=4,
offset=-27.326, frequency=3.774, jitter=3.893, noise=14.715,
stability=0.930, tai=0
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*ntphost.arm.gov .GPS.            1 u  767 1024  377  240.335  -27.326   3.893
 abyss.simplysam .STEP.          16 u    - 1024    0    0.000    0.000   0.000
 LOCAL(1)        .LOCL.          12 l   40   64  377    0.000    0.000   0.001

If the first two servers become unavailable, it should choose LOCAL.


> By the way, ntpd never synchronises to the itself.  The local clock is a 
> hack that prevents the root dispersion tending to infinity on an 
> isolated system, but it is not an input to the timing calculation as it 
> has an offset of zero, by definition.

If I understand it correctly, the LOCAL hack just means that the server (10.1.3.2) will hand out the time, even if it itself hasn't been sync'd.  This is perfect, since really what I care about is perfect time between the server and rds1 and rds2.

Thanks!
Seth




More information about the questions mailing list