[ntp:questions] Re: NTP and Slow Computer Clock
david at djwhome.demon.co.uk
Tue Oct 5 21:32:02 UTC 2004
In article <10m5ralmpbko19d at corp.supernews.com>,
Peter Waskowic <waskowic at sedsystems.ca> wrote:
> I've got NTP running on the machine, which helps maintain the time.
> Every 30 to 40 minutes, I get a message in /var/log/messages that is of
> the form "ntpd: time reset 1.209444 s".
This is more than 500ppm, the maximum clock skew rate, so can only be
corrected by stepping.
> However, I'd like to keep time a bit more accurately. My question is:
> Can I configure ntp so that it adjusts the clock more frequently than
> every 30 or 40 minutes?
You are well outside the design envelope of ntpd, even without being
beyond the slew rate limits. ntpd is definitely not intended as a
workaround for clocks that lose ticks at random. Your problem is not
a slow clock, but one that is suffering random back steps.
Your two choices are to run ntpdate, or a simple SNTP client, polling
every five minutes or less, or to set the clock frequency in the kernel
using ntptime, or similar, based on the long term average drift due to
lost ticks. The phase locked loops in ntpd really are not suited to
handling slips like yours.
You might improve the response from ntpd by setting maxpoll very low, but
you will still have to allow for the time it takes to become confident
that something nasty has happened to the time. You will still get steps of
at least 128ms, unless you also reduce the maximum offset.
Also, make sure that HZ=100. Some recent Linux kernels make the mistake
of configuring for HZ=1000 on fast machines, which almost guarantees
lost interrupts from the Linux IDE driver.
More information about the questions