In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Arul Murugan) wrote:
> Hi, We are using NTP4, when CPU is very busy some of the UDP packets [are] > dropped > by the kernel, so the local clock drifts 60 milliseconds from the time > server. Dropped packets are quite unlikely to be the problem, even if most packets never arrive. More likely is that the NTP daemon is being preempted between taking the send timestamp and the sent packet actually appearing on the wire, and between received packets actual arrival time and when the daemon is able to obtain the receipt timestamp. These preemptions appear to the daemon as very large and random asymmetrical transport delays. If sufficiently common, these bad observations will seep through the various filter steps in NTP, and corrupt the measurements of clock offset error used to update the servo. See <http://www.eecis.udel.edu/~mills/stamp.html>. What computer platform and operating system are you using? One classic solution is to give the NTP demon sufficient realtime priority to outrank whatever else the CPU is doing, thus sharply reducing fraction of NTP polls that suffer preemption. This raised priority will not cause those other activities to be any slower because the NTP daemon is an insignificant consumer of CPU resources. > From that point, NTP keeps drifts +ve and -ve for 2 to 3 three days to > become stable. The graph looks a like a sine wave oscillating and reaching > zero after 3 days. My question are: > > 1. Why [is] NTP drifting +ve and -ve? Because the clock servo is being fed contaminated data, as explained above. > 2. Why should NTP [be] taking 3 days for correcting 60 milliseconds? Because it takes NTP days versus a few hours to slog through all that bad data. > 3. Is this a problem or it is expected? Both. It is a problem for sure, but is to be expected under these circumstances. Joe Gwinn _______________________________________________ questions mailing list [email protected] https://lists.ntp.org/mailman/listinfo/questions
