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

Martin Burnicki martin.burnicki at meinberg.de
Mon Sep 15 08:12:22 UTC 2014

William Unruh wrote:
> 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.

Yes. And if you make the fudge depending on the IP range because you 
know it's *your* ADSL line causing the time error then the same 
correction is applied for *all* NTP servers used as time source and 
accessed via the inet. ;-)

Of course the simplest approach would be to allow a fudge time on a per 
"server" line, but who says that ntpd couldn't support both approaches, 
one per server, and another on per IP range.

> Also if you have not solved the first, then the second-- delivering
> exact time to others, cannot be solved.

That's not quite true. If my local server connected via ADSL is not 
synchronized by GPS but only by servers on the internet then the time of 
my local server is off by a few milliseconds tue to the ADSL asymmetry.

However, for other nodes on the internet which poll *my* local server 
the asymmetry due to my ADSL connection is once more applied with 
reversed sign, so from my client's point of view there is no time error 
due to *my* ADSL line.

> 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.

I agree, but I don't think we are discussing duties here. I was just 
thinking about ways what *can* be done to make the time on my server as 
accurate as possible, and also server time to others as accurately as 

>> - need to apply the same fudge time with reversed sign if *you* try to
>> compensate the time error caused by *your* inet connection when external
>> clients try to get the time from your NTP server
>> - need to apply no fudge time at all for connections on your local network
>> I don't know how this is in other countries, but at least here in
>> Germany a typical home setup is a NAT router connected to the inet via
>> ADSL, and the router providing an internal switch with several ports to
>> which you can connect your devices, e.g. your NTP server and some NTP
>> clients.
>> As has been stated in some other posts:
>> - NAT doesn't hurt at all, unless you are trying to use NTP's authentication
>> - the asymmetry of the ADSL connection causes a time error of a certain
>> range, the sign of which depends on whether you look from an external
>> node to your home NTP server, or from your home NTP server to some
>> remote NTP server
> Agreed.
>> So an overall solution might be:
>> - if the source IP of incoming client requests is not on your local
>> subnet, apply a fudge time
> No. That is their problem not yours. Otherwise you havee too many cooks.

Please see also my other reply to Phil W Lee.

Martin Burnicki

Meinberg Funkuhren
Bad Pyrmont

More information about the questions mailing list