[time-nuts] ntp and asymmetric delays

Magnus Danielson magnus at rubidium.dyndns.org
Wed Oct 5 12:14:09 UTC 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_lists.febo.com mailing list