[ntp:questions] strange behaviour of ntp peerstats entries.

David L. Mills mills at udel.edu
Sun Feb 3 20:41:20 UTC 2008


The rub is when a new sample comes along when an older sample with lower 
delay is in the filter. This can and often does persist until the 
minimum sample is ejected from the filter by a newer sample and the 
minimum sample is redetermined. So, the minimum sample, and thus the 
maximum loop delay, is no more than eight samples.

To make things more complicated, there can be several clock filters 
running at the same time, one for each server. The selection algorithm 
uses only the last minimum sample in each filter, even if more recent 
samples are in the filter. However, and this is a major point, once a 
system peer has been determined, the minimum sample of the peer is used 
only once. If selected again, the sample is ignored. This is done to 
avoid hijacking by a newer but inferior server and is a major 
contributor in the scheme to minimize clockhopping.

In connection with the Allan intercept, note that the sort list is 
biased by the sample age so that samples older than the Allan intercept 
are strongly discouraged (but not impossible). The reason for this, as 
you might assume, is that older samples become uncorrelated and thus not 
helpful. However, the code makes sure that at least two samples are in 
the filter in order to calculate jitter.


David Woolley wrote:

> Unruh wrote:
>> Under ... is the line
>> dst[i]=peer->filter_delay[j]
> Apologies, I missed that detail.  I guess dst has changed its meaning 
> over time.  (It doesn't really look right to me though, as there is a 
> sudden discontinuity as you cross the Allan Intercept.)
> However, that doesn't change the fact that the sample used is ord[0], 
> i.e. the sample with the lowest dst value, subject to it also being 
> newer than the last one used.  That is not necessarily the most recent.

More information about the questions mailing list