On Wed, Jun 6, 2012 at 6:07 PM, Paul Malishev <[email protected]> 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 _______________________________________________ questions mailing list [email protected] http://lists.ntp.org/listinfo/questions
