Your system actually has two clocks-- the battery powered ``real time clock'' that keeps track of time when the system is turned off (also known as the ``CMOS clock'', ``Hardware clock'', or ``RTC'') and the ``kernel time'' (sometimes called the ``software clock'' or ``system clock'') which is based on the timer interrupt and is initialized from the CMOS clock at boot time. The two will drift at different rates, so they will gradually drift apart from each other, and also away from the ``real'' time.
All references to ``the clock'' in the xntpd documentation
refer to the ``kernel clock''.
When you run xntpd or timed
(or any other program that uses the adjtimex system call),
the linux kernel assumes that the kernel clock is more accurate
than the CMOS clock, and resets the CMOS time every 11 minutes from then on
(until you reboot the machine).
This means that ``clock'' no longer knows
when the CMOS clock was last reset,
so you can't use the correction factor in /etc/adjtime.
You can use ntpdate in your startup file
to initially set the clock from a timeserver before starting xntpd.
If you don't always have access to an accurate time source
when you boot the machine, this can be a bit awkward--
xntpd isn't really designed to be used in situations like that.
Xntpd includes drivers for many radio clocks,
and can also be set to call NIST's dial-up time service at regular intervals
(be sure to calculate the effect on your phone bill
when setting the interval between calls).
It can also apply a correction factor to the kernel clock
if it loses contact with its other sources for an extended period of time.
Most radio clocks cost $3-4K,
but you can get plans for an inexpensive ``gadget box''
(actually a 300 baud modem) that sits between your computer
and any shortwave radio tuned to Canada's CHU time station
(see
ftp://ftp.udel.edu/pub/ntp/gadget.tar.Z).
The Heathkit WWV receiver (the ``Most Accurate Clock'')
is also still available (although not as a kit),
and costs around $4-500.
GPS signals also contain time information,
and some GPS recievers can connect to a serial port.
This may become the low cost solution in the near future.
In theory, someone could write a program to use NIST's dial up time service
to calculate the drift rate of both the CMOS clock
and the kernel clock automatically.
I am not aware of any stand-alone program to do this,
but most of the code could probably be borrowed from xntpd.