GNU/Linux Desktop Survival Guide by Graham Williams
Desktop Survival Project Home Preface Advocacy History Distributions Installation Basic Survival Wajig Audio AbiWord APM Backup Bash Booting Cameras CD Chinese ChRoot Clock Commercial Conference Management Configuration CRON CVS Databases DIA Directories Disks Documentation DVD Email Eye of Gnome Evolution File Systems Firewalls Floppy Disks Fonts Ghemical GIMP Glade Gnome GnuCash Gnumeric GQView Graphics Groups HTML Editors ImageMagick Initialisations on Booting Java KDE Kernels Keyboard Konqueror KVM Switch LaTeX Log System Login Magellan Mathematics Memory Modems Mounting Devices MS/Windows Music MySQL Nautilus Networks NFS NT File System OpenOffice.org Oracle Packages Partitions Passwords PDF Photos PPP Presentations Printing Python R Remote Desktops Rsync Samba Scanning Science Security SH File System Sketch Spell SPlus Spruce SSH SUDO Subversion Swap Themes USB Video Virtualization Web Word X XML Sample Installations Troubleshooting Index

Using adjtimex

The adjtimex command can be used to counter systematic drift in the system clock. It is tricky to fine tune, and it is recommended that you use ntp instead if you can.

To set the system clock do:

# date -s "13 Jun 2001 10:10:00"

Then monitor how the system (and hardware) clock varies over 24 hours.

The adjtimex command communicates with the kernel to change the number of ticks in a day (default is 10000 which corresponds to about 8.64 seconds per tick) and the frequency (default is 0) of the system clock. In Debian you can use the command adjtimexconfig to automatically tune the tick and frequency to match the accuracy of the hardware clock (assumed to be accurate) and so that the change has effect on each boot. Alternatively, override the automatic settings by editting /etc/adjtimex.conf.

INDY The system clock was losing (very) roughly 1 second per hour. (The hardware clock seemed to lose nearly one second each day.) Not too much on the face of it but considering the machine is rarely rebooted this can become a significant drift. For this machine a tick of 10002 and a frequency of 4000000 set the clock accurately:

# adjtimex --tick 10002 --freq 4000000

On an old 486/DX66 the system clock was gaining about 22 seconds in 24 hours and the hardware clock gaining about 10 seconds in 24 hours. Removing 3 ticks had the dramatic effect of making the system clock pretty accurate.

# adjtimex --tick=9997

Velox (104.33) The system clock was losing about 1 second every hour (16 seconds in 24 hours). The hardware clock was very accurate as best I could tell. I Installed adjtimex then:

  # adjtimexconfig

This claims to adjust the ticks for the system clock against the hardware clock which is assumed to be, and generally is, accurate. However, after 24 hours the system clock was still about 5 seconds slow. I noticed the hwclock was also a few seconds out after a weekend (fix that another time). I decided to set the parameters myself by editting /etc/adjtimex.conf. Before I started it contained:

  TICK=10000
  FREQ=1653461

At 1pm, 4 Jun, reset the clocks and reset the adjustment:

# adjtimex --tick 10002 --freq 0

See how it goes. If it works then update /Path/etc/adjtimex.conf to match this.

At 4pm, 5 Jun, the clock was 10 seconds slow? Reset the clock and try (in the absence of understanding):

# adjtimex --tick 10002 --freq 4000000

At 2pm, 6 Jun (22 hours later) the clock was 9 seconds too fast. So let's half the freq and see where that gets us. Really need to set things back to base (tick 10000 and freq 0) and do the actual calculations for the value.

# adjtimex --tick 10002 --freq 2000000