[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:
> 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=, srcport=123, dstadr=, 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

>> 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.


More information about the questions mailing list