ntpd struggling to keep up - how to fix?

[Peter Jeremy]

On 2010-Feb-20 22:32:01 +0100, Torfinn Ingolfsen <torfinn.ingolfsen at broadpark.no> wrote:
>On Sat, 20 Feb 2010 12:53:51 +1100
>Peter Jeremy <peterjeremy at acm.org> wrote:
>
>> Looks reasonable.  Let us know the results.  I'd be interested in
>> the output from "ntpdc -c loopi -c sysi".
>
>Ok, here we go (the server panic'ed again last night):
>root at kg-f2# uptime
>10:28PM  up  2:26, 3 users, load averages: 0.00, 0.00, 0.00
>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

That's definitely not good - though it's marginally better than before.
I have checked on a local machine and the timecounter frequency definitely
needs to be adjusted in the opposite direction to the ntpd drift.

I think I see the problem: I suggested 3579545Hz - 2500ppm, which
gives an ACPI frequency of 3570596Hz.  There was some miscommunication
and you have set an ACPI frequency of 3577045Hz which is 2500Hz (or
698ppm) lower.  The drift reported by the time resets has gone from
+1930ppm (14.5s in 2:05:17) to +1233ppm (8.4s in 2:20:06) - which is
697ppm - fairly close to the change you made.  (The PLL is running
at +500ppm so the actual clock offset is 500ppm more than the "time
reset" reports suggest.

Having re-checked my maths, using both your "time reset" results, can
you please try:
  sysctl machdep.acpi_timer_freq=3570847
That should result in a drift of close to zero (well within NTP's
lock range of +/- 300ppm).

>frequency:            500.000 ppm

And this is definitely not good.

>Not synced at all. Not good. :-/
>Perhaps I should give it more time?

No.  Once ntpd decides to continuously step, something is broken.

I've done some double-checking and 
On 2010-Feb-20 22:55:21 +0100, Torfinn Ingolfsen <ytorfinn.ingolfsen at broadpark.no> wrote:
>This output looks ... wrong ... somehow to my eyes:
...
>Shouldn't ntpq and ntpdc be in agreement?

I'm not sure which particular bits you are concerned about but ntpq
reports delay/offset/jitter in msec whilst ntpdc reports them in sec.

Note that I can't explain why the loopi offset is zero - ntpdc(8)
states that this is the "last offset given to the loop filter by the
packet processing code".  For me it's non-zero but doesn't quite
match the offset reported by 'ntpq -p'.

-- 
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/20100221/04351fdd/attachment.pgp