[time-nuts] ntp and asymmetric delays
tjv at westwood-tech.com
Tue Oct 11 13:09:29 EDT 2016
I was going to post my ntp output and ask for an opinion, then this
discussion popped up. It would appear that asymmetric delays are the
exact explanation for what I am seeing. Is that a reasonable assumption?
It does seem to be rather consistent throughout the day, however. The
reason for checking against the net when I have a GPS source is that I
want ntp to continue if/when there is no PPS. Is there any way to inform
ntp of the asymmetry?
-- Thomas Valerio
Every 20.0s: /usr/sbin/ntpq -n -c pe pe Tue Oct 11 12:37:33
remote refid st t when poll reach delay offset
x127.127.28.0 .NMEA. 0 l 4 16 377 0.000 -30.300
*127.127.28.1 .PPS. 0 l 3 16 377 0.000 0.001
-22.214.171.124 126.96.36.199 3 u 9 64 377 17.202 2.907
+188.8.131.52 184.108.40.206 2 u 64 64 377 16.612 2.332
+220.127.116.11 18.104.22.168 2 u 5 64 377 24.258 1.688
-22.214.171.124 126.96.36.199 2 u 53 64 377 40.429 4.956
> NTP can *not* detect âcommon modeâ asymmetric delay. Having a local
> GPS does not count in this respect. What does count is an NTP client /
> server sitting in your home trying to figure out what time it is only
> by hooking to the internet.
>To do this it must do a few things:
> 1) Get a signal out through the (slow / long lag) upload channel on your
> 2) Route that signal through the cable guyâs low capacity upstream
> one of his (at best) two or three gateways to your local empire.
> or may not be in the same state you live in.
> 3) Fly the signal over the backbone to whatever server is involved.
> 4) Fly a signal back over the backbone to possibly another set of gateways.
> 5) Route that signal through the cable guyâs high capacity downstream
> 6) Run it through the (quite fast / low lag) downstream channel on your
> Steps 1,2,5 and 6 are common to every single server you try to access.
> modem has an âupstreamâ lag of (say) 101 ms and a âdownstreamâ lag
> of (say) 1 ms, every server you contact will have a round trip time of at
> least 102 ms. They *may* have more than this, but none will ever have less.
> As the day progresses and various groups pop on and off the system in
> the usage of the upstream and downstream channels changes. It is not
> to guess that both change as a percentage. If that guess is correct,
> varies by significantly more than your downstream. That will get into
> correction stuff as well.
> You *might* ask, how about pings? Well, you *might* look into it and
> your local cable system recognizes pings at a very low level and
> routes them. Yes, thatâs hogwash and nobody would ever do it â¦.. except
> thatâs the way it works here with my internet. The network can be
> dead and pings (along with other ICMP traffic) will get through. Hmmmâ¦..
> You are indeed a guy with 5 watches to check against. The gotcha is that
> single one of them has been set fast or slow by the same amount.
>> On Oct 6, 2016, at 11:03 AM, Chris Albertson <albertson.chris at gmail.com>
>> I still think NTP can detect asymmetric delays. Only it can't know that
>> what it is detecting. What else generate those offset numbers? Yes
>> could very well be that MRS is running slow but I doubt that is the
>> And I really doubt your GPS' PPS is off by even one microsecond. A
>> bet is that ALL the results we see is because the real-world
>> path is different from the assumption NTP makes about communications
>> In practice what NTP sees is all due to the Internet and not so much the
>> reference clocks. Your data shows this. 188.8.131.52 .MRS has
>> stat depending on who is looking at it. So those billboards are showing
>> network stats not server stats. (but NTP can't know that for certain so
>> is obliged to call them server stats)
>> This is 2016. Almost any reference clock you are likely to use will be
>> pretty much dead-on, at least to within the precision that NTP works
>> So anything those billboards say is really about the communications
>> But NTP has no theoretical right to assume the cause of what it sees.
>> Theory and practice differs, In theory NTP can not detect asymmetric
>> delay but in practice that is about all it detects Maybe I should say
>> detects asymmetric delay just like the speedometer in my car deters
>> All that said, if the OP is still reading this it should be very good
>> for him because your data shows that NTP can give him his required
>> even without a GPS if he has an Internet connection as good as yours
>> In fact what you are showing is that NTP using the Internet can beat GPS
>> over USB to Winows. and can certainly beat any software the "jam sets"
>> clock. All you need is your Internet connection, no aded hardware.
More information about the time-nuts