mirror of https://github.com/tLDP/LDP
841 lines
33 KiB
Plaintext
841 lines
33 KiB
Plaintext
<!doctype linuxdoc system>
|
|
|
|
<article>
|
|
|
|
<!-- Title information -->
|
|
|
|
<title>The Clock Mini-HOWTO
|
|
<author>Ron Bean, <tt><htmlurl url="mailto:rbean@execpc.com"
|
|
name="rbean@execpc.com"></tt>
|
|
<date>v2.1, November 2000
|
|
|
|
<abstract>
|
|
How to set and keep your computer's clock on time.
|
|
</abstract>
|
|
|
|
<!-- Original version Dec 1996 (ASCII only) -->
|
|
<!-- Consisted mainly of detailed instructions for clock(8) -->
|
|
|
|
<!-- Converted to SGML Aug. 1997, no changes to text -->
|
|
<!-- Thanks to qinglong@yggdrasil.com for the SGML conversion -->
|
|
|
|
<!-- Completely revised and updated July 1999 -->
|
|
<!-- Descriptions of other software and radio clocks added -->
|
|
<!-- Instructions for clock(8) retained for reference -->
|
|
|
|
<!-- Comments on DST and local time vs UTC added November 2000 -->
|
|
<!-- Also many minor edits, URL corrected for Chrony website -->
|
|
<!-- Detailed instructions for clock(8) dropped as obsolete -->
|
|
<!-- (Send email if you want a copy) -->
|
|
|
|
<!-- Table of contents -->
|
|
<toc>
|
|
|
|
<sect>Introduction
|
|
|
|
<sect1>Does Anybody Really Know What Time It Is?
|
|
|
|
<p>
|
|
The Real-Time-Clock (RTC) chips used on PC motherboards are
|
|
notoriously inaccurate, usually gaining or losing the same
|
|
amount of time each day. Linux provides a simple way to correct
|
|
for this in software, which can make the clock <em>*very*</em>
|
|
accurate, even without an external time source. But most people
|
|
don't know how to set it up, for several reasons:
|
|
|
|
<itemize>
|
|
<item>It's not mentioned in most of the general documentation
|
|
on how to set up linux, and it can't be set up
|
|
automatically (unless you have an external time source),
|
|
so the default is not to use it.
|
|
<item>If you type &dquot;<tt>man clock</tt>&dquot; you may get
|
|
the man page for <tt>clock(3)</tt>, which is not what you
|
|
want. Try &dquot;<tt>man 8 clock</tt>&dquot; or
|
|
&dquot;<tt>man 8 hwclock</tt>&dquot; (some distributions
|
|
search the man pages in numerical order if you don't give
|
|
a section number, others search in the order specified in
|
|
<tt><file>/etc/man.config</file></tt>).
|
|
<item>Most people don't seem to care what time it is anyway.
|
|
<item>Those few who do care often want to sync the system clock
|
|
to an external time source, such as a network time server
|
|
or radio clock. This makes the accuracy of the RTC
|
|
(mostly) irrelevant.
|
|
</itemize>
|
|
</p>
|
|
|
|
<p>
|
|
This mini-HOWTO describes the low-tech approach (which can be
|
|
very accurate by itself), and provides pointers to several more
|
|
sophisticated options. In most cases the documentation is well
|
|
written, so I'm not going to repeat that information here.
|
|
</p>
|
|
|
|
<p>
|
|
Previous versions included detailed instructions for the old
|
|
<tt>clock(8)</tt> program for anyone still running an older
|
|
system, but I've dropped that section because most distributions
|
|
now use <tt>hwclock(8)</tt> instead, which has much better
|
|
documentation. If you still want a copy of the <tt>clock(8)</tt>
|
|
instructions I can email them to you, but read the section on
|
|
<tt>hwclock(8)</tt> first.
|
|
</p>
|
|
|
|
<p>
|
|
<descrip>
|
|
<tag/Note/
|
|
You must be logged in as &dquot;<bf>root</bf>&dquot; to run
|
|
any program that affects the RTC or the system time, which
|
|
includes most of the programs described here. If you
|
|
normally use a graphical interface for everything, you may
|
|
also need to learn some basic unix shell commands.
|
|
</descrip>
|
|
</p>
|
|
|
|
<p>
|
|
<descrip>
|
|
<tag/Note/
|
|
If you run more than one OS on your machine, you should
|
|
only let one of them set the RTC, so they don't
|
|
confuse each other. The exception is the twice-a-year
|
|
adjustment for Daylight Saving(s) Time (see the section on
|
|
DST for details).
|
|
</descrip>
|
|
</p>
|
|
|
|
<p>
|
|
If you run a dual-boot system that spends a lot of time running
|
|
Windows, you may want to check out some of the clock software
|
|
available for that OS instead. Follow the links on the NTP
|
|
website at <url url="http://www.eecis.udel.edu/˜ntp/software.html">.
|
|
Many of the radio clocks mentioned here include software for Windows.
|
|
</p>
|
|
|
|
<sect1>Where to Find Stuff: &dquot;The Usual Places&dquot;
|
|
|
|
<p>
|
|
In some places I've mentioned that software can be downloaded
|
|
from &dquot;the usual places&dquot;, which means any place you
|
|
could download a complete Linux system if you didn't get it on a
|
|
CD-ROM. In the old days that meant the ftp archive at
|
|
sunsite.unc.edu, and various mirror sites around the world. That
|
|
site has been renamed <url url="http://metalab.unc.edu/linux/">
|
|
(since Sun no longer sponsors it). Some distributions also have
|
|
their own websites, which may include a lot of this stuff.
|
|
</p>
|
|
|
|
<p>
|
|
I assume most people get Linux on CD these days, and those CDs
|
|
often include software that is not part of the default
|
|
installation, so you may already have some of the programs
|
|
mentioned here without knowing it.
|
|
</p>
|
|
|
|
<p>
|
|
The latest version of this mini-HOWTO can be found at the home of
|
|
the Linux Documentation Project, which is currently
|
|
<url url="http://www.linuxdoc.org/"> (and is also reachable from
|
|
the metalab site mentioned above). I think all the old links are
|
|
now forwarded to this one.
|
|
</p>
|
|
|
|
<p>
|
|
All HOWTOs are written in SGML and converted to various other
|
|
formats by standardized conversion programs. Most people seem to
|
|
want the HTML version, which is at
|
|
<url url="http://www.linuxdoc.org/HOWTO/mini/Clock.html">.
|
|
Revision history can be found as comments in the SGML source.
|
|
Most Linux distributions install a complete set of HOWTO's in
|
|
<tt><file>/usr/doc/HOWTO/</file></tt> and
|
|
<tt><file>/usr/doc/HOWTO/mini</file></tt>.
|
|
</p>
|
|
|
|
<sect1>Acknowledgements
|
|
|
|
<p>
|
|
This mini-HOWTO has been greatly improved thanks to various
|
|
people who have sent me email since the first version in 1996.
|
|
In some cases they wrote with questions but ended up giving me as
|
|
much information as I gave them. Unfortunately I haven't compiled
|
|
a list of names (maybe next time). You know who you are <tt>:-)</tt>.
|
|
</p>
|
|
|
|
<sect>How Linux Keeps Track of Time
|
|
|
|
<sect1>Basic Strategies
|
|
|
|
<p>
|
|
A Linux system actually has two clocks: One is the battery
|
|
powered &dquot;Real Time Clock&dquot; (also known as the
|
|
&dquot;RTC&dquot;, &dquot;CMOS clock&dquot;, or &dquot;Hardware
|
|
clock&dquot;) which keeps track of time when the system is turned
|
|
off but is not used when the system is running. The other is the
|
|
&dquot;system clock&dquot; (sometimes called the &dquot;kernel
|
|
clock&dquot; or &dquot;software clock&dquot;) which is a software
|
|
counter based on the timer interrupt. It does not exist when the
|
|
system is not running, so it has to be initialized from the RTC
|
|
(or some other time source) at boot time. References to
|
|
&dquot;the clock&dquot; in the <tt>ntpd</tt> documentation refer
|
|
to the system clock, not the RTC.
|
|
</p>
|
|
|
|
<p>
|
|
The two clocks will drift at different rates, so they will
|
|
gradually drift apart from each other, and also away from the
|
|
&dquot;real&dquot; time. The simplest way to keep them on time is to
|
|
measure their drift rates and apply correction factors in
|
|
software. Since the RTC is only used when the system is not
|
|
running, the correction factor is applied when the clock is
|
|
read at boot time, using <tt>clock(8)</tt> or <tt>hwclock(8)</tt>.
|
|
The system clock is corrected by adjusting the rate at which the system
|
|
time is advanced with each timer interrupt, using <tt>adjtimex(8)</tt>.
|
|
</p>
|
|
|
|
<p>
|
|
A crude alternative to <tt>adjtimex(8)</tt> is to have
|
|
<tt>chron</tt> run <tt>clock(8)</tt> or <tt>hwclock(8)</tt>
|
|
periodically to sync the system time to the (corrected) RTC. This
|
|
was recommended in the <tt>clock(8)</tt> man page, and it works
|
|
if you do it often enough that you don't cause large
|
|
&dquot;jumps&dquot; in the system time, but <tt>adjtimex(8)</tt>
|
|
is a more elegant solution. Some applications may complain if the
|
|
time jumps backwards.
|
|
</p>
|
|
|
|
<p>
|
|
The next step up in accuracy is to use a program like
|
|
<tt>ntpd</tt> to read the time periodically from a network time
|
|
server or radio clock, and continuously adjust the rate of the
|
|
system clock so that the times always match, without causing
|
|
sudden &dquot;jumps&dquot; in the system time. If you always have a
|
|
network connection at boot time, you can ignore the RTC
|
|
completely and use <tt>ntpdate</tt> (which comes with the
|
|
<tt>ntpd</tt> package) to initialize the system clock from a
|
|
time server-- either a local server on a LAN, or a remote server
|
|
on the internet. But if you sometimes don't have a network
|
|
connection, or if you need the time to be accurate during the
|
|
boot sequence before the network is active, then you need to
|
|
maintain the time in the RTC as well.
|
|
</p>
|
|
|
|
<sect1>Potential Conflicts
|
|
|
|
<p>
|
|
It might seem obvious that if you're using a program like
|
|
<tt>ntpd</tt>, you would want to sync the RTC to the (corrected)
|
|
system clock. But this turns out to be a bad idea if the system
|
|
is going to stay shut down longer than a few minutes, because it
|
|
interferes with the programs that apply the correction factor to
|
|
the RTC at boot time.
|
|
</p>
|
|
|
|
<p>
|
|
If the system runs 24/7 and is always rebooted immediately
|
|
whenever it's shut down, then you can just set the RTC from the
|
|
system clock right before you reboot. The RTC won't drift enough
|
|
to make a difference in the time it takes to reboot, so you don't
|
|
need to know its drift rate.
|
|
</p>
|
|
|
|
<p>
|
|
Of course the system may go down unexpectedly, so some versions
|
|
of the kernel sync the RTC to the system clock every 11 minutes
|
|
if the system clock has been adjusted by another program. The RTC
|
|
won't drift enough in 11 minutes to make any difference, but if
|
|
the system is down long enough for the RTC to drift
|
|
significantly, then you have a problem: the programs that apply
|
|
the drift correction to the RTC need to know <em>*exactly*</em>
|
|
when it was last reset, and the kernel doesn't record that
|
|
information anywhere.
|
|
</p>
|
|
|
|
<p>
|
|
Some unix &dquot;traditionalists&dquot; might wonder why anyone
|
|
would run a linux system less than 24/7, but some of us run
|
|
dual-boot systems with another OS running some of the time, or
|
|
run Linux on laptops that have to be shut down to conserve
|
|
battery power when they're not being used. Other people just
|
|
don't like to leave machines running unattended for long periods
|
|
of time (even though we've heard all the arguments in favor of
|
|
it). So the &dquot;every 11 minutes&dquot; feature becomes a bug.
|
|
</p>
|
|
|
|
<p>
|
|
This &dquot;feature/bug&dquot; appears to behave differently in
|
|
different versions of the kernel (and possibly in different
|
|
versions of <tt>xntpd</tt> and <tt>ntpd</tt> as well), so if
|
|
you're running both <tt>ntpd</tt> and <tt>hwclock</tt> you may
|
|
need to test your system to see what it actually does. If you
|
|
can't keep the kernel from resetting the RTC, you might have to
|
|
run without a correction factor on the RTC.
|
|
</p>
|
|
|
|
<p>
|
|
The part of the kernel that controls this can be found in
|
|
<tt><file>/usr/src/linux-2.0.34/arch/i386/kernel/time.c</file></tt>
|
|
(where the version number in the path will be the version of the
|
|
kernel you're running). If the variable <tt>time_status</tt> is
|
|
set to <tt>TIME_OK</tt> then the kernel will write the system
|
|
time to the RTC every 11 minutes, otherwise it leaves the RTC
|
|
alone. Calls to <tt>adjtimex(2)</tt> (as used by <tt>ntpd</tt>
|
|
and <tt>timed</tt>, for example) may turn this on. Calls to
|
|
<tt>settimeofday(2)</tt> will set <tt>time_status</tt> to
|
|
<tt>TIME_UNSYNC</tt>, which tells the kernel not to adjust the
|
|
RTC. I have not found any real documentation on this.
|
|
</p>
|
|
|
|
<p>
|
|
I've heard reports that some versions of the kernel may have
|
|
problems with &dquot;sleep modes&dquot; that shut down the CPU to
|
|
save energy. The best solution is to keep your kernel up to date,
|
|
and refer any problems to the people who maintain the kernel.
|
|
</p>
|
|
|
|
<p>
|
|
If you get bizarre results from the RTC you may have a hardware
|
|
problem. Some RTC chips include a lithium battery that can run
|
|
down, and some motherboards have an option for an external
|
|
battery (be sure the jumper is set correctly). The same battery
|
|
maintains the CMOS RAM, but the clock takes more power and is
|
|
likely to fail first. Bizarre results from the system clock may
|
|
mean there is a problem with interrupts.
|
|
</p>
|
|
|
|
<sect1>Should the RTC use Local Time or UTC, and What About DST?
|
|
|
|
<p>
|
|
The Linux &dquot;system clock&dquot; actually just counts the
|
|
number of seconds past Jan 1, 1970, and is always in UTC (or GMT,
|
|
which is technically different but close enough that casual users
|
|
tend to use both terms interchangeably). UTC does not change as
|
|
DST comes and goes-- what changes is the <em>conversion</em> between UTC
|
|
and local time. The translation to local time is done by
|
|
library functions that are linked into the application programs.
|
|
</p>
|
|
|
|
<p>
|
|
This has two consequences: First, any application that needs
|
|
to know the local time also needs to know what time zone you're
|
|
in, and whether DST is in effect or not (see the next section for
|
|
more on time zones). Second, there is no provision in the kernel to
|
|
change either the system clock or the RTC as DST comes and goes,
|
|
because UTC doesn't change. Therefore, machines that only run
|
|
Linux should have the RTC set to UTC, not local time.
|
|
</p>
|
|
|
|
<p>
|
|
However, many people run dual-boot systems with other OS's that
|
|
expect the RTC to contain the local time, so <tt>hwclock</tt>
|
|
needs to know whether your RTC is in local time or UTC, which it
|
|
then converts to seconds past Jan 1, 1970 (UTC). This still does
|
|
not provide for seasonal changes to the RTC, so the change must
|
|
be made by the other OS (this is the one exception to the rule
|
|
against letting more than one program change the time in the RTC).
|
|
</p>
|
|
|
|
<p>
|
|
Unfortunately, there are no flags in the RTC or the CMOS RAM to
|
|
indicate standard time vs DST, so each OS stores this information
|
|
someplace where the other OS's can't find it. This means that
|
|
<tt>hwclock</tt> must assume that the RTC always contains the
|
|
correct local time, even if the other OS has not been run since
|
|
the most recent seasonal time change.
|
|
</p>
|
|
|
|
<p>
|
|
If Linux is running when the seasonal time change occurs, the
|
|
system clock is unaffected and applications will make the
|
|
correct conversion. But if linux has to be rebooted for any
|
|
reason, the system clock will be set to the time in the RTC,
|
|
which will be off by one hour until the other OS (usually
|
|
Windows) has a chance to run.
|
|
</p>
|
|
|
|
<p>
|
|
There is no way around this, but Linux doesn't crash very often,
|
|
so the most likely reason to reboot on a dual-boot system is to
|
|
run the other OS anyway. But beware if you're one of those people
|
|
who shuts down Linux whenever you won't be using it for a while--
|
|
if you haven't had a chance to run the other OS since the last
|
|
time change, the RTC will be off by an hour until you do.
|
|
</p>
|
|
|
|
<p>
|
|
Some other documents have stated that setting the RTC to UTC
|
|
allows Linux to take care of DST properly. This is not really
|
|
wrong, but it doesn't tell the whole story-- as long as you don't
|
|
reboot, it does not matter which time is in the RTC (or even if
|
|
the RTC's battery dies). Linux will maintain the correct time
|
|
either way, until the next reboot. In theory, if you only reboot
|
|
once a year (which is not unreasonable for Linux), DST could come
|
|
and go and you'd never notice that the RTC had been wrong for
|
|
several months, because the system clock would have stayed
|
|
correct all along. But since you can't predict when you'll want
|
|
to reboot, it's better to have the RTC set to UTC if you're not
|
|
running another OS that requires local time.
|
|
</p>
|
|
|
|
<p>
|
|
The Dallas Semiconductor RTC chip (which is a drop-in replacement
|
|
for the Motorola chip used in the IBM AT and clones) actually has
|
|
the ability to do the DST conversion by itself, but this feature
|
|
is not used because the changeover dates are hard-wired into the
|
|
chip and can't be changed. Current versions change on the first
|
|
Sunday in April and the last Sunday in October, but earlier
|
|
versions used different dates (and obviously this doesn't work in
|
|
countries that use other dates). Also, the RTC is often
|
|
integrated into the motherboard's &dquot;chipset&dquot; (rather
|
|
than being a separate chip) and I don't know if they all have
|
|
this ability.
|
|
</p>
|
|
|
|
<sect1>How Linux keeps Track of Time Zones
|
|
|
|
<p>
|
|
You probably set your time zone correctly when you
|
|
installed Linux. But if you have to change it for some reason, or
|
|
if the local laws regarding DST have changed (as they do
|
|
frequently in some countries), then you'll need to know how to
|
|
change it. If your system time is off by some exact number of
|
|
hours, you may have a time zone problem (or a DST problem).
|
|
</p>
|
|
|
|
<p>
|
|
Time zone and DST information is stored in
|
|
<tt><file>/usr/share/zoneinfo</file></tt> (or
|
|
<tt><file>/usr/lib/zoneinfo</file></tt> on older systems).
|
|
The local time zone is determined by a symbolic link from
|
|
<tt><file>/etc/localtime</file></tt> to one of these files.
|
|
The way to change your timezone is to change the link.
|
|
If your local DST dates have changed, you'll have to edit the
|
|
file.
|
|
</p>
|
|
|
|
<p>
|
|
You can also use the <tt>TZ</tt> environment variable to change
|
|
the current time zone, which is handy of you're logged in
|
|
remotely to a machine in another time zone. Also see the man
|
|
pages for <tt>tzset</tt> and <tt>tzfile</tt>.
|
|
</p>
|
|
|
|
<p>
|
|
This is nicely summarized at
|
|
<url url="http://www.linuxsa.org.au/tips/time.html">
|
|
</p>
|
|
|
|
<sect1>The Bottom Line
|
|
|
|
<p>
|
|
If you don't need sub-second accuracy, <tt>hwclock(8)</tt> and
|
|
<tt>adjtimex(8)</tt> may be all you need. It's easy to get
|
|
enthused about time servers and radio clocks and so on, but I ran
|
|
the old <tt>clock(8)</tt> program for years with excellent results.
|
|
On the other hand, if you have several machines on a LAN it can be
|
|
handy (and sometimes essential) to have them automatically sync
|
|
their clocks to each other. And the other stuff can be fun to
|
|
play with even if you don't really need it.
|
|
</p>
|
|
|
|
<p>
|
|
On machines that only run Linux, set the RTC to UTC (or GMT).
|
|
On dual-boot systems that require local time in the RTC, be aware
|
|
that if you have to reboot Linux after the seasonal time change,
|
|
the clock may be temporarily off by one hour, until you have a
|
|
chance to run the other OS. If you run more than two OS's, be
|
|
sure only one of them is trying to adjust for DST.
|
|
</p>
|
|
|
|
<sect>Software
|
|
|
|
<sect1>Clock(8) and Hwclock(8)
|
|
|
|
<p>
|
|
All linux distributions install either the old <tt>clock(8)</tt>
|
|
or the newer <tt>hwclock(8)</tt>, but without a correction
|
|
factor. Some may also install <tt>adjtimex(8)</tt>, or they may
|
|
include it on the CD as optional (or you can download it from
|
|
the usual Linux archive sites). Some distributions also include
|
|
a graphical clock setting program that runs in an X-window, but
|
|
those are designed for interactive use, and the system will still
|
|
install <tt>clock(8)</tt> or <tt>hwclock(8)</tt> for use in the
|
|
startup scripts.
|
|
</p>
|
|
|
|
<p>
|
|
<tt>Clock(8)</tt> requires you to calculate the correction factor
|
|
by hand, but <tt>hwclock(8)</tt> calculates it automatically
|
|
whenever you use it to reset the RTC (using another program to
|
|
set the RTC will interfere with the drift correction, so always
|
|
use the same program if you're using a correction factor). If you
|
|
have an older system that still uses <tt>clock(8)</tt> and you
|
|
want to upgrade, you can find <tt>hwclock(8)</tt> in the
|
|
&dquot;<tt>util-linux</tt>&dquot; package, version 2.7 or later.
|
|
See the man page for more information.
|
|
</p>
|
|
|
|
<p>
|
|
<descrip>
|
|
<tag/Note/
|
|
The man page for <tt>hwclock(8)</tt> may be called
|
|
&dquot;<tt>clock</tt>&dquot; for backward compatibility, so
|
|
try both names. <tt>Hwclock(8)</tt> will respond to commands
|
|
written for <tt>clock(8)</tt>, but the result may not be the
|
|
same-- in particular, &dquot;<tt>hwclock -a</tt>&dquot; is
|
|
not quite the same as &dquot;<tt>clock -a</tt>&dquot;, so if
|
|
you're upgrading to <tt>hwclock</tt> I'd suggest replacing
|
|
all references to &dquot;<tt>clock</tt>&dquot; in your
|
|
startup scripts to use <tt>hwclock</tt>'s native commands
|
|
instead.
|
|
</descrip>
|
|
</p>
|
|
|
|
<p>
|
|
The startup scripts vary from one distribution to another, so you
|
|
may have to search a bit to find where it sets the clock. Typical
|
|
locations are <tt><file>/etc/rc.local</file></tt>,
|
|
<tt><file>/etc/rc.d/rc.sysinit</file></tt>,
|
|
<tt><file>/etc/rc.d/boot</file></tt>, or some
|
|
similar place.
|
|
</p>
|
|
|
|
<p>
|
|
The correction factor for the RTC is stored in
|
|
<tt><file>/etc/adjtime</file></tt>.
|
|
Red Hat has a script in
|
|
<tt><file>/etc/sysconfig/clock</file></tt> that controls the
|
|
options to <tt>hwclock</tt>.
|
|
</p>
|
|
|
|
<p>
|
|
When you're setting the clock to determine the drift rate, keep
|
|
in mind that your local telephone time announcement may or may
|
|
not be accurate. If you don't have a shortwave radio or GPS
|
|
receiver, you can hear the audio feed from WWV by calling
|
|
(303)499-7111 (this is a toll call to Boulder, Colorado). It
|
|
will cut you off after three minutes, but that should be long
|
|
enough to set the clock. USNO and Canada's CHU also have
|
|
telephone time services, but I prefer WWV's because there is
|
|
more time between the announcement and the &dquot;beep&dquot;.
|
|
You can also get the time from a network time server using the
|
|
<tt>ntpdate</tt> program that comes with <tt>ntpd</tt>, and
|
|
there's a javaclock at <url url="www.time.gov">.
|
|
</p>
|
|
|
|
<p>
|
|
In any case, what you're setting is the system clock, not the RTC
|
|
(see the man page for the <tt>date</tt> command for the formats
|
|
to use). Then use <tt>hwclock</tt> to set the RTC and calculate
|
|
the drift rate. If you're doing this by hand, you should be able
|
|
to set it within a second or two, and get a reasonable
|
|
approximation of the drift rate after a few weeks. Then you can
|
|
run <tt>adjtimex(8)</tt> to fine-tune the system clock.
|
|
</p>
|
|
|
|
<sect1>Adjtimex(8)
|
|
|
|
<p>
|
|
<tt>Adjtimex(8)</tt> allows the user to adjust the kernel's time
|
|
variables, and therefore change the speed of the system clock
|
|
(you must be logged in as &dquot;<bf>root</bf>&dquot; to do
|
|
this). It is cleverly designed to compare the system clock to the
|
|
RTC using the same correction factor used by <tt>clock(8)</tt> or
|
|
<tt>hwclock(8)</tt>, as stored in <tt><file>/etc/adjtime</file></tt>.
|
|
So, once you've established the drift rate of the RTC, it's fairly simple
|
|
to correct the system clock as well. Once you've got it running
|
|
at the right speed, you can add a line to your startup scripts to
|
|
set the correct kernel variables at boot time. Since
|
|
<tt>adjtimex(8)</tt> was designed to work with <tt>clock(8)</tt>
|
|
or <tt>hwclock(8)</tt>, it includes a work-around for the
|
|
&dquot;every 11 minutes&dquot; bug.
|
|
</p>
|
|
|
|
<p>
|
|
After you've installed <tt>adjtimex(8)</tt> you can get more
|
|
information on setting it up by typing &dquot;<tt>man 8
|
|
adjtimex</tt>&dquot; (there is also an <tt>adjtimex(2)</tt> man
|
|
page, which is not what you want) and by reading the
|
|
<tt>README</tt> file in <tt><file>/usr/doc/adjtimex-1.3/README</file></tt>
|
|
(where the version number in the path will be the current version
|
|
of <tt>adjtimex(8)</tt>).
|
|
</p>
|
|
|
|
<sect1>Xntpd and ntpd: the Network Time Protocol
|
|
|
|
<p>
|
|
<tt>Xntpd</tt> (NTPv3) has been replaced by <tt>ntpd</tt>
|
|
(NTPv4); the earlier version is no longer being maintained.
|
|
</p>
|
|
|
|
<p>
|
|
<tt>Ntpd</tt> is the standard program for synchronizing clocks
|
|
across a network, and it comes with a list of public time servers
|
|
you can connect to. It can be a little more complicated to set up
|
|
than the other programs described here, but if you're interested
|
|
in this kind of thing I highly recommend that you take a look at
|
|
it anyway.
|
|
</p>
|
|
|
|
<p>
|
|
The &dquot;home base&dquot; for information on <tt>ntpd</tt>
|
|
is the NTP website at <url url="http://www.eecis.udel.edu/˜ntp/">
|
|
which also includes links to all kinds of interesting time-related
|
|
stuff (including software for other OS's). Some linux
|
|
distributions include <tt>ntpd</tt> on the CD. There is a list of
|
|
public time servers at
|
|
<url url="http://www.eecis.udel.edu/˜mills/ntp/clock2.html">.
|
|
</p>
|
|
|
|
<p>
|
|
A relatively new feature in <tt>ntpd</tt> is a &dquot;burst mode&dquot;
|
|
which is designed for machines that have only intermittent
|
|
dial-up access to the internet.
|
|
</p>
|
|
|
|
<p>
|
|
<tt>Ntpd</tt> includes drivers for quite a few radio clocks
|
|
(although some appear to be better supported than others). Most
|
|
radio clocks are designed for commercial use and cost thousands
|
|
of dollars, but there are some cheaper alternatives (discussed in
|
|
later sections). In the past most were WWV or WWVB receivers, but
|
|
now most of them seem to be GPS receivers. NIST has a PDF file
|
|
that lists manufacturers of radio clocks on their website at
|
|
<url url="http://www.boulder.nist.gov/timefreq/links.htm"> (near
|
|
the bottom of the page). The NTP website also includes many links
|
|
to manufacturers of radio clocks at
|
|
<url url="http://www.eecis.udel.edu/˜ntp/hardware.htm"> and
|
|
<url url="http://www.eecis.udel.edu/˜mills/ntp/refclock.htm">.
|
|
Either list may or may not be up to date at any given time <tt>:-)</tt>.
|
|
The list of drivers for <tt>ntpd</tt> is at
|
|
<url url="http://www.eecis.udel.edu/˜ntp/ntp_spool/html/refclock.htm">.
|
|
</p>
|
|
|
|
<p>
|
|
<tt>Ntpd</tt> also includes drivers for several dial-up time
|
|
services. These are all long-distance (toll) calls, so be sure to
|
|
calculate the effect on your phone bill before using them.
|
|
</p>
|
|
|
|
<sect1>Chrony
|
|
|
|
<p>
|
|
<tt>Xntpd</tt> was originally written for machines that have a
|
|
full-time connection to a network time server or radio clock. In
|
|
theory it can also be used with machines that are only connected
|
|
intermittently, but Richard Curnow couldn't get it to work the
|
|
way he wanted it to, so he wrote &dquot;<tt>chrony</tt>&dquot; as an
|
|
alternative for those of us who only have network access when
|
|
we're dialed in to an ISP (this is the same problem that
|
|
<tt>ntpd</tt>'s new &dquot;burst mode&dquot; was designed to solve).
|
|
The current version of <tt>chrony</tt> includes drift correction
|
|
for the RTC, for machines that are turned off for long periods of
|
|
time.
|
|
</p>
|
|
|
|
<p>
|
|
You can get more information from Richard Curnow's website at
|
|
<url url="http://www.rrbcurnow.freeuk.com/chrony"> or
|
|
<url url="http://go.to/chrony">.
|
|
There are also two <tt>chrony</tt> mailing lists, one for
|
|
announcements and one for discussion by users. For information
|
|
send email to
|
|
<tt><htmlurl url="mailto:chrony-users-subscribe@egroups.com"
|
|
name="chrony-users-subscribe@egroups.com"></tt>
|
|
or
|
|
<tt><htmlurl url="mailto:chrony-announce-subscribe@egroups.com"
|
|
name="chrony-announce-subscribe@egroups.com"></tt>
|
|
</p>
|
|
|
|
<p>
|
|
Chrony is normally distributed as source code only, but Debian
|
|
has been including a binary in their &dquot;unstable&dquot;
|
|
collection. The source file is also available at the usual Linux
|
|
archive sites.
|
|
</p>
|
|
|
|
<sect1>Clockspeed
|
|
|
|
<p>
|
|
Another option is the <tt>clockspeed</tt> program by DJ
|
|
Bernstein. It gets the time from a network time server and simply
|
|
resets the system clock every three seconds. It can also be used
|
|
to synchronize several machines on a LAN.
|
|
</p>
|
|
|
|
<p>
|
|
I've sometimes had trouble reaching his website at
|
|
<url url="http://Cr.yp.to/clockspeed.html">, so if you get a DNS
|
|
error try again on another day. I'll try to update this
|
|
section if I get some better information.
|
|
</p>
|
|
|
|
<sect>Radio Clocks
|
|
|
|
<sect1>CHU and the &dquot;Gadget Box&dquot;
|
|
|
|
<p>
|
|
CHU, the Canadian shortwave time station near Ottawa, is similar
|
|
to WWV in the US but with one important difference: in addition
|
|
to announcing the time in both French and English, it also
|
|
broadcasts the current time once per minute using the old &dquot;Bell
|
|
103&dquot; (300 baud) modem tones. These tones are very easy to
|
|
decode, and Bill Rossi realised that you don't even need a
|
|
modem-- just a shortwave radio and a sound card. If you're able
|
|
to receive the signal from CHU, this may be the cheapest radio
|
|
clock available. Shortwave reception varies throughout the day,
|
|
but Bill claims that by changing frequencies twice a day (morning
|
|
and evening) he gets almost 24-hour coverage. CHU broadcasts on
|
|
3.33, 7.335, and 14.670 MHz.
|
|
</p>
|
|
|
|
<p>
|
|
For more information see Bill Rossi's website at
|
|
<url url="http://www.rossi.com/chu/">. The source file is also
|
|
available at the usual Linux archive sites. For information on
|
|
CHU's time services see
|
|
<url url="http://www.nrc.ca/inms/time/ctse.html">.
|
|
</p>
|
|
|
|
<p>
|
|
The NTP website has plans for a &dquot;gadget box&dquot; that
|
|
decodes the CHU time broadcast using an inexpensive 300 baud
|
|
modem chip and any shortwave radio, at
|
|
<url url="http://www.eecis.udel.edu/˜ntp/ntp_spool/html/gadget.htm">.
|
|
The plans include a Postscript image of a
|
|
2-sided custom printed circuit board, but you have to make the
|
|
board yourself (or find someone who can make it for you).
|
|
</p>
|
|
|
|
<p>
|
|
<tt>Ntpd</tt> includes a driver (type 7) for CHU receivers, which
|
|
works either with modems like the &dquot;<tt>gadget box</tt>&dquot;,
|
|
or by feeding the audio directly into the mic input of a Sun SPARCstation
|
|
(or any other machine with &dquot;compatible audio drivers&dquot;).
|
|
</p>
|
|
|
|
<sect1>WWV and the &dquot;Most Accurate Clock&dquot;
|
|
|
|
<p>
|
|
You may have heard about Heathkit's &dquot;Most Accurate Clock&dquot;,
|
|
which received and decoded the time signal from WWV and had an
|
|
optional serial port for connecting to a computer. Heathkit
|
|
stopped selling kits a long time ago, but they continued to sell
|
|
the factory-built version of the clock until 1995, when it was
|
|
also discontinued. For Heathkit nostalgia (not including the
|
|
clock) see <url url="http://www.heathkit-museum.com">. The
|
|
Heathkit company still exists, selling educational materials. See
|
|
<url url="http://www.heathkit.com">.
|
|
</p>
|
|
|
|
<p>
|
|
According to Dave Mills, Heathkit's patent on the &dquot;Most Accurate
|
|
Clock&dquot; is due to expire soon, so maybe someone out there would
|
|
like to clone it as a single-chip IC.
|
|
</p>
|
|
|
|
<p>
|
|
The NTP website has a DSP program (and a PDF file describing it) at
|
|
<url url="http://www.eecis.udel.edu/˜mills/resource.htm">
|
|
that decodes the WWV time signal using a shortwave radio and the
|
|
TAPR/AMSAT DSP-93, a DSP kit which is no longer available. It was
|
|
based on the Texas Instruments TMS320C25 DSP chip. The TAPR
|
|
website at <url url="http://www.tapr.org"> includes a lot of
|
|
information on homebrew DSP programming.
|
|
</p>
|
|
|
|
<p>
|
|
<tt>Ntpd</tt> includes a driver (type 6) for the IRIG-B and
|
|
IRIG-E time codes, using <tt><file>/dev/audio</file></tt> on a
|
|
Sun SPARCstation, with a note that it is &dquot;likely portable
|
|
to other systems&dquot;. WWV uses the IRIG-H time code.
|
|
</p>
|
|
|
|
<p>
|
|
WWV is run by NIST, which has a website at
|
|
<url url="http://www.boulder.nist.gov/timefreq/index.html">.
|
|
This site includes the text of &dquot;Special Publication 432&dquot;,
|
|
which describes their time and frequency services, at
|
|
<url url="http://www.boulder.nist.gov/timefreq/pubs/sp432/sp432.htm">.
|
|
WWV broadcasts on 2.5, 5, 10, 15, and 20 Mhz.
|
|
</p>
|
|
|
|
<sect1>GPS and the &dquot;Totally Accurate Clock&dquot;
|
|
|
|
<p>
|
|
GPS signals include the correct time, and some GPS receivers have
|
|
serial ports. <tt>Ntpd</tt> includes drivers for several GPS
|
|
receivers. The 1PPS feature (&dquot;One Pulse Per Second&dquot;,
|
|
required for high accuracy) usually requires a separate interface
|
|
to connect it to the computer.
|
|
</p>
|
|
|
|
<p>
|
|
TAPR (Tuscon Amateur Packet Radio) makes a kit for an interface
|
|
called &dquot;TAC-2&dquot; (for &dquot;Totally Accurate
|
|
Clock&dquot;) that plugs into a serial port and works with any
|
|
GPS receiver that can provide a 1PPS output-- including some
|
|
&dquot;bare board&dquot; models that can be mounted directly to
|
|
the circuit board. For more information see their website at
|
|
<url url="http://www.tapr.org">. The price (as of June 1999) is around
|
|
$140, not including the GPS receiver. The kit does not
|
|
include any enclosure or mounting hardware.
|
|
</p>
|
|
|
|
<p>
|
|
The CHU &dquot;gadget box&dquot; (described in another section)
|
|
can also be used as an interface for the 1PPS signal. The NTP website
|
|
has a discussion of this at
|
|
<url url="http://www.eecis.udel.edu/˜ntp/ntp_spool/html/pps.htm">.
|
|
</p>
|
|
|
|
<sect1>Low-frequency Time Signals: DCF77, MSF(Rugby), WWVB
|
|
|
|
<p>
|
|
These low-frequency stations broadcast a time code by simply
|
|
switching the carrier on and off. Each station uses its own
|
|
coding scheme, and summaries are available on the NTP website at
|
|
<url url="http://www.eecis.udel.edu/˜mills/ntp/index.htm">
|
|
(near the bottom of the page). DCF77 in Germany broadcasts on
|
|
77.5kHz. MSF in England (also called &dquot;Rugby&dquot;, which
|
|
apparently refers to its location) and WWVB in Colorado both
|
|
broadcast on 60 kHz.
|
|
</p>
|
|
|
|
<p>
|
|
Reception of WWVB varies, but there are plans to increase its
|
|
broadcast power, in several stages. You can follow its progress
|
|
on NIST's website at
|
|
<url url="http://www.boulder.nist.gov/timefreq/wwvstatus.html">.
|
|
</p>
|
|
|
|
<p>
|
|
Inexpensive receivers that can plug into a serial port are
|
|
reported to be available in Europe. <tt>Ntpd</tt> includes
|
|
drivers for a couple of MSF receivers.
|
|
</p>
|
|
|
|
<p>
|
|
A number of companies in the US sell relatively inexpensive
|
|
clocks that have built-in WWVB receivers (including several
|
|
analog wall clocks), but I'm only aware of two that can be
|
|
connected to a computer:
|
|
</p>
|
|
|
|
<p>
|
|
The Ultralink Model 320 sells for about $120 (as of June
|
|
1999) and has a serial interface and a straightforward ASCII
|
|
command set, so it shouldn't be too hard to program. It draws 1mA
|
|
from the serial port for power. The antenna can be up to 100 feet
|
|
away from the computer, and the unit contains its own clock to
|
|
maintain the time if it loses the signal. They also sell a
|
|
&dquot;bare board&dquot; version for about $80 that is
|
|
designed to work with the &dquot;BASIC Stamp&dquot; series of
|
|
microcontrollers. See <url url="http://www.ulio.com/timepr.html">.
|
|
</p>
|
|
|
|
<p>
|
|
Arcron Technology sells a desk clock with an optional serial
|
|
port for about $130, including software for Windows. See
|
|
<url url="http://www.arctime.com">
|
|
</p>
|
|
|
|
</article>
|