NTP Won't Sync to Slow Clocksource

Symptom:

You're using the Network Time Protocol (NTP) to synchronize your machine's clock with another time server. ntpd is properly configured and is running. But when you do ntpq -p at 5 minute intervals you see that both the offset and the jitter of your time server are allegedly over 1000 (milliseconds) and varying erratically. If you look in your syslog you find that ntpd resets the time every 10 to 15 minutes, often well over one second each time. This is unacceptable performance for NTP.

Alternatively, if you have the local time server configured on 127.127.1.0, ntpd will sync with it and the reported offset to the real time server will increase without limit; if you do date you will find that your machine's date differs from real time by the amount of the reported offset; in my case it was 2 to 3 minutes per day.

What's happening:

If your clocksource is slower or faster than real time by more than 500 PPM then ntpd's sync algorithm can't deal with it. PPM means parts per million; the clock rate has to be in the range 0.9995 to 1.0005 times the speed of real time unless you use the fix detailed below. If ntpd is authorized to believe the (incorrect) local clock it will do so; if not it will restart its sync algorithm repeatedly.

Linux can use several clocksources and will pick the best one at boot time. The High Precision Event Timer (HPET) is best, if available; on all my machines it is accurate to a few PPM. However, it has a baleful effect on the Realtime Clock, preventing the machine from waking at a specified time; see the previous bugfix for how to disable it. The next choice is the ACPI Power Management Timer (acpi_pm). I don't know what time standard it uses, but on two identical machines it is 2830 PPM slow on one, and about 2400 PPM slow on the other -- beyond ntpd's sync range.

How to fix:

The kernel time variables can be adjusted by the adjtimex program from the util-linux package. If you get them set right, ntpd can synchronize and keep the machine's clock in sync.

For reference, use adjtimex -p to print out the current values of the time variables. If you don't have /etc/adjtime already, do hwclock --systohc --utc (or --localtime if needed to dual boot Windows); this saves the current time offset in /etc/adjtime.

Stop the ntp service: /etc/init.d/ntp stop (or the equivalent on Ubuntu or Debian). You shouldn't mess with time variables when ntpd is also struggling with them.

Now do adjtimex -a. It runs for about 80 seconds, showing the tick and frequency variables every 10 seconds. And it installs the values that it has computed.

Remove ntpd's bogus drift file. Look for its name in /etc/ntp.conf, the driftfile parameter. On a SuSE system it is in /var/lib/ntp/drift/localhost. This makes ntpd start from the beginning to determine the clock rate according to the new kernel time variables. After an hour or so it will save the correct drift rate again.

Now restart ntp: /etc/init.d/ntp start. ntpd will sync right away with the time server.

You need to set the tick value at every reboot. The frequency variable is not so important because ntpd initializes this itself from the drift file. In the SuSE 11.3 distro the /etc/init.d/ntp script has a command option ntptimeset which pre-syncs the clock. It should be executed also as part of the start procedure (make sure it's not commented out; it was on my system). In the ntptimeset section before it actually syncs the time I added a command

adjtimex --tick 10025 --frequency 3132687

(filling in the values provided by adjtimex -a).