[time-nuts] ntp and asymmetric delays (was: Need Time Help)

[Attila Kinali]

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)

> 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.

			Attila Kinali

-- 
It is upon moral qualities that a society is ultimately founded. All 
the prosperity and technological sophistication in the world is of no 
use without that foundation.
                 -- Miss Matheson, The Diamond Age, Neil Stephenson