[time-nuts] ntp and asymmetric delays
Vlad
time at patoka.org
Tue Oct 11 20:16:11 UTC 2016
There is good article to read
http://cs.stackexchange.com/questions/103/clock-synchronization-in-a-network-with-asymmetric-delays
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
> 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?
>
> Thanks,
> -- Thomas Valerio
>
>
> Every 20.0s: /usr/sbin/ntpq -n -c pe pe Tue Oct 11
> 12:37:33
> 2016
>
> remote refid st t when poll reach delay offset
> jitter
> ==============================================================================
> x127.127.28.0 .NMEA. 0 l 4 16 377 0.000 -30.300
> 36.009
> *127.127.28.1 .PPS. 0 l 3 16 377 0.000 0.001
> 0.000
> -208.53.158.34 216.93.242.12 3 u 9 64 377 17.202 2.907
> 0.188
> +208.100.4.52 216.86.146.46 2 u 64 64 377 16.612 2.332
> 0.193
> +208.69.120.241 142.66.101.13 2 u 5 64 377 24.258 1.688
> 0.223
> -128.118.25.3 130.207.244.240 2 u 53 64 377 40.429 4.956
> 2.577
>
>
>> Hi
>>
>> 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
> modem.
>> 2) Route that signal through the cable guyâs low capacity
>> upstream
> 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
>> gateways.
>> 5) Route that signal through the cable guyâs high capacity
>> downstream
> network.
>> 6) Run it through the (quite fast / low lag) downstream channel on
>> your
> modem.
>>
>> 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
>> 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
> your state,
>> the usage of the upstream and downstream channels changes. It is not
> unreasonable
>> 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
> preferentially
>> 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
> completely
>> 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
> every
>> single one of them has been set fast or slow by the same amount.
>>
>> Bob
>>
>>> On Oct 6, 2016, at 11:03 AM, Chris Albertson
>>> <albertson.chris at gmail.com>
>>> wrote:
>>>
>>> I still think NTP can detect asymmetric delays. Only it can't know
>>> that
>>> is
>>> what it is detecting. What else generate those offset numbers?
>>> Yes
>>> it
>>> could very well be that MRS is running slow but I doubt that is the
>>> case.
>>> And I really doubt your GPS' PPS is off by even one microsecond.
>>> A
>>> good
>>> bet is that ALL the results we see is because the real-world
>>> communication
>>> path is different from the assumption NTP makes about communications
>>> paths.
>>>
>>> In practice what NTP sees is all due to the Internet and not so much
>>> the
>>> reference clocks. Your data shows this. 162.23.41.10 .MRS has
>>> different
>>> 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
>>> it
>>> 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
>>> with.
>>> So anything those billboards say is really about the communications
>>> paths.
>>> 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
>>> NTP
>>> detects asymmetric delay just like the speedometer in my car deters
>>> engine
>>> failure.
>>>
>>> All that said, if the OP is still reading this it should be very good
>>> news
>>> for him because your data shows that NTP can give him his required
>>> accuracy
>>> 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"
>>> the
>>> clock. All you need is your Internet connection, no aded hardware.
> _______________________________________________
> time-nuts mailing list -- time-nuts at febo.com
> To unsubscribe, go to
> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.
--
WBW,
V.P.
More information about the Time-nuts_lists.febo.com
mailing list