"Linux Gazette...making Linux just a little more fun!"

The Answer Guy

By James T. Dennis, tag@lists.linuxgazette.net
Starshine Technical Services, https://www.starshine.org/

The BIOS Clock, Y2K, Linux and Everything

From Ward, David on 12 Aug 1998

Linux's initial clock settings (at boot up) are from the BIOS. However, the kernel internally keeps its own time thereafter.

It turns out that there is an immense about of work that is done on system clock synchronization over the Internet and among Unix systems.

I'm assuming that you're concerned about some specific systems that have a buggy BIOS --- that you know will report invalid dates after the year 2000.

To detect this condition you could use a script like:

CURRENT_YEAR=$( date +%Y )
FILE_YEAR=$( find /etc/README -printf "%TY" )


[ $CURRENT_YEAR -eq $FILE_YEAR ] || {
# We've suffered a backslip: the current 4 digit
# year arimetically precedes the date on our
# marker file
logger "Backslip in Time Detected ... Fixing"
# Recover here....
# After recovery and during shutdown, when
# the clock is in a known good state, we can
# touch the marker file to unsure that it's
# date is periodically updated.
}

... note that I'm using the $() (Korn/bash) construct rather than the equivalent "backtick" operators. This is to avoid ambiguity; the effect is the same.

One way to ensure that you have the correct date set on your system is to use the 'ntpdate' command around boot time. This sets your clock based on that of another system. Oddly enough, though this command is included on many Linux systems, there often seems to be no man page installed for it. However I've read the man pages at (https://www.eecis.udel.edu/~ntp) --- and they don't make things any easier.

With all due respect to Mr. Mills (one of the key figures in the NTP system) these pages (man and web) look like they were written for a federal funding grant. A simple HOWTO would be nice. (Maybe I'm just stupid but these pages seem to talk about everything other than how does a typical home or SOHO sysadmin configure their systems to have the correct time).

In any event here's the command I use to initially set my date:

/usr/sbin/ntpdate -s ntp.ucsd.edu ns.scruz.net ntp1.cs.wisc.edu

... this calls the ntpdate command and lists three time servers (stratum-2 in this case). In the complicated world of NTP the "stratum" of a clock is a measure of how "far" it is from the NIST atomic clocks which are used as the international standards. In essense it is a measure of the time server's "authority" (as in 'how authoritative is that answer'). It isn't actually a measure of how "accurate" that clock is, just how many hops are between it and the top of the hierarchy.

Thus my system (betelgeuse) becomes a "stratum-3" NTP server after I refer to these "stratum-2" servers. It is the system that I use to set the time for the rest of the house. After the time is initially set I periodically re-run this command to reset it. It reports to me the adjustment that it makes (typically under one second).

This is NOT recommended practice. (Mixing ntpdate and xntpd on a system). However, in my case, I don't want to configure my xntpd to refer to those same servers since it would mean that my ISDN router would fire up an unnecessary connection to the Internet every twenty minutes round the clock. Since I have no easy way to prevent this (the ISDN router I'm using is a separate box) I choose do use my method.

If you have a full time connection to the Internet then the best solution is to use the xntpd (extended Network Time Protocol Daemon) to keep your system clocks in sync with a set of time servers. I'd set up one or two systems on your 'perimeter' network (the one that's exposed to the Internet --- assuming you have a firewall). Then I'd have the rest of your systems use that (or those) as their time reference.

xntpd also includes support for a couple of dozen GPS and radio clock devices. These range from a couple hundred to a few thousand dollars (and typically connect to your host via a serial line).

In all cases ntpdate and xntpd use sophisticated protocols to measure latency and network communications delays and to account for deviations between the reference servers. You're pretty well guaranteed sub-second accuracy when you use them.

In some versions and configurations, the NTP suite supports cryptographic integrity preservation methods, to prevent spurious and hostiles changes to your network time references.

The web pages I referred to above does have a wealth of details about the protocols and the suite. If you can manage to decode it into a set of simple instructions for us "tape apes" I'd love to see it written up as a HOW-TO. Perhaps the subscribers to the comp.protocols.time.ntp newsgroup might be more helpful.

(My e-mail exchange with Mr. Mills on this issue was not terribly helpful).

There is one existing mini-HOWTO that could be expanded to suit the bill:

Clock Mini-HOWTO:

https://www.ssc.com/linux/LDP/HOWTO/mini/Clock.html (written by Roy Bean).

... it only contains a few words about xntpd.

Also, someone once told me about a GPS reciever that was very inexpensive. It had no display, only a DB-9 serial connector. If anyone out there knows of a reliable source for these, I'd like to know about it, and I'll be happy to publish the URL. I wouldn't mind paying $100 for a good time source --- but two or three hundred is just too much for my applications.

Copyright © 1998, James T. Dennis
Published in Linux Gazette Issue 32 September 1998

	phreak	abandon	javaterm	BBS	flaws	doslinux	resume
	softwindows	convert	apache	emulate	database	distrib	proxy
	disable	DVI	superblock	serial	permission	detach	cdr
rs422	modem	notfound	tuning	libc5	startup	clock	ping
accounts	lilo	NDS	95slow	nonlinux	progenv	cluster	ftpd