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

Unruh unruh-spam at physics.ubc.ca
Sat Feb 2 22:10:46 UTC 2008


David Woolley <david at ex.djwhome.demon.co.uk.invalid> writes:

>Unruh wrote:

>> 
>> Worse than that . Only if the latest sample is the one with the min delay
>> is it chosen Otherwise it is not. You can go for 16 or more samples never
>> using any of thembefor one fits the criteion. (actually the samples are
>> aged as well-- ie the delay is increased as they get olderbut that seems to
>> have little effect.)

>The increase is a pessimistic estimate of the error due to not having 
>quite the right frequency, so has a larger effect with larger polling 
>intervals.  The delay is a pessimistic estimate of the affects of link 
>asymmetry.  Incidentally, are you sure it is delay; I would have 
>expected the root dispersion to be included.

This is in the clock_filter algorithm. It selects the sample of the last 8
which has the lowest delay (suitably aged) If that sample is the most
recent, then it is actually used. Otherwise nothing is used that that
clokck measuremnt is tossed. Once it has a measurement sucnh that the
latest sample aslo has the least delay then that sample is passed to the
clock selection process.

>If you use that logic, whilst the last good sample is still in the 
>filter, only the head sample can actually override it.

Yup.

>The real questions seem to be whether one should use such worst case 
>estimates of error and whether one should rescan the whole filter when 
>the current value drops off the end.

At each measurment from ta peer, that measurement is checked against the
lst 8 measurmeents and used only if it is the least delay of those 8.


>If it really is failing to rescan, that is either an implementation 
>error or a change from NTP V3's formal specification.  NTPv3 requires a
>sort by distance, which includes dispersion terms.  ntpd 4.2.0, does 
>seem to implement the sort that chooses the lowest distance, and does 
>seem to use distance, rather than delay, so it looks to me that you've 
>either misread the code, or it has changed between 4.2.0 and 4.2.4, 
>apparently for the worse.

NO I am not talking about the clock selection process. It is teh
clock_filter which occurs before the clock selection algorithm comes into
play.


>I wonder if you are getting confused by the bit that says a peer sample 
>must be younger than the last one used?  It seems to me that that is 
>only there as a tie breaker, if two samples have equal aged differences.




More information about the questions mailing list