UNIX for Dummies Questions & Answers

There is a command called hwclock. If you look at the the man page, where it says "hardware clock", think "bios clock". Anyway this is the command to fiddle with the bios clock.

My opinion: when a system boots it should run hwclock to suck the time out of the bios. Then it should run ntpdate to suck the time out of an NTP server... and this might fail if no NTP server is reachable. Then is should start running NTP.

And if it is running NTP the time should actually stay very accurate even if NTP servers become unavailable. Most computers have rather stable but rather inaccurate clocks.

Code:

$ cat /var/lib/ntp/drift
8.744
$

That is the clock error in parts per million. This (very roughly) means that one million + 8.744 local microseconds are needed to increment the clock by one second. ntpd will continue to enforce that metric even if an NTP server cannot be contacted. 8.744 ppm is about 5.2 seconds per week. My system time would be much better off spending a week with ntpd running without NTP servers than it would spending a week with the clock running wild.

So I'm summing up:
1. When machine boots, the hardware clock (otherwise accessible via BIOS) sets the system time with "date" command (from somewhere in rc files I guess).
2. When NTP is available, it will keep time by providing drift metrics from refence server.
3. When NTP adjustments are received, and/or when "shutdown" command is issues, the updated time value is used for adjusting hardware clock.
4. When system boots...see 1.

Am I correct?

No. First of all I was saying what I hoped would happen...there are lots of different configurations out there. Who mentioned "date" command? I said hwclock. If ntp server is available, drift will be calculated and continues to be useful if ntp server becomes unavailable. Often the shutdown script will invoke hwclock on the way down, but ntpd never invokes it.

I don't see anything in my boot scripts that uses hwclock to read the clock, so I think the Linux kernel actually consults the hardware clock itself on boot. But you've got the right idea: Read the hardware clock once, then only use the system clock from then on out. Mostly nothing touches the hardware clock. It's likely to be much lower resolution than the system clock, after all. (resolution and accuracy being not quite the same thing. the hardware clock might lose less seconds per month than the system one but can't give you numbers down to microseconds.) Your system may set it on power-off.

And most of this is configurable, so it might not always be the same. I had to edit a config file to tell my system to set the hardware clock on power-off. This is just the big picture.

I guess this is why it would be good to specify what version of Linux is involved. I am using RedHat. We install from a local server with some customizations, but I believe that the code I am about to show is standard RedHat....

On the way up the system clock is synced in /etc/rc.d/rc.sysinit via:

Code:

[ -x /sbin/hwclock ] && /sbin/hwclock $CLOCKFLAGS

On the way down there seems to be two opportunities to sync in the other direction:

Code:

# cd /etc/init.d
# grep hwclock *
halt:[ -x /sbin/hwclock ] && action $"Syncing hardware clock to system time" /sbin/hwclock $CLOCKFLAGS
ntpd:sync_hwclock() {
ntpd:   action $"Syncing hardware clock to system time" /sbin/hwclock $CLOCKFLAGS
ntpd:           [ "$SYNC_HWCLOCK" = "yes" ] && sync_hwclock
#

I would be very surprised in some distro moved this into the kernel. But then again I am frequently very surprised.

And while we are discussing Linux NTP configurations, our standard /etc/ntp.conf came with this abomination:

Code:

# Undisciplined Local Clock. This is a fake driver intended for backup
# and when no outside source of synchronized time is available. The
# default stratum is usually 3, but in this case we elect to use stratum
# 0. Since the server line does not have the prefer keyword, this driver
# is never used for synchronization, unless no other other
# synchronization source is available. In case the local host is
# controlled by some external source, such as an external oscillator or
# another protocol, the prefer keyword would cause the local host to
# disregard all other synchronization sources, unless the kernel
# modifications are in use and declare an unsynchronized condition.
#
server  127.127.1.0     # local clock
fudge   127.127.1.0 stratum 10

I wonder how widespread that is. That is a very bad idea. Undisciplined means that NTP keeps its hands off the system clock. It was intended for use on a system where the system clock is being disciplined by other software which has comminication with a very accurate clock. Also, as a kludge, it is suggested that with a cluster of computers with no way to contact a real NTP server, you could pick a system with a relatively accurate local clock, make it an NTP server, set the time and best you can, and use the above code to syncronize all the systems to your selected clock.

We were recently devestated by this collection of misfeatures. Our NTP server had all of these configuration settings. It locked up. I could not ssh in or access via the system console. It was no longer providing NTP service. So I rebooted it. It came right back up with no problems. It synced the system clock to the bios clock. But are now in EDT and bios clock still had EST, so the system time was off by one hour. NTP started and the NTP server contacted our master NTP server which is an appliance that gets its time fro the GPS satellites. When NTP first contacts an NTP server it does not instantly believe it. It takes several contacts over the space of several minutes to insure the NTP server is self-consistent before it will be accepted as a truechimer. Meanwhile the local clock is immediately accepted and selected as the primary peer. Now our NTP server sent out the wrong time to our entire campus. Other sites continued to have the correct time. Things went downhill pretty fast.

Nothing weird about the Gentoo kernels.

Tell you what, I'll boot an initrd and see what time it thinks it is.

Perderabo, Corona688,
Thank you guys for your time and explanations. In my opinion, if Perderabo would put together a breif article on timekeeping IN PLAIN ENGLISH for BEGINNERS, as he/she did for file permissions, it may have been beneficial to many. I thanked you guys in the forum, but in the real world I would buy to you both a drink (I hope you are of drinking age)