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

David Woolley david at ex.djwhome.demon.co.uk.invalid
Wed Aug 20 07:00:30 UTC 2008


Arul Murugan wrote:
> Hi,We are using NTP4, when CPU is very busy some of the UDP packets
+ hdropped by the kernel, so the local clock drifts 60 milliseconds from

The problem is not dropped packets, but delayed packets.

+ the time server. From that point NTP keeps drifts +ve and -ve for 2 to 3

Especially given the long recovery times you describe, it is more likely 
that the measured time server time is drifting from its true time and 
that the local clock is actually rather more accurately tracking it than 
the offsets imply.

However, if the errors always start as negative slips, your problem is 
not CPU overload but a device driver, often IDE run on non-DMA mode, 
with poor interrupt latency.

+ 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 NTP
+ drifting +ve and -ve?2. Why should NTP taking 3 days for correcting 60
+ milliseconds?3. Is this a problem or it is expected? Regards,Arul

ntpd isn't designed to cope with systematic changes well, it assumes 
random perturbations until convinced otherwise, The best way of dealing 
with those involves running a low pass filter with a time constant 
reflecting typical crystal frequency variation times.

I am surprised that it has not been convinced otherwise in this case, so 
could you confirm that you are using the recommended minpoll of 6 (64 
seconds) and the recommended maxpoll of 10 (1024 seconds).  Using high 
values for these will compromise recovery times.

Normally this problem is caused by network congestion, not CPU overload. 
  To get round asymmetric link delay problems, you should configure your 
routers and the corresponding ISP routers to give priority to NTP 
traffic.  In default of that, you should use the tinker huffpuff option.

If you really are having effects from CPU loading, you need to find 
network hardware with better drivers.  If you are losing clock 
interrupts, you need to investigate the drivers with poor latency.

Quite a few people believe that ntpd's assumptions about measurement 
error statistics are not valid in the world in which NTP is used by most 
system admins, and, if you are using Linux, I'm sure Unruh will suggest 
one alternative.




More information about the questions mailing list