On 10/05/2016 01:48 PM, Attila Kinali wrote:
On Tue, 4 Oct 2016 18:05:16 -0700
Chris Albertson <[email protected]> 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 -- [email protected]
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
