[ntp:questions] Loop Frequency and Offset

Dave Hart hart at ntp.org
Sun Sep 25 23:46:57 UTC 2011


2011/9/25 Dave Hart <hart at ntp.org>:
> 2011/9/25 Miguel Gonçalves <mail at miguelgoncalves.com>:
>
>> 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
>>
> 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.

Nice theory, Dave, but you overlooked that all those offsets are
within 500 usec of zero (in fact within +10 to +12 usec), which would
trigger the end of initial offset convergence and unclamping the
frequency compensation.

I'd suggest starting with the tickadj correction, and testing again to
see if the offsets are staying on one side of zero.  I'm still curious
about the ntpd versions involved.

Cheers,
Dave Hart



More information about the questions mailing list