[ntp:questions] NTP Drifts +ve and -ve

Joseph Gwinn 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.  

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




More information about the questions mailing list