On some hardware, the system the clock speed is somewhat different from what the hardware claims. This will cause the kernel’s idea of the current time to drift from the actual time, since the actual amount of time that elapses each kernel tick is different from what the kernel thinks (which is typically 10,000 microseconds by default).
If this drift is large enough, ntpd will unable to keep the system time synchronized with the servers to which it is talking. What you’ll typically see in this situation is that
ntpdc -p will show no servers with an asterisk next to the name (indicating it’s not synchronizing to any of them) and you’ll see the offsets creeping higher and higher in magnitude.
The fix for this is to teach the kernel what the actual time that elapses during each tick really is. This is easily done on Ubuntu and Debian systems by installing the adjtimex package.
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.
As I said above, the default tick value is 10,000, but on one of my systems that runs fast, for example, 9851 is a more accurate value. You can re-run the
adjtimexconfig command yourself at any time in order to set or update this.
Once you’ve done this, you should then see that once
ntpd has been running for a while, it selects a server, logging a message such as
ntpd: synchronized to 22.214.171.124, stratum 2 in
ntpdc -p should display an asterisk next to that same server.
Note that if you upgrade your BIOS you should certainly run
adjtimexconfig immediately afterwards, since this may change the speed that hardware reports, especially if it was previously reported incorrectly. The same goes if you change your hardware.