[time-nuts] leontp offset

[Mike Cook]

> 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.
 129.6.15.28     .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.
 128.138.140.44  .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 128.138.140.44 , a UTC server and which is in the same server room and on the same net as Nut1 ( 128.138.140.50 ) 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