[ntp:questions] NTP Drifts +ve and -ve
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
More information about the questions