ntpd struggling to keep up - how to fix?

[Peter Jeremy]

On 2010-Feb-21 14:29:28 -0500, David Magda <dmagda at ee.ryerson.ca> wrote:
>For future reference, how does the math work? How do you go from  
>taking a timer number:
>
>	$ sysctl machdep.acpi_timer_freq
>	machdep.acpi_timer_freq: 3577045
>
>And the ntpd(8) time reset log entries to adjust the frequency? Or do  
>you use the PPM output of the ntpdc(8) command?
>
>I'm not quite sure I understand what happened here. :)

I'm using a combination of the ACPI frequency, time reset logs and
PLL frequency reported by the op:

On 2010-Feb-20 22:32:01 +0100, Torfinn Ingolfsen <torfinn.ingolfsen at broadpa=
rk.no> wrote:
>root at kg-f2# sysctl machdep.acpi_timer_freq
>machdep.acpi_timer_freq: 3577045
>root at kg-f2# tvlm
>Feb 20 20:06:41 kg-f2 ntpd[942]: kernel time sync status change 2001
>Feb 20 20:21:49 kg-f2 ntpd[942]: time reset +1.118880 s
>Feb 20 20:37:53 kg-f2 ntpd[942]: time reset +1.188538 s
>Feb 20 20:53:03 kg-f2 ntpd[942]: time reset +1.121903 s
>Feb 20 21:09:00 kg-f2 ntpd[942]: time reset +1.179924 s
>Feb 20 21:24:57 kg-f2 ntpd[942]: time reset +1.178490 s
>Feb 20 21:39:58 kg-f2 ntpd[942]: time reset +1.110647 s
>Feb 20 21:55:53 kg-f2 ntpd[942]: time reset +1.177292 s
>Feb 20 22:11:44 kg-f2 ntpd[942]: time reset +1.172358 s
>Feb 20 22:26:48 kg-f2 ntpd[942]: time reset +1.114350 s
...
>root at kg-f2# ntpdc -c loopi -c sysi
>offset:               0.000000 s
>frequency:            500.000 ppm

Together with the assumptions that the system clock is stable (ie the
rate of drift is constant) and the syslog entries occurred at
precisely the times reported.  If the former assumption isn't true
(which was a distinct possibility given the size of error) then ntpd
isn't going to work.  If he latter assumption is incorrect then the
calculated clock skew will be incorrect - but hopefully enough to
bring it into ntpd capture range to allow later tweaking.

If ntpd cannot slew the local clock sufficiently, it will step the
clock roughly every 900 seconds, hence the regular "time reset"
messages.  Since we are assuming a stable clock, we can accumulate
the offsets in multiple reset messages to give a cumulative offset.

For the above figures, the clock drift (sum of "time reset" messages)
totals ~10.36 seconds over a period of 2:20:07 (the difference between
the "kernel time sync" and last "time reset" message).  [Note that I
somehow mistranscribed both the offset and duration in my last mail -
apologies for the confusion this might have caused].

10.36s in 2:20:07 == 10.36/8407 ~= 1.233e-3 or 1233ppm.  Thus ntpd is
reporting that the system clock is still 1233ppm slow, even with ntpd
pulling the system clock by its maximum of 500ppm.  Adding these gives
a total clock error of 1733ppm.

The nominal clock frequency used by the timecounter is 3577045Hz.
In order to calculate the actual clock frequency, we need to subtract the
clock error (1733ppm) from this frequency:
3577045Hz * (1 - 1733e-6) = 3570846Hz
(I rounded the clock error differently previously and got 3570847Hz).

-- 
Peter Jeremy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20100223/b967cb78/attachment.pgp