William Unruh wrote:
On 2014-09-12, Martin Burnicki <[email protected]> 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
possible.
- 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
--
Martin Burnicki
Meinberg Funkuhren
Bad Pyrmont
Germany
_______________________________________________
questions mailing list
[email protected]
http://lists.ntp.org/listinfo/questions
