[ntp:questions] Compensating for asymmetric delay on a per-peer/server basis?

William Unruh unruh at invalid.ca
Mon Sep 15 15:24:27 UTC 2014

On 2014-09-15, Martin Burnicki <martin.burnicki at meinberg.de> wrote:
> Phil W Lee wrote:
>> William Unruh <unruh at invalid.ca> considered Sat, 13 Sep 2014 11:56:37
>> +0000 (UTC) the perfect time to write:
>>> On 2014-09-12, Martin Burnicki <martin.burnicki at meinberg.de> wrote:
>>>> William Unruh wrote:
>>>>> No idea why a fudge parameter would be complicated. If you wanted to use
>>>>> ntpd itself to figure out the assymmetry, that could well be
>>>>> complicated. But if it is a fixed offset, I cannot see how that would be
>>>>> complicated and it ihas already been implimented in the refclock case.
>>>> I tried to explain this in my earlier email.
>>>> If you have a local (GPS controlled) NTP server plus some NTP clients
>>>> connected to the inet via an asymmetric connection you
>>>> - need to apply a fudge time if your local server contacts external servers
>>> Again, let us separate the two questions-- one is trying to make the
>>> time on your computer equal UTC, the other is to deliver that UTC to
>>> others. At present it is the first that is most important to me, and for
>>> the solution to THAT problem that it seems to me to be simple-- exactly
>>> the same as the fudge for refclock.
>>> Also if you have not solved the first, then the second-- delivering
>>> exact time to others, cannot be solved.
>> Additionally, the same solution, if applied by the client, would work
>> just as well for them as it does for you.
> Only if the client has explicitly configured my server as time source. 
> If I'm a member of the pool and clients get my IP or the IP of other 
> pool servers dynamically, how should they know if they had too apply a 
> fudge time because *my* server is accessed via an ADSL line while others 
> are not, or with a different ratio of upload/download speeds?

It they are willing to put up with the pool, they are willing to accept
what they get. The quality of the servers in the pool varies a lot. Some
will have microsecond accuracy, some millisecond. It says that they
really do not care about the ultimate accuracy. If your assymmetric
delay is such that it puts out your time by say 10ms or 1 sec, perhaps
you should refrain from participating in the pool.

But in any case this is a very different situation from making sure that
your own clock is accurate, and having ntpd provide solutions for that
case should not wait for solutions for this far more difficult case. The
solutions for your own acuracy seem simple, kand just hneed an extention
fo the fudge time directrive to servers as well as refclocks. 
As someone pointed out, the solution for compensating for delays in the
time you server to others is far more complex.

> If I know the time error caused by *my* ADSL connection I could try to 
> compensate it as good as possible so it doesn't make a difference for a 
> client (in terms of time error) if he polls my server or different one 
> from the pool which is eventually connected via a symmetric line.
> If another client is also connected via ADSL he could apply another 
> fudge time to compensate the asymmetry in *his* connection.
>>> One could argue that the second is the problem for the client, not the
>>> server to solve.  Ie, if you connect to some source, it is up to you to
>>> figure out if there is an assymetry on the path from them to you. Now
>>> the server could help in this if it knows that there are some local
>>> assymmeteries, but that is help, not duty.
>> Heck, you can only know about the part of the path on the local loop
>> anyway, because after that the route diversifies, and may even change
>> dynamically, as well as by destination.
> I don't think there are systematic asymmetries on internet backbones as 
> there are with ADSL lines, so if every end node took care to compensate 
> the time error caused by his *own* inet connection the overall accuracy 
> should increase, regardless which time source you chose.
>> And those who are seriously concerned about a ms or two are likely to
>> want to verify their time sources anyway, in which case a small web
>> page on the same IP address as the ntp server could be used to advise
>> prospective clients what, if any, asymmetry is known on the local loop
>> of the server, which version of ntp is needed for corrective
>> parameters to be set, and what line(s) to include in the ntp.conf to
>> achieve that.
> As said above this wouldn't help in case of pool servers where clients 
> might get your IP automatically.
>> I suppose there might be some value in recommending a different port
>> for ntp related web information, just in case a single machine (or NAT
>> gateway) is used to reach both an ntp server and a web server with
>> other content - I'd suggest 8123 would be memorable for such a purpose
>> (the 8 coming from the normal http port 80 and the 123 from the ntp
>> port assignment).
>> Most users aren't likely to be that bothered about a small (sub
>> 1/100th sec) difference between real UTC and the time received,
>> provided the time served is consistent.
> So they can simply don't care about time corrections. What I mean is 
> that you *could* take care if you wanted, but you don't have to if the 
> accuracy you achieve is good enough for your requirements.
> Martin

More information about the questions mailing list