[ntp:questions] Re: Clock selection?

David L. Mills mills at udel.edu
Sun Jan 18 17:09:54 UTC 2004


David,

It doesn't work like you suspect. Rather:

1. Order the servers by increasing synchronization distance (first
stratum, then one-half delay plus dispersion). This is the initial set
of survivors.

2. Compute the mean incidental offset error r[i] for the ith survivor.
This is shown in the ntpq billboard as jitter. Compute the mean
selection error s[i] of the ith survivor relative to all the others.

3. Toss out the survivor with the largest s[i]. If the minimum s[j]
remaining is less than the maximum r[k], or if the number of survivors
is three or less, terminate the procedure; otherwise, continue in step
2.

The first survivor in the remaining list becomes the synchronization
source and the others participate only in the combining algorithm. The
details are of course in the briefings.

Ordinarily, delay is not a factor in the algorithm, as satellites can
make very good sources. The usual problem is not the satellite itself,
but asymmetric paths, one way by satellite the other by landline.

Dave

David J Taylor wrote:
> 
> "Richard B. Gilbert" <rgilbert88 at comcast.net> wrote in message
> news:1YudnY3jCP0QhpfdRVn-sQ at comcast.com...
> > Can anyone explain the clock selection here?  Why would the clock with
> > the highest delay, offset, and jitter be selected?  To my unpracticed
> > eye, 128.59.39.48 appears to be the cleanest source of time!
> 
> I've seen this behaviour as well, and I think it has been discussed here.
> As I recall, the behaviour I observed was by design.
> 
> When you have both landline links (15 - 50ms) and satellite links
> (~200ms), the satellite links seem to be selected on the same sort of
> basis, something like: the smallest ratio of jitter to delay.  Not a
> linear measure, I expect.  I now avoid intercontinental links for this
> reason (and they are further away on the network, of course!).
> 
> Cheers,
> David



More information about the questions mailing list