[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