Phil W Lee wrote:
William Unruh <[email protected]> considered Sat, 13 Sep 2014 11:56:37
+0000 (UTC) the perfect time to write:
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.
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
_______________________________________________
questions mailing list
[email protected]
http://lists.ntp.org/listinfo/questions
