[ntp:questions] Synchronizing against a free-running server
detha
detha at foad.co.za
Mon Apr 15 11:53:37 UTC 2013
On Mon, 15 Apr 2013 11:23:04 +0100, David Woolley wrote:
> detha wrote:
<snip>
> Is this w32time? w32time will send a true root dispersion, which will
> eventually disqualify the server. You will probably need to run the real
> reference ntpd with a local clock pseudo driver (something not otherwise
> recommended).
>
> In general, though, you will need to provide the ntpq rv output for the
> rejected server's association, to see why it is being rejected.
Alas yes, w32time. ntpq rv says:
ntpq> rv 1399
assID=1399 status=9014 reach, conf, 1 event, event_reach,
srcadr=10.55.17.245, srcport=123, dstadr=10.55.17.246, dstport=123,
leap=00, stratum=1, precision=-6, rootdelay=0.000,
rootdispersion=10802.399, refid=LOCL, reach=377, unreach=0, hmode=3,
pmode=4, hpoll=10, ppoll=10, flash=400 peer_dist, keyid=0, ttl=0,
offset=-124.961, delay=0.697, dispersion=34.222, jitter=41.139,
reftime=d515509e.59585f3c Sun, Apr 14 2013 17:58:22.349,
org=d5165a2a.eb856d92 Mon, Apr 15 2013 12:51:22.920,
rec=d5165a2b.162b3880 Mon, Apr 15 2013 12:51:23.086,
xmt=d5165a2b.15eab1f4 Mon, Apr 15 2013 12:51:23.085,
filtdelay= 0.98 0.70 0.80 0.58 0.61 1.09 0.00 0.96,
filtoffset= -166.10 -124.96 21.37 -181.69 -144.35 -0.09 41.00 -164.28,
filtdisp= 15.63 30.97 46.35 61.74 77.13 92.47 107.86 123.22
ntpq>
>
>> However I have not been able to convince it (neither 4.2.6p2 on debian
>> nor 4.2.4p8 on centos) to do this. The moment the windows server is set
>> to sync to anything (pool.ntp.org, some other server, ...) it works. But
>> as long at the server advertises itself as 'stratum 1, .LOCL.', ntpd
>> seems
>
> It is bad practice to use stratum one for the bogus local clock driver.
> If there is another valid method of disciplining the clock, a lowish
> stratum number is OK. If it is free-running, the stratum should be set as
> high as possile subject to being acceptable to all of its clients, so that
> it cannot accidentally propagate very far.
It's what w32time seems to do (I don't know too much about windows, so
maybe that can be tweaked)
This setup is at a remote site(remote as in 'intermittent connectivity,
sometimes a consistent ~200ms latency, sometimes 3G with huge latency
variations, sometimes nothing').
The whole setup needs about 500ms to 1 second accuracy, and at the
moment machines drift apart by 5 sec/day. I'm inclined to either just
leave it on 'hourly cron-job running ntpdate', or put together a box with
a Raspberry Pi and a GPS receiver and have it shipped out there.
-d
More information about the questions
mailing list