[ntp:questions] Loop Frequency and Offset

Miguel Gonçalves mail at miguelgoncalves.com
Mon Sep 26 13:38:10 UTC 2011


Hi Dave!

2011/9/26 Dave Hart <hart at ntp.org>

> 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.
>

Thanks for all your support to reach a solution for this problem!

I found out that 180 ppm were the result of the CPU running too fast because
if I increased the CPU frequency by 180 ppm I would get a even higher
offset. Am I wrong? It seems I solved the problem as I showed in my previous
post.

Funny thing is that this machine has been running like this (180 ppm) since
July and it never complained... Obviously I always found odd 10 us offsets
but for NTP it was good enough.


>
> > 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.
>

Did it and I am getting

tick# tail -5 /var/log/ntp/loopstats ; ntpq -p ; ntptime
55830 48740.318 0.000000172 0.027 0.000001288 0.001534 10
55830 48755.315 -0.000000731 0.027 0.000000809 0.001435 10
55830 48771.315 -0.000000563 0.027 0.000000713 0.001342 10
55830 48788.310 -0.000000651 0.027 0.000001134 0.001255 10
55830 48805.310 -0.000000303 0.027 0.000000432 0.001174 10

Is 0.027 good enough or should I wait for it to stabilise and reduce it? The
machine is not loaded (not money wise of course :-)) and sits in a
temperature controlled room (20 ºC).


> > 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.
>

The first one is running NTP 4.2.4p5 (180 ppm previosly) and the second one
(46 ppm) is running 4.2.6p3.

Thanks for your help!

Cheers,
Miguel



More information about the questions mailing list