[ntp:questions] Re: Which public servers for adjustment?

Richard B. Gilbert rgilbert88 at comcast.net
Mon Dec 20 22:27:24 UTC 2004


Helmut Wollmersdorfer wrote:

> Each of my two servers has 3 radio clock receivers (DCF77, HBG75, MSF60).
>
> Calibrating against two stratum 1 servers gave around 40ms delay. 
> Other radioclockd users here reported values around 20ms.
>
> Here is a typical result of ntpq -d one hour after restart and more 
> public servers than necessary:
>
> via2:~# ntpq -p
>      remote      ... st t when poll reach   delay   offset  jitter
> =================...==============================================
> -ntp1.esat.net   ...  1 u   96  128  377   60.335  -15.919   5.050
> -ntp1.ien.it     ...  1 u  104  128  137   82.738    6.799   3.418
> -212-82-32-15.ip ...  1 u   10  128  377   72.336    3.288   3.574
> -192.168.0.10    ...  1 u  115  128  377    0.227   -3.985   0.140
> *SHM(0)          ...  0 l   91  128   77    0.000    1.035   0.495
> +SHM(1)          ...  0 l   20   64  373    0.000    0.739   2.203
> +SHM(2)          ...  0 l   87   64  376    0.000   -0.637   1.000
> -nav.metrologie. ... 14 u   24   64  377   15.396  -13.001   9.449
> xmbox.eunet.at   ...  2 u   22  128  377   12.494   43.665   5.553
> -orfroufh5.apa.n ...  2 u   16  128  377   14.235  -14.594   7.367
> -ntp2.ptb.de     ...  1 u   22  128  377   33.400  -13.700   4.573
>  LOCAL(0)        ... 13 l   14   64  377    0.000    0.000   0.004
>
> SHM(0) is DCF77 with "prefer" in ntp.conf.
> esat.net is from pool.ntp.org.
> ien.it and 212-82-32-15 are the servers used for calibration.


I would not rely on either of these servers to calibrate anything!  The 
delay figures of 82 and 72ms are both large enough to allow a lot of 
room for error!  The packets returned by these servers have four time 
stamps: the time the request left your server, the time the request 
arrived at the remote server, the time the response left the remote 
server and the time it arrived at your server.  The only thing you can 
be certain of is that the two timestamps added by the remote server 
occurred somewhere in the interveral between the request timestamp and 
the arrival timestamp.  In an ideal world they should be very near the 
middle of the interval.  The world, however, is seldom ideal and the 
outgoing and incoming network delays are almost certainly not exactly 
symmetrical.

I'd suggest calibrating against the servers with the lowest delay and 
jitter and comparing with the calculated propagation delays from DCF77, 
MSF60, and HBG75

If you need better time than that your options are to make GPS an option 
somehow or to buy a rubidium or cesium frequency standard with a clock 
option and have it calibrated by your national standards laboratory!

>
> Looking to the offsets above there are two groups of public servers:
> 1) -13 to -16 ms
> 2)  +3 to  +7 ms
>
> The difference between 1) and 2) is around 20ms.
>
> What's the correct time?
> To use GPS is not possible.
>
> Will it help to remove "prefer" for some hours from SHM(0), and 
> specify  a low stratum, to let the references "fight" against each 
> other within ntp's logic?
>
> Helmut Wollmersdorfer

I would not use "prefer" unless you are much closer to one of your radio 
sources than to the other two. 



More information about the questions mailing list