Joshua Coombs wrote:
"Richard B. Gilbert" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
Duplication is not particularly desirable but it's damned difficult to
avoid! Each peer needs a minimum of four time sources. Providing four
unique servers to each peer would require sixteen servers. It can be
difficult to find even four really good servers for a site. There are
many good servers out there but "good at the server" is not the same
as "good, as delivered here". The Internet can really mess up the
time as delivered at your site so the problem becomes one of finding
servers with low latency and stable round trip delays.
Peers with more than one server do not just "track" one server. One
server is selected as the primary source and the remaining "usable"
servers act as an "advisory committee" having some small influence on
the clock. See the RFC or Dave's "slide show" for the math; I'm sure
the math is much more precise than my fumbling English translation
thereof.
Ok, so I've taken a kind of aggressive approach to getting an 'ideal'
setup. I used the list of public stratum 1 and stratum 2 clocks, and
pulled all US entries that are A) Open and B) don't request
notification. I've setup a dedicated box in my lab that does aggressive
(burst, low interval) polling of my 4 existing ntp time sources, using
them as a baseline. I've conf'd all the servers in the list I
generated, setting min/max poll to 12 (34mins) so I don't abuse anyone.
I've got a perl script going through and recording the observed offsets,
latency, and jitter using RRDTool and plan to try and find 16 solid
sources from that list.
I only have about 24 hours worth of data, but I've already spotted three
trends. First are servers that tend to report offsets very close to
what I'm getting as 'true' time from my 4 existing ntp servers, one of
which is tracking ACTS. The second is a group of servers that all seem
to have a systemic offset, but are otherwise quite stable. The third
are all over the map.
I know the third group is garbage, but what about the systemic offset
servers? I would think they would be usable to at least get frequency
info from despite the offset, or should I avoid them as well and start
contacting remote servers if I can't fill out my 16 slots using first
pick servers?
Joshua Coombs
I believe that systematic offsets are "normal" and also that they are an
artifact of the network; e.g. the server has the correct time but there
is an asymmetric delay between you and the server in question, say 20
milliseconds in one direction and 10 milliseconds in the other. I have
configured a GPS receiver and four internet servers; all four of the
internet servers show offsets of two to six milliseconds from the GPS.
It is also true that there are a bunch of not so great servers out
there! I will name no names (there, but for the grace of God. . . .).
I have the impression that a lot of them use HF or VLF radio receivers
as time sources. When reception is good, time is good, when reception
is poor so is the time.
_______________________________________________
questions mailing list
[email protected]
https://lists.ntp.isc.org/mailman/listinfo/questions
