October 2014

June 09, 2009

Clock Synching is Worth Your Time

How many physical machines or virtual partitions do you have in your environment? One? Ten? Hundreds? How often do you verify that the time is set correctly on each of your servers? I've seen customers set the time on a machine using the date command, and then forget about it.

Why should you care whether your machines keep accurate time? In many environments, one server hosts a database while another hosts the application. If either doesn't maintain accurate time, problems can result. For instance, the database might think it's getting requests from the future, or from the past. Have you ever tried to troubleshoot two machines whose timestamps aren't in sync? Good luck trying to figure out what happened at a given point in time. Maybe you've tried running an HACMP failover on machines with clocks that are off, or maybe you've tried live application mobility on machines keeping different times. Each of these scenarios can introduce problems into your environment due to timing issues, and in same cases will refuse to work at all. Therefore, setting up network time protocol (NTP) is something we must do to keep our clocks in sync.

From Wikipedia: "Clock synchronization is a problem from computer science and engineering which deals with the idea that internal clocks of several computers may differ. Even when initially set accurately, real clocks will differ after some amount of time due to clock drift. Clock drift refers to several related phenomena where a clock does not run at the exact right speed compared to another clock."

Some people will run the "ntpdate –u <timeserver>" command from cron at some interval to keep clocks in sync. However, I would argue that we should set up the xntpd daemon instead. If you're unsure how to do this, keep reading.

First, determine which time server you will use. Many times a time server is already set up in your environment, so you can use that one. You'll need to edit the /etc/ntp.conf file and make changes. On a default AIX machine, at the end of the file you should find:

However, if you look at that Web site, you'll also find that you could use a sub-zone of pools based on continent or country.

According to ntp.org: "As pool.ntp.org will assign you timeservers from all over the world, time quality will not be ideal. You get a bit better result if you use the continental zones (For example europe, north-america, oceania or asia.pool.ntp.org), and even better time if you use the country zone (like ch.pool.ntp.org in Switzerland) - for all these zones, you can again use the 0, 1 or 2 prefixes, like 0.ch.pool.ntp.org. Note, however, that the country zone might not exist for your country, or might contain only one or two timeservers. If you know timeservers that are really close to you (measured by network distance, with traceroute or ping), time probably will be even better."

After set up your /etc/ntp.conf file the way you want it, save it and run startsrc –s xntpd.

Once your daemon is running, check your output with ntpq –p.

After some period of time (ntp.org says it could take up to 30 minutes), you should see:

Again from ntp.org: "The IP addresses will be different, because you've been assigned random timeservers. The essential thing is that one of the lines starts with an asterisk (*), this means your computer gets the time from the Internet."

Once you set up everything, be sure to go into /etc/rc.tcpip and uncomment the line:

start /usr/sbin/xntpd "$src_running"

This enables xntpd to restart after you reboot your machine.

Keeping all of your clocks accurate and in sync is a best practice. It should be one more step on your new server build checklists, if it isn't already.

Comments

Agree whole-heartedly. One note though. xntpd will only adjust the clock so far, so in the startup, before the start command, add "ntpdate -u server list" to bring your clock in close.. then, xntpd won't complain.

Hi Rob!
Let's asume that we have several LPARs without xntpd running, hosted on a managed frame. Each LPAR takes the time and date form the managed system so they would be in sync? Or each LPAR has its own internal clock? Thanks in advance!

IBM Systems Magazine is a trademark of International Business Machines Corporation. The editorial content of IBM Systems Magazine is placed on this website by MSP TechMedia under license from International Business Machines Corporation.