Intermittent Connectivity with
NTP Time Service

To be a good netizen, only one of your devices should sync with a remote time standard, so the load on both the network and the remote time standard are minimized. This one device should then become your local time standard. All the rest of your devices should sync with it locally, rather than getting their time remotely (and redundantly). In some cases, your main router (probably supplied by the ISP) should sync with a remote time standard (sometimes supplied by the ISP), and all your other devices should sync their time with that router. In other cases, one of your computers should sync with a remote time standard, and all your other devices should sync their time with that computer.

There are a large number of time reference servers available, some from volunteer pools, some from individual volunteer efforts, some from government services, some from vendors, and some from ISPs. They are all the same, and can be exchanged indiscriminately (except if the ISP disallows contact with any but their own time servers). If you have a very old piece of equipment, it may default to a time server that no longer exists. If so, just change its configuration to specify the name of a different time server that does exist. In most cases, time servers can be specified either by name or by raw IP address. Specification by name makes it easy for time servers to do substitution or load sharing. On the other hand specification by raw IP address will work even if DNS is not accessible yet or is not working at all.

Note that the restrict ... lines in ntp.conf apply to all received messages, including responses from upstream time servers that were provoked by our own request messages. An overly restrictive restrict ... line may cause received responses to be discarded, resulting in ntpd never synchronizing with those upstream references.

A tool called SNTP (same protocol, but much simpler behavior) can sometimes be used to set the times of end systems that do not serve as time references for anybody else. Do not use it though for intermediate systems that can serve as time references for other systems. Depending on your system, it is often simpler to just use NTP for everything.

Home Network Security

My experience is NTP does not have any incompatibilities or issues with NAT. I did not need to configure any sort of port forwarding nor bridging in my router to get ntpd to work as desired. All I needed to do was make sure port 123 was open in the IPTables firewall on my computer. Even though the ntpd software itself sees every message as independent with no notion of a connection, most routers associate UDP responses with requests anyway, so as long as ntpd speaks first -which it in fact always does when synchronizing with upstream references- full connectivity with the outside time reference servers is allowed automatically, even at a high security level.

Configuration Recommendations

Much of the lore and defaults for the use and configuration of NTP are relics from the bad old days when the Internet was much slower and unreliable and fragile, and system hardware clocks only provided a rough estimate. The program itself has kept up pretty well, but the documentation and lore have not. The current implementation of ntpd isn't actually nearly as limited as some of the common usage and configuration suggestions make it seem.

In particular the common wisdom for two situations in which ntpd may find itself is wrongheaded:

1. Keeping a system clock highly accurate in the face of intermittent network connectivity
2. Syncing time to upstream servers quickly and reliably

In all cases, it's still necessary to manually set the computer time (and timezone) approximately correctly before doing anything else, as ntpd won't change the clock at all if it's too far off. It may also be necessary to manually reset the computer time approximately correctly if the computer has lain unused for many months and the clock has drifted more than ten minutes. This advice is correct.

Configuration Recommendations for Intermittent Connectivity

The usual recommendation for a system that either has only intermittent network connectivity or sometimes goes to sleep (hibernates) is to restart ntpd whenever network connectivity comes up or the computer wakes up. This way even a poor hardware clock is almost instantly yanked into correctness before it's referenced.

(Another recommentation is to run something like ntpdate at certain times of day, perhaps as a cron job. This may be a reasonable thing to do for end systems which sync locally, but not for your local time reference which syncs remotely. It it good advice only if network connectivity between the subject system and the remote reference is guaranteed to be up at those times.)

But hardware clocks are much better than they used to be, and need only occasional tweaking to be very accurate. And nowadays it works just fine to have that tweaking occur any old time, not necessarily right away as soon as it becomes possible. The original instance of the current ntpd can simply run continuously, without restart/reset, and without any notification of changes to either network connectivity or computer power state. ntpd will continue polling the time servers but will simply notice they're unreachable (because the network is down). When reachability is restored, ntpd will continue as if nothing happened.

Your network must be connected during the few minutes when ntpd is started and makes initial contact with the time server(s). If your network is not connected when ntpd is started, it will discard all the time server(s) and rely solely on the local hardware clock, but with no indication of any possible problem. Use the command ntpq -c lpeers to list the time sources and check remote server(s) have not been discarded.

Configuration Recommendations for Faster Syncing

By default when a server is unreachable ntpd will try again to see if reachability (which includes network connectivity) has been restored only once in more than fifteen minutes. (This is apparently a leftover from the bad old days when the whole Internet was easily overloaded.) To cut that time in half, append maxpoll 9 to the server line(s) in ntp.conf. (This increases load on the server a bit, but not anywhere near as much as the widely suggested burst and iburst parameters.)

By default when a server needs to be reached as quickly as possible, ntpd will initiate an exchange no sooner than about a minute after the last one. (This also is apparently a leftover from the bad old days when the whole Internet was subject to overloading.) To cut that time in half too, append minpoll 5 to the server line(s) in ntp.conf. (This increases load on the server a bit only occasionally rather than all the time, and is not a big concern.)

The usual recommendation for an ntpd that has serious problems syncing with upstream time servers is to append the parameters burst and/or iburst to the server line(s) in ntp.conf. But doing this is overkill and causes a substantial increase in the load on the upstream time servers, and so should be avoided (or at least limited). There are better ways to make time syncing a little faster and a little more reliable, but without placing so much additional load on the network and on the time servers. Add a new line tos maxdist 5 (or tos maxdist 2.5 if you're more conservative) to ntp.conf. The net effect is to accept upstream time servers sooner than after the default four successful exchanges (only two exchanges for tos maxdist 5, and only three exchanges for tos maxdist 2.5). Doing this has become reasonable since the Internet is much more reliable than it was decades ago.

In a very few exceptional cases, resort to some of the usual parameters may still be required. If your system still has a problem syncing its time the first time after network connectivity is restored, add the iburst parameter. If your system still syncs its time too slowly, then add the burst parameter.

Getting Rid of Automatic Restart

To reiterate, it is not really necessary (nor even a good idea:-) to restart the NTP daemon every time the intermittent network connectivity is restored. However this mis-apprehension is so common that your system may automatically restart ntpd, in which case you will need to disable that functionality. Doing so is probably pretty simple ...once you find the right place.

Finding the sleep/wake functions may sometimes be difficult. On my particular Linux system they were scripts in /usr/lib/pm-utils/sleep.d. To disable restarting of ntpd on hibernate/wake, I had to as the superuser:

cd /usr/lib/pm-utils
cp -a sleep.d sleep.d.SAV1ORIG
cd sleep.d
vi 90clock
# comment out the two blocks of lines that check on and stop or start ntpd

(If your hardware clock drifts more than a few tens of seconds in a day, not restarting ntpd will not work. Fix your hardware first; consider replacing or restoring your CMOS battery. Consult your system's documentation, or its website, for specific directions. Be sure to display and write down all the CMOS (BIOS) settings before disturbing the old battery. Sometimes it's possible to retain the old CMOS (BIOS) settings unchanged by powering down the computer but leaving it plugged in; but doing so is not generally recommended because of the increased risk of either shock or damage.)

Debugging

Here are a couple very simple Linux time synchronization debugging tools: To use these, first enter the admin state (i.e. on many systems become the root user).

Then to see the current state, at a command prompt enter something like: ntpq -p. The very first column indicates whether or not synchronization with that time server is established. It will be blank (or perhaps ex or period or dash or hash) if not, and star or plus if so. The poll column is how many seconds between exchange attempts (the number will be a power of two, with the power being minpoll initially and maxpoll when network connectivity has been down for a while). The reach column is a bitmask record -displayed as an octal number- of the last eight exchange attempts, with each 1 bit indicating a successful exchange and each 0 bit indicating no response. It will be 377 when every recent exchange has been successful, and 0 after network connectivity has been down for a while.

To see the history of what your ntpd has done, enter something like grep synchronized /var/log/messages, paying particular attention to the timestamps. There will be some synchronizations to LOCAL (0) (the hardware clock itself, how's that for a loop?-), interspersed among many synchronizations to the time servers you specified.