[ntp:questions] Loop Frequency and Offset

Dave Hart hart at ntp.org
Sun Sep 25 23:37:32 UTC 2011


2011/9/25 Miguel Gonçalves <mail at miguelgoncalves.com>:
> I have a machine running FreeBSD 7.4 and it seems that the CPU clock runs
> too fast or slow (positive offset in loopstats is fast or slow?).

ntpd's offset and the frequency compensation are both reported as
corrections to the local clock to bring it into alignment with the
source(s).  So a positive offset means the clock is behind correct,
and a positive frequency correction means the clock runs slower than
correct.

> tick# tail -10 /var/log/ntp/loopstats
> 55829 66814.311 0.000010871 185.398 0.000003540 0.002317 4
> 55829 66831.312 0.000010025 185.398 0.000000984 0.002167 4
> 55829 66847.312 0.000011242 185.398 0.000001303 0.002027 4
> 55829 66862.313 0.000011571 185.398 0.000000625 0.001896 4
> 55829 66877.313 0.000010833 185.398 0.000000990 0.001774 4
> 55829 66893.323 0.000011386 185.398 0.000000724 0.001659 4
> 55829 66909.314 0.000010876 185.398 0.000000574 0.001552 4
> 55829 66927.314 0.000011263 185.398 0.000000620 0.001452 4
> 55829 66942.315 0.000011355 185.398 0.000000402 0.001358 4
> 55829 66957.315 0.000010197 185.398 0.000001026 0.001270 4
>
> The frequency is too high it seems. Since this is a software clock can this
> be changed to get a lower frequency and thus a smaller offset?

As David Wooley noted, you should be able to use tickadj to bump the
software clock frequency by 100 PPM.  That's invisible to ntpd, so
after tickadj, delete your driftfile and restart ntpd.  Make sure the
measured drift is indeed closer to zero.

> In another machine I am getting (also FreeBSD 7.4):
>
> tock# tail -10 /var/log/ntp/loopstats
> 55829 66540.886 -0.000000472 46.597 0.000000364 0.011080 6
> 55829 66604.886 0.000002199 46.597 0.000000287 0.010364 6
> 55829 66668.886 0.000004014 46.616 0.000000245 0.011887 6
> 55829 66732.886 0.000005470 46.616 0.000000269 0.011119 6
> 55829 66796.886 0.000006189 46.616 0.000000227 0.010401 6
> 55829 66860.886 0.000005828 46.616 0.000000176 0.009730 6
> 55829 66924.886 0.000003394 46.645 0.000002087 0.013579 6
> 55829 66988.887 0.000001509 46.645 0.000000211 0.012702 6
> 55829 67052.887 -0.000000924 46.645 0.000000173 0.011882 6
> 55829 67116.887 -0.000003216 46.645 0.000000390 0.011114 6
>
> Here a much lower frequency and a smaller offset at each reset interval?

More notable to me:  The frequency compensation is varying.  What
version(s) of ntpd are the two machines running?  On the first one,
given the loopstats covers less than 300 seconds and the frequency
appears locked, I'm guessing you sampled during initial offset
convergence.  That's new for 4.2.7 and runs for the first 300 seconds
(by default) after the frequency compensation is loaded from driftfile
or measured.  During that period, the frequency compensation is locked
while ntpd attempts to slew away the initial offset until less than
500 usec remains, or the 300s limit elapses.

Cheers,
Dave Hart



More information about the questions mailing list