[time-nuts] ntp and asymmetric delays
time at patoka.org
Tue Oct 11 16:16:11 EDT 2016
There is good article to read
Probably NTPD uses a weighting schema when processing the measurements.
However, beyond a certain level of delay the measurements are likely to
be so corrupted as to be useless.
On 2016-10-11 13:09, Thomas Valerio wrote:
> 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
> 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
> ntp of the asymmetry?
> -- Thomas Valerio
> Every 20.0s: /usr/sbin/ntpq -n -c pe pe Tue Oct 11
> 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
> -18.104.22.168 22.214.171.124 3 u 9 64 377 17.202 2.907
> +126.96.36.199 188.8.131.52 2 u 64 64 377 16.612 2.332
> +184.108.40.206 220.127.116.11 2 u 5 64 377 24.258 1.688
> -18.104.22.168 22.214.171.124 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
>> 2) Route that signal through the cable guyâs low capacity
> network to
>> one of his (at best) two or three gateways to your local empire.
> These may
>> 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
>> 5) Route that signal through the cable guyâs high capacity
>> 6) Run it through the (quite fast / low lag) downstream channel on
>> Steps 1,2,5 and 6 are common to every single server you try to access.
> If your
>> 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
>> least 102 ms. They *may* have more than this, but none will ever have
>> As the day progresses and various groups pop on and off the system in
> your state,
>> 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,
> your upstream
>> varies by significantly more than your downstream. That will get into
> NTPâs loop
>> correction stuff as well.
>> You *might* ask, how about pings? Well, you *might* look into it and
> find that
>> 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.
>> You are indeed a guy with 5 watches to check against. The gotcha is
>> 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
>>> what it is detecting. What else generate those offset numbers?
>>> 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.
>>> 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
>>> reference clocks. Your data shows this. 126.96.36.199 .MRS has
>>> stat depending on who is looking at it. So those billboards are
>>> network stats not server stats. (but NTP can't know that for certain
>>> is obliged to call them server stats)
>>> This is 2016. Almost any reference clock you are likely to use will
>>> 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
>>> delay but in practice that is about all it detects Maybe I should
>>> 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
>>> over USB to Winows. and can certainly beat any software the "jam
>>> clock. All you need is your Internet connection, no aded hardware.
> time-nuts mailing list -- time-nuts at febo.com
> To unsubscribe, go to
> and follow the instructions there.
More information about the time-nuts