Patrick Nolan wrote: > 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? > Yes it is possible. It's rare but it can happen.
Some Linux systems have known problems with losing timer interrupts! During periods of heavy I/O load disk drivers may mask or disable interrupts for a little too long a time. . . . Some Windows systems have also been known to exhibit similar behavior. > 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. What's the value stored in your drift file? DON'T use burst! The burst keyword was intended for situations where ntpd has to make a phone call to NIST (or similar service) to get the time. It is NOT suitable for general use over the internet. Iburst is good. It gets you a fast startup and then lets your system poll the server at normal intervals. Check the value of a Kernel variable called "HERTZ". Some Linux systems set it to 1000 which is not good for NTP. If yours is set to 1000 (or 250) try changing it to 100. Using a single server is not usually a good idea. Two servers are the worst possible configuration; ntpd has no good way to decide which one to believe. Three are good but four are better. Try to select servers that are close to you in network space (low values of Delay). _______________________________________________ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
