On Thu, Nov 04, 2010 at 08:32:06PM +0000, David L. Mills wrote:
> Wrong. The damon starts off be setting the frequency to zero, as you
> can see in the protostats. When the frequency calibration is
> complete, the frequency is set directly, as you can also see in the
> protostats. It could be a massively broken motherboard might set the
> frequency larger than 500 PPM, but in your case it set it at 172
> PPM, well within the tolerance. During the 5 minutes following the
> direct set, the frequency update is suppressed, so there is no
> clamp. So, please explain where to you find the bug.
The bug is in the adj_host_clock() function in ntp_loopfilter.c. On
startup when freq_cnt > 0, a reduced time constant is used which makes
the adjustment so large that the adjtime() argument is over 500
microseconds. On systems following the standard slew rate 500 ppm, the
adjustment will be applied only partially in the one second interval
it has and so there will be error in clock_offset. The missing offset
is the cause of the 172ppm error in the frequency estimation.
In order to fix this bug without checking the adjtime() leftover, a
clamp for the adjustment has to be added to that function, so
adjustment + drift_comp stays below 500 microseconds (or whatever
value is appropriate for the system).
For example:
if (adjustment + drift_comp > 500e-6)
adjustment = 500e-6 - drift_comp;
else if (adjustment + drift_comp < -500e-6)
adjustment = -500e-6 - drift_comp;
clock_offset -= adjustment;
adj_systime(adjustment + drift_comp);
--
Miroslav Lichvar
_______________________________________________
questions mailing list
[email protected]
http://lists.ntp.org/listinfo/questions
