[ntp:questions] Re: NTP sync problems

David L. Mills mills at udel.edu
Thu Dec 16 20:12:45 UTC 2004


Terje,

The prefer peer designation does not affect the mitgation algorithm, 
which means it could be booted off the intersection as well as any 
other. However, it is never booted off the clustering algorithm, but in 
fact if it would otherwise be selected for boot, the algorithm 
terminates right there.

An empty intersection does not ordinarily occur if the servers are 
operating correctly, as the dispersion is inherited along the path and 
the confidence interval inreased accordingly. What has been a problem 
with very good reference clocks, nearby servers and fast networks is 
that the confidence intervals can get really tiny, like a couple hundred 
microseconds or so. This tends to amplify even tiny network wiggles due 
to Ethernet collisions, switch latencies and ARP cache refreshes.

My Blade 1500 with PPS routinely shows PPS offset and jitter of a 
microsecond or two and dispersion 250 microseconds. It is also watching 
a CDMA-based Ethernet server over a 100-Mbps Ethernet. It shows the 
corresponding numbers of 45, 64 and 5077 microseconds. So, if the PPS 
and CDMA offsets differed by more than 5 ms, a Mexican standoff would 
have to be declared.

Strangely enough, I was watching just now, and found a curiousity. The 
Blade and CDMA server are on different 100-Mbps Ethernet stubs connected 
by two switches and a 100-Mbps fiber link. The roundtrip delay is 
typically 0.9+-.05 ms, but every once in a while the delay becomes 
3.5+-0.5 ms with offset -1.5 ms. It looks like the delay is only on one 
leg due probably to the CDMA.

Dave

Terje Mathisen wrote:
> David L. Mills wrote:
> 
>> Guys,
>>
>> There might be some misconception here. The mitigation algorithm 
>> establishes a bound on the offset of any server with respect to 
>> roundtrip delay and dispersion. This is a matter of physics and 
>> theory. When multiple servers are involved, the algorithm computes an 
>> intersection interval within which the server clocks can be considered 
>> valid. A possibly correct time must be contained in this intersection. 
>> If the intersection is empty, a correct time cannot be established. 
>> This is independent of the stratum.
> 
> 
> Sure, this is obviously right.
> 
> My suggestion was based on the idea that if the secondary server would 
> always use the primary as its own preferred source, then it would have 
> to have more or less the same time, right?
> 
> Actually finding two servers with no intersection interval pretty much 
> proves that either one or both of them are misconfigured, and without a 
> proper UTC reference.
> 
> Terje
> 




More information about the questions mailing list