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@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
_______________________________________________
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
