I'm having trouble with one linux client out of a group.
It seems as if ntpd can't keep its clock syncronized. It's
drifting about 6-10 minutes per day, well over the 500 ppm limit.
After reading some of the posts on this newsgroup, I have come
to realize that debugging ntp problems can be quite complex.
Before I launch into a detailed search, I would like to clarify
one question. Is it possible for the clock frequency to be so
far off that ntpd just can't get it under control?
I have stripped my ntp.conf to the minimum, just one server
line and a drift file. The log entries look like this:
Oct 18 17:23:32 client ntpd[30920]: synchronized to 171.64.7.87, stratum 1
Oct 18 17:27:48 client ntpd[30920]: no servers reachable
Oct 18 17:29:06 client ntpd[30920]: synchronized to 171.64.7.87, stratum 1
Oct 18 17:29:16 client ntpd[30920]: time reset +10.678548 s
Oct 18 17:29:58 client ntpd[30920]: synchronized to 171.64.7.87, stratum 1
Oct 18 17:31:59 client ntpd[30920]: no servers reachable
ntpq -p says this:
remote refid st t when poll reach delay offset jitter
==============================================================================
grandfather.Sta .GPS. 1 u 49 64 375 0.243 2833.49 1139.84
For a while there was a * in the first column, but it went away.
Did I mention that there are several other clients with no problems at all?
ntpd 4.2.2 is running with -g, burst, and iburst.
So, does this look like a hardware problem?
If not, I'll have to dig into networking and details of the configuration.
_______________________________________________
questions mailing list
[email protected]
https://lists.ntp.org/mailman/listinfo/questions
