[time-nuts] leontp offset
michael.cook at sfr.fr
Fri Oct 21 06:11:40 EDT 2016
> Le 20 oct. 2016 à 22:06, Hal Murray <hmurray at megapathdsl.net> a écrit :
>> full disclosure: there were a couple of outlier external clocks I threw out,
>> one with a 38 ms offset and the other with a 112 ms offset).
> That's not uncommon. It happens more often when the server is farther away
> and there are more opportunities for strange network routing.
> The NIST servers in Gaithersburg MD (near Washington DC) have been off by 30
> ms for a while. There was a discussion on some list several months back. I
> forget which one.
Yes though I couldn’t find that thread. time-a.nist.gov appears to me also as 30+ms offset.
126.96.36.199 .ACTS. 1 u 5 16 77 151.600 33.212 0.161
I am also seeing systematic large offsets from another NIST server reported by NTP on clients with GPS PPS input.
188.8.131.52 .NIST. 1 u 6 16 377 126.938 -2.246 0.074
I had been monitoring the Nut1 UT1 time server in Boulder and was surprised when I detected a >2 ms difference between that reference and the NIST bulletin B UT1-UTC deltas.
Dr Judah Levine , who is providing the service, suggested that I monitor 184.108.40.206 , a UTC server and which is in the same server room and on the same net as Nut1 ( 220.127.116.11 ) and I discovered this systematic and remarkably stable offset ( 5.28 x 10^-6 ) and which explains the difference.
The unfortunate part is that the systematic offset that I see cannot be removed by any NTP « fudge » factor and is about the same magnitude as a days UT1-UTC difference as reported by Bulletin B. A real PITA.
I cannot think of any reason other than asymmetric path delay that could cause this, but the 33ms offset for the Gaithersburg server is huge.
« The power of accurate observation is commonly called cynicism by those who have not got it. »
George Bernard Shaw
More information about the time-nuts