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

Paul Malishev p.malishev at gmail.com
Thu Jun 7 10:21:31 UTC 2012


Thanks Dave.

I have some realtime processes on this server and 128ms is too much for
stepping.
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>
> 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.
>
> Cheers,
> Dave Hart
>


More information about the questions mailing list