[time-nuts] ntp and asymmetric delays
albertson.chris at gmail.com
Thu Oct 6 11:03:57 EDT 2016
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. 126.96.36.199 .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
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
> 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
>>> 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
>> The full view of A is (the last line is B):
>> remote refid st t when poll reach delay offset
>> +188.8.131.52 .MRS. 1 u 357 1024 377 4.555 0.198
>> *184.108.40.206 .MRS. 1 u 318 1024 377 4.403 -0.040
>> -220.127.116.11 .PZF. 1 u 548 1024 377 9.524 -0.654
>> +2001:67c:8:abcd .GPS1. 1 u 74 1024 373 12.163 0.143
>> -18.104.22.168 22.214.171.124 2 u 297 1024 377 0.985 -0.798
>> -2a02:418:f022:: 126.96.36.199 2 u 792 1024 377 0.649 -0.727
>> And the full view of B is:
>> remote refid st t when poll reach delay offset
>> *188.8.131.52 .MRS. 1 u 175 1024 377 2.067 -0.033
>> +184.108.40.206 220.127.116.11 2 u 504 1024 377 1.317 -0.360
>> +18.104.22.168 22.214.171.124 4 u 901 1024 377 1.539 0.932
>> Note: 126.96.36.199 (the server S) is one of the three NTP servers run by
>> 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
>> (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
>> 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
>> is not that bad for an internet facing ntp server where most of the
>> 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.
> time-nuts mailing list -- time-nuts at febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/m
> and follow the instructions there.
Redondo Beach, California
More information about the time-nuts