MFC r285424 (ian):

Use the monotonic (uptime) counter rather than time-of-day to measure
elapsed time between ntp_adjtime() clock offset adjustments.  This
eliminates spurious frequency steering after a large clock step (such
as a 1970->2015 step on a system with no battery-backed clock hardware).

This problem was discovered after the import of ntpd 4.2.8, which does
things in a slightly different (but still correct) order than the 4.2.4
we had previously.  In particular, 4.2.4 would step the clock then
immediately after use ntp_adjtime() to set the frequency and offset to
zero, which captured the post-step time-of-day as a side effect.  In
4.2.8, ntpd sets frequency and offset to zero before any initial clock
step, capturing the time as 1970-ish, then when it next calls
ntp_adjtime() it's with a non-zero offset measurement. This non-zero
value gets multiplied by the apparent 45-year interval, which blows up
into a completely bogus frequency steer.  That gets clamped to 500ppm,
but that's still enough to make the clock drift so fast that ntpd has
to keep stepping it every few minutes to compensate.

Approved by:	re (gjb)

0 files changed, 0 insertions, 0 deletions