Tom Brown wrote:

Hi

On 5.3 i have a situation where some boxes have been 3 or 4 seconds out and restarting ntpd has fixed the issue.

What i dont understand is why the clocks did not drift to the correct time when the config seems correct in that restarting ntp did correct the time.

Is there something 'special' i need to do in order for the drift to work?

Is the directory /var/lib/ntp present, and with write permissions for the 'ntp' user? Does the drift file exist? Does ntpd ever lock in? What do you see in 'ntpq -p' over time? Are these heavily-loaded boxes, or boxes with wildly-varying loads? -Alan

Tom Brown <tom@...> writes:

Hi

On 5.3 i have a situation where some boxes have been 3 or 4 seconds out and restarting ntpd has fixed the issue.

What i dont understand is why the clocks did not drift to the correct time when the config seems correct in that restarting ntp did correct the time.

Is there something 'special' i need to do in order for the drift to work?

$ cat /etc/ntp.conf restrict default ignore restrict 127.0.0.1 restrict 10.0.0.0 mask 255.0.0.0 nomodify notrap server server01 server server02 fudge 127.127.1.0 stratum 10 driftfile /var/lib/ntp/drift broadcastdelay 0.008 keys /etc/ntp/keys

# cat /etc/ntp/step-tickers server01 server02

any clues?

thanks

From the ntpd documentation:

Note: Since the slew rate of typical Unix kernels is limited to 0.5 ms/s, each second of adjustment requires an amortization interval of 2000 s. Thus, an adjustment as much as 600 s will take almost 14 days to complete.

By design, ntp takes a while to correct a clock.

Cheers, Dave