[ntp:questions] NTP 4.2.2p4 loopstats
mills at udel.edu
mills at udel.edu
Mon Nov 13 16:59:15 UTC 2006
I haven't changed the statistics in a rather long time, although my
timescale and the timescale of the distributions might not coincide. The
statistics on jitter are rather intricate. In one sense the combined
jitter weighted by the combined metric is valid and in the other what is
claimed to be the selection jitter is the other. Both are reported in
the rv statistics, although a case can be made for either one as the
most important. Frankly, this represents a case for splitting hairs that
is not really a sign of the times.
Having said that, the loopstats have not changed in several years.
> Wandering back to jg's original question...
> It appears that the jitter field which gets written to loopstats
> changed considerably between 4.2.0 and 4.2.2.
> The new value, in the global variable clock_jitter, is calculated from
> (last offset - current offset) rather than from the current offset as
> in 4.2.0.
> This new value is displayed by ntpq rv as "noise".
> The old value is still around in the global sys_jitter. ntpq still
> displays this value as "jitter" in 4.2.2.
> The sys_jitter value still gets updated, but not by ntp_loopfilter
> anymore - which only updates clock_jitter.
> This is significant to anyone who post-processes loopstats, as the new
> values are typically smaller in magnitude.
> I can't find anything about it in the bugs, docs, or mailing list.
> Maybe I'm just not finding it.
> A quick fix (...well, a quick ugly hack actually...), for anyone who's
> loopstats post-processing has been disrupted with 4.2.2, is to change
> the calls in ntpd/ntp_loopfilter.c to pass sys_jitter instead of
> clock_jitter to the 'record_loop_stats' function.
> Note that you probably don't want to change *anything* else in
> ntp_loopfilter - just the number which gets written to loopstats, lest
> you disrupt the calculation of poll interval, etc.
More information about the questions