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
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 at ...> 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