> Le 20 oct. 2016 à 22:06, Hal Murray <[email protected]> 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 _______________________________________________ time-nuts mailing list -- [email protected] To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
