Back in the localisation lecture from our Linux administration course, we discussed maintaining accurate timezone settings on Linux systems through the usr/share/zoneinfo, etc/timezone, and etc/localtime files. Here we're going to discuss a critically important task of maintaining an accurate system time. While it's always nice to know that the time displayed in the clock at the corner of your desktop is accurate, this will be especially important when you're managing applications that require resource coordination across a network or over the Internet. If even one node is set to an incorrect time, you can expect to experience some really weird behavior.

Controlling Linux system clocks using hwclock

First of all, however, we'll need to distinguish between two separate and often contradicting computer time values, the hardware clock and system time. The hardware clock, also known as the real-time clock or RTC or the bias clock or the CMOS clock, is a time and date setting maintained in your motherboard's firmware and is often powered even when a system is off by a CMOS battery. While such a steady value is a necessary element of the boot process and basic hardware operation, it's not particularly reliable.

It can quickly fall out of sync with more accurate network time sources. For that reason, your operating system will usually make use of system time, which ideally is continually updated from a network time protocol or NTP server. You can display your current hardware time with hwclock -r. hwclock --hctosys will take the current hardware time value and apply it to the system clock. Of course, you can also do the opposite. That is, apply the system value to the hardware time using hwclock --systohc. This can be useful to update a hardware clock value that's fallen far out of sync with your network adjusted system time.

Remembering which of these two command arguments will set which value can be a bit confusing, but I'm afraid that the LPIC exam will simply expect you to know it. You can also set your hardware clock with either coordinated universal time, UTC, which is more or less simply changeable with Greenwich Mean Time, or local system time. hwclock --UTC or --localtime will control that setting, although either way, hwclock -r will continue to display a local time.

Finally, you can set the hardware time and date using hwclock --set --date following this format.

Let's review what we've seen so far. Computers keep time in two ways, through the hardware clock and through system time. You can control the hardware clock with hwclock. -r displays the current time. --hctosys will apply the hardware time to the system time. --systohc will apply the system time to the hardware clock. --UTC tells a hardware clock to use coordinated universal time, while --localtime applies a local time. hwclock --set lets you manually set the time.

Using NTP to manage your Linux system time

When accurate timekeeping is important, you want to make use of an NTP server through the ntpd daemon. If you don't need to install full NTP connectivity but want to manually update your time, you could use ntpdate from the command line. This can especially helpful for mobile devices that might not have regular access to real-time servers. ntpdate is also useful as a preparation for full NTP configuration to make sure that your current time isn't too far off from the official value. In some cases, if you haven't got an NTP server configured and assuming that you're running a Debian-based Linux distribution, you may want to use ntpdate -debian, which will by default poll the ntp.ubuntu.com server. Since ntpd generally won't be installed by default, you can run your distribution's package manager to bring it on board. Let's make sure that the service is actually running. ntpq will print out a list of peers currently available to NTP.

Now let's take a look at /etc/ntp.com to make sure everything is configured the way we like. The entries that interest us most right now are the server lines. Each of these defines a single upstream NTP server, which our system will query for the current time. You'll notice that each of the servers in our configuration is part of the pool.ntp.org system. Now will be a good time to explain what that's all about. NTP servers are arranged in layers, each of which is called a stratum. An NTP server that gets its data directly from a time producer like the US Naval Observatory in Bethesda, Maryland, is considered stratum 1. A server that gets its data from a stratum 1 server is known as stratum 2 and so on until stratum 15. To make sure that too many NTP clients can't overwhelm a single stratum 1 server, it's highly recommended that you tell your client to make its request from a pool of servers. The pool will automatically distribute requests among its servers by random distribution.

By default, Ubuntu installations will point to ubuntu.pool.ntp.org servers, which you could replace with the address of local network NTP servers or other offsite servers that are nevertheless accessible to you with lower latency. Our configuration also provides a non-pool fallback server, in case pool servers are inaccessible. Many admins will also add a local hosting address for this setting. The drift file that might sometimes be found in /var/lib/ntp is interesting as it contains a number that's the result of tracking the milliseconds that your local time might have drifted from your time server over the past while. This can be useful for software with built-in algorithms compensating for potential discrepancies.

NTP and slewing, stepping, and insane time

There are three more terms you'll really want to understand, slewing, stepping, and insane time. When NTP updates your clock, it'll first check to see how far up it's drifted from the true time. If it's more than 128 milleseconds off, NTP will correct the time in relatively large steps called stepping. If the difference is smaller than 128 milliseconds, then NTP will make its adjustments in smaller gradients using the process called slewing. If your system time is more than 1024 seconds off, then it's considered to be using insane time, and NTP will ignore this as source of accurate time.

Let's review. You can update your system time using ntpdate or ntpdate-debian. ntpq will display available peers. The NTP settings are kept in the /etc/ntp.com file. Ideally we connect to a server that's close to a stratum zero server with as low a latency connection to us as possible and part of a traffic distributing pool. /var/lib/ntp can contain a numeric record of a historic drift between our system and a time source. Slewing is the process of gradually adjusting the time that's not too far from the true time. Stepping is the process of more quickly making that adjustment using larger steps, and insane time is a system time that's more than 1024 seconds off.