[time-nuts] ntp and asymmetric delays

Thomas Valerio tjv at westwood-tech.com
Tue Oct 11 17:09:29 UTC 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?

   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.



More information about the Time-nuts_lists.febo.com mailing list