[ntp:questions] NTP Drifts +ve and -ve
joegwinn at comcast.net
Wed Aug 20 13:39:42 UTC 2008
In article <BLU109-W27F6F9B75A676DDED8C61D9F6E0 at phx.gbl>,
umarul_it at hotmail.com (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.
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
> 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
> 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
> 3. Is this a problem or it is expected?
Both. It is a problem for sure, but is to be expected under these
More information about the questions