Time Travel

I'm sure the following scenario will be familiar to all of you. You're in a group and someone asks the time. It might go something like this:

It's 9:15.
No, it's 9:14.
Uh uh, it's 9:16.
Actually, it's 9:15:47

I'm sure you've seen these conversations before. They are representative of competition amongst individuals and of the variance in time pieces. Everyone has a different opinion and everyone thinks they are right. In most cases, such differences are not very important. Most people are happy to have their watches accurate to within a few minutes. Such an inaccuracy doesn't make a difference with individuals. This is not always the case with computers.

Most computers do not have accurate time pieces. As an example, try setting the time on your computer, and then check it a week later. Most computers will be out by a minute or more. This may not seem like much, but over a month, the difference will be nearly five minutes, and over a year, nearly an hour. But there is an easy solution to time drift.

FreeBSD Time

FreeBSD has a good solution for storing time: it stores the time in two parts. First, it stores the time as the number of seconds since 1 January 1970. This time is known as UTC, which is Universal Coordinated Time, the international time zone (similar but not quite the same as Greenwich Mean Time (GMT). FreeBSD also records the time zone in which the computer is located. Between UTC and the time zone, the computer can determine the local time.

The time can be changed manually using the date command. An example, taken from the date man pages, follows:

	date 8506131627
  

sets the date to "June 13, 1985, 4:27 PM".

The time zone can be set using the tzsetup command. Information about the time zone is stored in /etc/localtime. This file is not an ASCII file, so please don't try to modify it directly.

Internet time servers

As more and more computers were connected together, the consequences of inaccurate time became evident. The solution seems simple: create a super-accurate time piece, connect it to a computer (the server), and let all the other computers get their time from that server. The problem is scalability. It is unrealistic to have a single computer service all other computers. The solution is distribution. Instead of one computer with an accurate time piece, we have many. And instead of having every computer talk to one of these servers, we delegate. I will explain this delegation later in this article.

Internet computers use the ntp (Network Time Protocol) service for time synchronization. This service uses port 123. There are many computers around the world which provide an ntp server. I suggest you use your ISP. If your ISP does not provide such a service, urge them to do so.

Time synchronization

If you are always connected to the Internet, I recommend you use xntpd. Otherwise, you should use ntpdate.

xntpd

xntpd is a Network Time Protocol daemon. It comes with FreeBSD and very little effort is required to get it running. It runs all the time, so it is best suited to systems which are always connected to the Internet.

In the , I found a message which showed how to install xntpd. In brief, it outlined the following steps.

Create a file /etc/ntp.conf which contains the following:

	server		truechimer.waikato.ac.nz
	driftfile	/etc/ntp.drift
  

You will not want to use the server listed above unless you are in or near New Zealand. You should obtain the address of a closer time server from one of the resources listed later in this article. If you choose a server that is too far away, the time will not be as accurate as it can be, which defeats the purpose of this exercise.

The file /etc/ntp.drift is used by the program to record information about your clock and is used to improve the accuracy of the time.

To ensure that xntpd is started automatically when the system boots, look for the following lines within /etc/rc.conf and make them look like this:

	xntpd_enable="YES"      # Run xntpd Network Time Protocol (or NO).
	xntpd_program="xntpd"   # path to xntpd, if you want a different one.
	xntpd_flags="-c /etc/ntp.conf -p /var/run/xntpd.pid"  # Flags to xntpd
  

The flags tell xntpd to use the configuration file we created above and specifies the name of the file to record the daemon's process id. Note that xntpd defaults to this configuration file, so this flag is redundant.

To start xntpd manually, just enter the following command:

	# xntpd -c /etc/ntp.conf -p /var/run/xntpd.pid
  

For more information on xntpd, try man xntpd or the .

ntpdate

ntpdate is similar to xntpd except that it does not run as a daemon. If you do not have a permanent connection, you should use this application instead of xntpd (which would probably become annoyed and not keep accurate time).

To use ntpdate, use the following command:

	# ntpdate truechimer.waikato.ac.nz
  

As with xntpd, you will not want to use the server listed above unless you are in or near New Zealand. You should obtain the address of a closer time server from one of the resources listed in the next section. If you choose a server that is too far away, the time will not be as accurate as it can be, which defeats the purpose of this exercise.

Use your FreeBSD box as a time server for your subnet

In the above examples, we installed xntpd to run as a client and to use an external time server. But xntpd can also run as a server at the same time. This approach makes it very easy to coordinate the time on all of your machines. If you are running several machines at home, one of them should act as a server for the others. There is no reason for each of the machines to individually access a time server. In fact, it's an inefficient use of resources and it increases network traffic.

I run several NT boxes on my subnet. I installed on those machines and they now synchronize with the FreeBSD box. In this solution, the gateway machine talks to the external time servers and my local subnet coordinates their time with the gateway.

I admit to not having tried the server side of xntpd, so please treat the following with a grain of salt. I haven't tested them but I have faith in what appears below. If you have problems, please contact me and I'll help as I can.

I have designated the computer which connects directly to my ISP as my local time server. xntpd has been installed on that machine as described in the previous sections. This machine operates as a client with respect to the time server at my ISP. But it runs as a server for the other machines on my network. The other machines operate xntpd as a client and use that machine as their time server. The /etc/ntp.conf file on the client machines refers to my local time server, not my ISP. This distinction is important.

The Server

For the server, set it up as described in the previous sections but use the following /etc/xtp.conf file instead:

	server		truechimer.waikato.ac.nz
	driftfile	/etc/ntp.drift
	broadcast	192.168.0.255
  

The main difference is the addition of the broadcast command. In my case, I've used the broadcast address for 192.168.0.0 Class C network. You should pick the one appropriate to your subnet.

recommends the use of a broadcast address such as the above. However, the man pages specifies that "The Numbers Czar has assigned the address 224.0.1.1 to NTP; this is presently the only number that should be used". But my best guess is to go with the configuration provided above, modified for your local subnet.

The Client

For the server, set it up as described in the previous sections but use the following /etc/xtp.conf file instead:

	server		your.local.time.server
	driftfile	/etc/ntp.drift
  

Provide the IP address or the hostname of the time server you configured in the previous section.

Where to find a timeserver

I use my ISP as a time server. You might want to ask your ISP if they provide such a service. If they do, use them. If they don't, try the one of the following resources. It's also been pointed out to me that it may pay to use more than one timer server.

Good stuff and some sound guidelines.

�

Copies of the software you might want. Lots of links to other information.

�

A good resource.

- Dan

Return to Issue #2