4

I've got an AMD Athlon XP-2500+ host (Shuttle MN31 motherboard, nForce 2 IGP + MCP-T chipset) running 32-bit Ubuntu 9.10 (i686 2.6.31-20-generic kernel). Unfortunately, it appears that the clock drift on it is so bad (it advances close to an extra second every minute) that ntpd can't keep the machine in sync.

How do I deal with this so I can get ntpd working?

Improve this question
0

5 Answers 5

Reset to default
7

The solution is to use the adjtimex package to let your kernel know how much time really elapses during each kernel tick. If it's idea is different from reality, the system clock will run more quickly or more slowly. I quote from Making NTP Work on Hardware with Large Clock Drift:

When installed, the package will normally run the adjtimexconfig command. This will compare the system clock to the hardware real-time clock over a period of seventy seconds or so and determine how much faster or slower the system clock is. It will then run the adjtimex command with the -t option to set the “tick” parameter, which is the number of microseconds the clock should advance with each kernel tick. It will also update the /etc/default/adjtimex file with this information so that it’s preserved across reboots.

Improve this answer
5

The issue may be one of several clocks or timers are particularly inaccurate or possibly defective oscillator or timer / clock (including RTC) passive components (quartz crystal, and any related capacitors). If this is the cause you may not be able to entirely work around it, if accurate time is critical to you.

The nVidia nForce2 chipset for motherboards is known to be very erratic. There is also the possibility that APIC and ACPI, Variable Speed Processors, and Front Side Bus (FSB) Spread Spectrum (SS) oscillators / clock issues effecting accuracy. One potential software (kernel) issue is with some versions of 2.6.x kernel mis-detecting the TSC (timestamp counter) frequency, and some AMD processors adjust TSC based on the processor's core clock speed (i.e for power-saving, similar to SpeedStep in Intel processors).

If you haven't already, look at NTP documentation for Troubleshooting problems with NTP.

If none of the above reduce the clock's erratic behaviors, then you can Manually Calibrate it using adjtimex and NTP. Be sure to delete any existing NTP drift files /var/lib/ntp/ntp.drift on Ubuntu, may be located in /etc/ntp/ on some other Unix/Linux systems) or entries in ntp.conf.

Apologies for possibly stating the obvious, but ensure you have 3 or 4 reachable NTP servers included in the NTP config file (typically /etc/ntp.conf or similar). And please use (public) servers "close" to you. Most ISP or network providers offer free access to their own internal NTP server, use it. otherwise use public servers from http://pool.ntp.org/, preferably located in your province/state or at least country.

Improve this answer
0

My current hack is to run ntpdate once a minute from root's crontab. This moves the time back by just under a second every minute. I'm not very happy with this solution. However, it does demonstrate the consistency of the drift:

ntpdate[20526]: step time server 218.45.21.199 offset -0.932912 sec
ntpdate[20549]: step time server 218.45.21.199 offset -0.932647 sec
ntpdate[20572]: step time server 218.45.21.199 offset -0.922805 sec
ntpdate[20597]: step time server 218.45.21.199 offset -0.949046 sec
ntpdate[20621]: step time server 219.117.196.238 offset -0.941480 sec
ntpdate[20650]: step time server 219.117.196.238 offset -0.925179 sec
ntpdate[20673]: step time server 219.117.196.238 offset -0.930992 sec
ntpdate[20698]: step time server 219.117.196.238 offset -0.949393 sec
ntpdate[20726]: step time server 219.117.196.238 offset -0.923139 sec
ntpdate[20751]: step time server 219.117.196.238 offset -0.933554 sec
Improve this answer
0
-1

You can edit the configuration file (/etc/ntp.conf, usually) to set a couple of helpfull things, such as minpoll:

   minpoll, maxpoll
          These options specify the minimum and maximum poll intervals for NTP messages, in seconds as a power of two.The maximum poll interval defaults to 10 (1,024 s), but can be increased by the maxpoll option to  an  upper limit  of  17 (36.4 h).  The minimum poll interval defaults to 6 (64 s), but can be decreased by the minpoll option to a lower limit of 4 (16 s).  These option are valid only with the server and peer commands.
Improve this answer
1
  • Feel free to show me wrong, but I think how often ntpd polls the peers has nothing to do with whether or not it will adjust the system clock when the clock is running at a very different rate from the peers.
    – cjs
    Commented Apr 5, 2010 at 10:52
-1

Try removing the "-g" option from ntpd's command line options.

Improve this answer
3
  • You failed to mention why, or even what this does. It adjusts the "panic threshold" where, if the time is already more than that amount (1000s by default) different from the servers, ntpd will refuse to adjust the clock. I did look at this, but it wasn't the issue; ntpd wasn't existing due to this because I was setting the clock to the correct time with ntpdate before starting ntp, so it was within the panic threshold anyway.
    – cjs
    Commented Apr 5, 2010 at 10:57
  • Well -g causes ntpd to exit at any time if it exceeds the panic threshold, not only at startup. So removing -g will make ntpd correct the drifting time during normal operations as well.
    – Ricardo Pardini
    Commented Apr 6, 2010 at 23:22
  • As far as I can see, no it will not. My ntpd is running, not exiting. It's just not correcting the time while it's running, even when it spends hours with a (steadily increasing) difference under the panic threshold.
    – cjs
    Commented Apr 7, 2010 at 4:06

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .