Excessive clock drift on AMD Athlon prevents ntpd from synchronizing clock

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.

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.

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

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.

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