[ntp:questions] Is it possible to confuse ntpd's freq error measurement procedure?
p.malishev at gmail.com
Thu Jun 7 10:21:31 UTC 2012
I have some realtime processes on this server and 128ms is too much for
But thanks for the hint now I have some start point to investigate
2012/6/7 Dave Hart <hart at ntp.org>
> On Wed, Jun 6, 2012 at 6:07 PM, Paul Malishev <p.malishev at gmail.com>
> > 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: 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: 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
> > 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