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
- 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
So an overall solution might be:
- if the source IP of incoming client requests is not on your local
subnet, apply a fudge time
- if the destination address of reply packets you send is not on your
local subnet, apply a fudge time with reversed sign
- otherwise (source and destination on your local subnet) apply no fudge
time at all
Martin
--
Martin Burnicki
Meinberg Funkuhren
Bad Pyrmont
Germany
_______________________________________________
questions mailing list
[email protected]
http://lists.ntp.org/listinfo/questions
