[ntp:questions] Re: peering question
Richard B. Gilbert
rgilbert88 at comcast.net
Tue Mar 14 20:06:36 UTC 2006
Joshua Coombs wrote:
> "Richard B. Gilbert" <rgilbert88 at comcast.net> wrote in message
> news:waCdnRpEKui8M5LZRVn-gQ at comcast.com...
>> 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
> 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.
More information about the questions