[ntp:questions] Is it possible to confuse ntpd's freq error measurement procedure?

Dave Hart hart at ntp.org
Wed Jun 6 22:13:58 UTC 2012

On Wed, Jun 6, 2012 at 6:07 PM, Paul Malishev <p.malishev at gmail.com> wrote:
> Hello.
> I have two ntpd peers which exchange time between themselves and also
> receive time from external server.
> I believe that at some moment connection to external server was lost and
> time on these two peers drifted a bit.
> When connection to external server was restored both ntpd on both peers
> logged something like:
> Jun  5 13:21:09 peer0 ntpd[5052]: frequency error 18158 PPM exceeds
> tolerance 500 PPM
> After that there were a lot of messages with not so big freq error:
> Jun  5 13:23:18 DIG ntpd[5052]: frequency error 608 PPM exceeds tolerance
> 500 PPM
> When an operator saw time difference with external server about 30sec he
> just restarted ntpd on both nodes and surprisingly freq error messages
> disappeared. Now difference is about 1ms and stability stays about 0.021
> So my question is: is it possible to confuse ntpd's freq error measurement
> with some wrong settings?

ntpd measures the frequency error directly only at startup, lacking a
driftfile.  While it's operating, it's not measuring the frequency
error, but rather manipulating it to steer the clock offset toward
zero.  That manipulation is capped at 500 parts per million relative
to the nominal clock rate.

> My config is:
> tinker step 0

You've told ntpd to never step the clock to correct it (by default, it
is stepped when the offset exceeds 128ms).  So instead, ntpd must
eliminate slowly by running the clock faster or slower (but not more
than 500 PPM faster or slower).  The large frequency "error" in the
messages is a direct result of the perceived local clock offset.

Likely restarting ntpd also invoked ntpdate, which stepped the clock
so it was close enough that after restarting, ntpd's rate adjustments
were well under 500 PPM.

Dave Hart

More information about the questions mailing list