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

Martin Burnicki martin.burnicki at meinberg.de
Mon Sep 15 07:57:38 UTC 2014


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?

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
-- 
Martin Burnicki

Meinberg Funkuhren
Bad Pyrmont
Germany



More information about the questions mailing list