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

Ahh ... The Toils of Time

From cly on Mon, 11 Jan 1999

Hi! My problem is, that the system clock runs too fast, about 4 mins/3 days.

That's a pretty bad clock. However, there are ways to cope with it.

It's a big problem, because this server is time server for some workstations.

Are you using timed, xntpd or some other time synchronization server/protocol?

If you have a dedicated connection to the Internet, I'd recommend using xntpd --- and thus using the NTP protocol.

This is a complex protocol with largely inaccessible documentation. So far as the average sysadmin is concerned it should simply be a matter of installing xntpd on one or more Internet accessible (bastion) hosts --- such as your nameserver and external mail relay, and providing it with a suitable configuration file.

Mine looks like:


#/etc/ntp.conf
server nebu1-atm.ucsd.edu ## (132.239.254.49)
server ns.scruz.net ## (165.227.1.1)
server 127.127.1.0 # local clock (LCL)
fudge 127.127.1.0 stratum 10 # LCL is unsynchronized
driftfile /etc/ntp.drift

... note that the servers I've chosen are listed among the Stratum-2 (secondary) public time servers at the NTP web pages:

http://www.eecis.udel.edu/~ntp

... also note that you should ping and run ntpdate against any of these before you try to use them as one of your xntpd time source servers. (This list is sadly out of date --- and includes hosts which haven't responded to my pings and time requests in a couple of years --- and that's just from a sampling of the ones in California!).

But I'm getting ahead of myself. First you need to ensure that your clock is even close (within 1000 seconds) of the correct time before you load the xntpd daemon. So, during startup you should run the 'ntpdate' command to set your system time. (I also run the /sbin/clock -w command to write the system time to the CMOS hardware clock --- and have a cron job to repeat that command once a day).

Using this technique during startup you have your system time in the right ballpark. (The cron job also limits how far off your CMOS/hardware clock can drift).

Then you have your startup scripts load the NTP daemon after your networking interfaces and routes have been established. Then this daemon will periodically poll its time servers, measuring the networking delays and arriving at a precise approximation of the UTC time. I gather that the default is every 17 minutes. You'll see UDP traffic between port 123 on the clients and servers.

I recommend that you configure at least one exposed (bastion) server with xntpd and another one or two internal hosts which access the externally visible one. Then all of your internal systems can access the internal (stratum-4) time servers. If you have less than a hundred systems your external systems should probably refer to stratum-2 servers (to limit the load on the primary (stratum-1) servers).

You can also buy hardware clocks which xntpd can use to set the time. Some of them are radio clocks, other monitor GPS (global positioning system) or Loran signals (which would also be considered "radio" clocks I guess) and others are high precision clocks embedded on PC or other interfaces.

Thus, if you connect a GPS or Loran based high precision clock to one of your servers you can be your own stratum-1 time source. (If you go to the expense of buying one of these --- and they can cost over $1000 US --- I highly recommend that you make that server publicly available as a primary NTP server).

I gather that there are also modem based time services that are supported by the NTP package. I have yet to see any configuration examples for using these.

Note:

It has sometimes been the experience that the local clock oscillator frequency error is too large for the NTP discipline algorithm, which can correct frequency errors as large as 30 seconds per day. There are two possibilities that may result in this problem. First, the hardware time- of-year clock chip must be disabled when using NTP, since this can destabilize the discipline process. This is usually done using the tickadj program and the -s command line argument, but other means may be necessary. For instance, in the Sun Solaris kernel, this must be done using a command in the system startup file.

... in your case your system may require a bit of extra work to get xntpd working reliably. You're experiencing over a minute per day in slew --- so you'll almost certainly need read these details from the NTP home page.

As I've said --- the biggest failing in the xntpd package is that the documentation is written like a doctoral thesis. It add incredible complexity to a process that should be very simple to the "user" (the typical sysadmin, in this case).

Another problem with the whole system (protocol, utilities etc) is that it's designed for systems with dedicated Internet connections. No provisions or suggestions are made for those of us with dial-up (dial on demand) connection over modems, ISDN lines, etc.

My solution was to create a cron job that kill the xntpd on my internal time server once every day --- fired up my link to the 'net, ran 'ntpdate' against three different servers and then restarted the daemon.

This is specifically NOT recommended in the NTP documentation. They are concerned that the sudden change in time might confuse some daemons and processes. However, it seems to be the only choice for those of us that want to maintain reasonable time synchronization but don't have the money to spend on dedicated internet connections and/or hardware clocks.

You can find a list of those high precision time clocks at the NTP web pages. I'm must sorry that you'll have to muddle through all that erudite prose to get at the information you want.

(Meanwhile I have changed my network and I do have a dedicated connection (DSL) now. So if anyone wants to send me a good GPS PC/clock I'll be happy to set up an ntp.starshine.org public time server ).

My config:

Slackware 3.5 with 2.0.36 kernel on iP200MMX
What to do?
Cly

I hope that helps. I don't know if xntpd is included with Slackware --- but you can certainly find and build the source package from any good Linux archive site or from the NTP home pages that I've listed above.

Copyright © 1999, James T. Dennis
Published in The Linux Gazette Issue 37 February 1999

				1	2	3	4	5	6	7	8	9	10
				11	12	14	15	16	17	18	19	21	22
				23	28	29	30	31	32	33	34	37	38
39	41	42	43	44	45	46	47	48	49