On 2010-Feb-21 14:29:28 -0500, David Magda <dma...@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.ingolf...@broadpa= rk.no> wrote: >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 ... >r...@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
pgpiFgyALIePm.pgp
Description: PGP signature
