On 2010-Feb-20 22:32:01 +0100, Torfinn Ingolfsen <torfinn.ingolf...@broadpark.no> wrote: >On Sat, 20 Feb 2010 12:53:51 +1100 >Peter Jeremy <peterjer...@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): >r...@kg-f2# uptime >10:28PM up 2:26, 3 users, load averages: 0.00, 0.00, 0.00 >r...@kg-f2# sysctl machdep.acpi_timer_freq >machdep.acpi_timer_freq: 3577045 >r...@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.ingolf...@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
pgpZax0MQojXe.pgp
Description: PGP signature
