[time-nuts] ntp and asymmetric delays

Thu Oct 6 13:18:57 EDT 2016

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.
> 
> 
> 
> On Wed, Oct 5, 2016 at 5:14 AM, Magnus Danielson <magnus at rubidium.dyndns.org
>> wrote:
> 
>> 
>> 
>> On 10/05/2016 01:48 PM, Attila Kinali wrote:
>> 
>>> On Tue, 4 Oct 2016 18:05:16 -0700
>>> Chris Albertson <albertson.chris at gmail.com> wrote:
>>> 
>>> The problem, I think with your Internet sync's NTP servers is you are only
>>>> using one server S.  The most common practice is to use 3 to 5 with 5
>>>> being
>>>> about the right number.   If you get Ntp enough Internet servers to work
>>>> with it can detect problem like asymmetric path lengths which I'm sure is
>>>> you problem.
>>>> 
>>> 
>>> No they are correctly configured with 3 and 5 servers respectively.
>>> I singled out server S out, because i didn't want to clutter the argument
>>> with too many numbers and because S is common to both machines A and B
>>> and because it's very close in internet terms (with 4.5ms and 2ms
>>> respectively).
>>> 
>>> The full view of A is (the last line is B):
>>> 
>>>     remote           refid      st t when poll reach   delay   offset
>>> jitter
>>> ============================================================
>>> ==================
>>> +162.23.41.55    .MRS.            1 u  357 1024  377    4.555    0.198
>>> 0.293
>>> *162.23.41.10    .MRS.            1 u  318 1024  377    4.403   -0.040
>>> 0.123
>>> -131.188.3.223   .PZF.            1 u  548 1024  377    9.524   -0.654
>>> 0.039
>>> +2001:67c:8:abcd .GPS1.           1 u   74 1024  373   12.163    0.143
>>> 0.168
>>> -81.94.123.17    85.158.25.74     2 u  297 1024  377    0.985   -0.798
>>> 0.158
>>> -2a02:418:f022:: 162.23.41.10     2 u  792 1024  377    0.649   -0.727
>>> 2.120
>>> 
>>> And the full view of B is:
>>>     remote           refid      st t when poll reach   delay   offset
>>> jitter
>>> ============================================================
>>> ==================
>>> *162.23.41.10    .MRS.            1 u  175 1024  377    2.067   -0.033
>>> 0.069
>>> +195.186.1.101   195.186.150.242  2 u  504 1024  377    1.317   -0.360
>>> 0.086
>>> +130.60.204.10   130.60.159.7     4 u  901 1024  377    1.539    0.932
>>> 2.065
>>> 
>>> 
>>> Note: 162.23.41.10 (the server S) is one of the three NTP servers run by
>>> METAS
>>> and fed by the official PPS of Switzerland.
>>> 
>>> 
>>> And no, NTP cannot detect asymmetric network delays. They are completely
>>> indisdinguishable from clock offsets. One can easily show that the
>>> uncertainty in the network delay symmetry is the fundamental accuracy
>>> limit of NTP. As the asymmetry is in general unbounded, the only guarantee
>>> you have is that you are at most off by the RTT (aka delay) of the
>>> reference.
>>> (given the reference itself is accurate)
>>> 
>> 
>> It is trivial to show that any two-way time-transfer mechanism, be it NTP,
>> PTP, TWTFST, DTM TT or whatever, cannot unaided separate Time Error between
>> two clocks from that of the asymmetry between them. The Round Trip Time
>> (RTT) is however guaranteed unbiased under the assumption of no (major)
>> frequency difference. PTP adds means by which intermediate nodes can
>> provide delay estimations and thus allow cancellation of delay in those
>> equipments, but it does not help for asymmetry in path, such as different
>> fiber-lengths. Such delays needs to be calibrated.
>> 
>> With lots of observations you can however draw some conclusions of likely
>> cause of offsets, but without aiding through calibration, you cannot draw a
>> strict conclusion.
>> 
>> You CAN do very well, to just a few Millisecond using NTP sync'ing to
>>>> Internet servers, but pick 5 of them or even 7.  and make sure they are
>>>> dispersed and not all at the same place.
>>>> 
>>> 
>>> You want to have them (time wise) as close as possible. Having many
>>> servers
>>> does not help as much as having one accurate close by. Actually, once you
>>> have a very close stratum 1, any additional server will _degrade_ the
>>> accuracy of NTP as NTP cannot know which of it's reference servers is
>>> accurate or not (unless specifically configured).
>>> 
>>> 
>>> In this case the correct answer to this "problem" would be to set up a
>>> stratum 1 server in either of the colo centers and synchornize to that.
>>> And if i had the hardware, I would do that. But then, being off by only
>>> 1ms
>>> is not that bad for an internet facing ntp server where most of the
>>> clients
>>> will be on ADSL/VDSL lines which exhibit some 10ms of delay.
>>> 
>> 
>> Indeed. Asymmetry can build up in places where you do not expect it.
>> Most systems isn't designed for symmetric delay. Many works fairly decent
>> (at low load), but you never know and it's hard to tell.
>> 
>> Cheers,
>> Magnus
>> _______________________________________________
>> time-nuts mailing list -- time-nuts at febo.com
>> To unsubscribe, go to https://www.febo.com/cgi-bin/m
>> ailman/listinfo/time-nuts
>> and follow the instructions there.
>> 
> 
> 
> 
> -- 
> 
> Chris Albertson
> Redondo Beach, California
> _______________________________________________
> 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.