[ntp:questions] strange behaviour of ntp peerstats entries.
David L. Mills
mills at udel.edu
Sun Feb 3 20:41:20 UTC 2008
David,
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.
Dave
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