[time-nuts] ntp and asymmetric delays
Magnus Danielson
magnus at rubidium.dyndns.org
Wed Oct 5 08:14:09 EDT 2016
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
More information about the time-nuts
mailing list