Empathy List Archives

time-nuts@lists.febo.com

Discussion of precise time and frequency measurement

Re: [time-nuts] leontp offset

Hal Murray

Thu, Oct 20, 2016 8:06 PM

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.

What's worrying is that both arbiters off by the same-ish amount. This
indicates something systemic in the way we do things.

My guess is that the PPS is 10 ms wide and somebody is triggering on the
wrong edge. 10 ms is small enough that unless something like this happens
nobody would notice. (I wonder if they are selling into the financial
market.)

Are you getting time from the Arbiters via Ethernet or PPS over a serial
connection? If you are getting it via PPS, ntpd has a simple fudge flag to
use the other edge. If you are getting it via Ethernet, then the problem is
inside their box which make it harder to fix but also stranger that nobody
else noticed sooner.

--
These are my opinions. I hate spam.

> 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. > What's worrying is that both arbiters off by the same-ish amount. This > indicates something systemic in the way we do things. My guess is that the PPS is 10 ms wide and somebody is triggering on the wrong edge. 10 ms is small enough that unless something like this happens nobody would notice. (I wonder if they are selling into the financial market.) Are you getting time from the Arbiters via Ethernet or PPS over a serial connection? If you are getting it via PPS, ntpd has a simple fudge flag to use the other edge. If you are getting it via Ethernet, then the problem is inside their box which make it harder to fix but also stranger that nobody else noticed sooner. -- These are my opinions. I hate spam.

Mike Cook

Fri, Oct 21, 2016 10:11 AM

Le 20 oct. 2016 à 22:06, Hal Murray hmurray@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

> Le 20 oct. 2016 à 22:06, Hal Murray <hmurray@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