REFACTOR See StartingNTP4Dev for discussion of this topic.

Starting NTP 4

Start ntpd as Early as Possible

As early as possible in the boot sequence, run:

   ntpd -g -N

(note that in versions 4.0 thru 4.1.2, you must specify -N high)

Avoid DNS Delays

Use IP Addresses or /etc/hosts Entries

If you choose to start ntpd before starting the nameserver, you will have to either use IP numbers in your ntp.conf file or provide an alternate way to convert hostnames into IPs (perhaps using /etc/hosts).

Use Good Local Resolvers

If you do specify the servers by name instead of by IP address, make sure that you have good local nameservers listed first in your resolver (on *nix type systems, that will be in /etc/resolv.conf).

By "local", we mean on your same LAN, perhaps even on the same machine. Using the nameservers from your ISP or otherwise across the WAN may not work well, and may cause significant additional delays. Make sure that these nameservers are not overloaded.

A single "dead" or overloaded nameserver listed first in your resolver can take your startup time from a normal eleven seconds and turn it into a very abnormal forty-five seconds.

Wait Before Starting Time-sensitive Services

If you have services (like some database servers) that require that the time is never "stepped" backwards, run:

   ntp-wait -v

as late as possible in the boot sequence, before starting these time-sensitive services.

Also note that should you have to restart ntpd, you should not use the -g option as that may cause the time to be stepped backwards.

Configuration file tips

Use iburst for Faster Sync

Use iburst in the appropriate peer or server lines in your /etc/ntp.conf file for faster sync (i.e. ~8-15 seconds instead of ~5-10 minutes)

Avoid Using Burst

Note that using burst on public servers is considered unfriendly. Do not use this option unless you own the servers in question, or you have been given explicit permission to do so by their owner. Also note that iburst and burst cannot be used with refclocks, only upstream time servers

Increase Number of Time Servers for Time-sensitive Systems

Number of Time Server "Candidates" and "Sane"

The NTP algorithms for selecting good timeservers (truechimers) and separating them from bad ones (falsetickers) are complex, but what it amounts to is the system going through and systematically looking at all the currently remaining servers and seeing if one of them is statistically an outlier, and therefore "insane". The "insane" server is eliminated, and the cycle repeats. Once you've eliminated all the "insane" servers, the remaining "sane" servers are culled through a similar process.

Once you've gotten down to the minimum number of "sane" servers, the system considers the rest to be the "candidates" for selection as the One True Clock (a.k.a., "syspeer"). This is the clock that ntpd will sync to. Of course, ntpd will periodically re-calculate the set of "sane" servers, the "candidates", and the "syspeer". See section 8.4 of TroubleshootingNTP for information on the "tally" character that shows you which server is considered to be a candidate, insane, etc....

By default, the minimum required number of sane servers is three (3), and the minimum required number of candidates is one (1). However, this can have some very undesirable consequences.

To increase your ability to detect and eliminate falsetickers (especially during startup), you should use the following configuration command in your /etc/ntp.conf file:

   tos minclock 4 minsane 4

Note that the values you specify here for minclock and minsane should be at least four, and at least two less than the total number of servers you have defined in your /etc/ntp.conf file.

Number of Time Servers Specified in /etc/ntp.conf

If you follow the logic in section 4.3.3 of SelectingOffsiteNTPServers, you will know that you need at least four upstream time servers defined in your /etc/ntp.conf in order to be able to detect and eliminate one single "falseticker".

For systems that are very sensitive to issues regarding accurate time-stamps, you should have at least six or seven servers listed in your /etc/ntp.conf, and perhaps as many as nine. It will take your system a little longer to settle down to good time sync on boot, but the additional robustness, and accuracy will be worth it.

Sensitivity to Boot-time Delays

With the above recommendations, you can get boot-time delays down to about seven seconds, with four good (and reasonably close) servers listed by IP address in the /etc/ntp.conf, making use of iburst for each, etc.... If you list six servers by IP address, make use of iburst, and also make use of the tos minclock 4 minsane 4 option recommended above, our tests have shown that you should be able to see startup times around eleven seconds. Adding a few more servers should not significantly impact this startup time.

If this still isn't fast enough, you can make use of a different option to tos, which reduces the number of reply packets that ntpd waits for. This is likely to greatly reduce your clock accuracy on startup (because ntpd will have much less statistical information to work with before it tries to make its decision with regards to the initial stepping or slewing of the clock), and may make ntpd work much harder than it needs to in order to correct the poor initial startup values.

Indeed, there is a good chance that using this option may create a situation bad enough that ntpd won't be able to recover, with the program finally deciding to give up and commit suicide.

Those caveats aside, the option is maxdist, and is used like this:

   tos maxdist 16

Using tos maxdist 16 by itself with just four servers specified by IP address in /etc/ntp.conf and using iburst, you should be able to get startup times as low as three seconds, pretty consistently. But you're not going to get any better than that. Not even if you specify just one server in the /etc/ntp.conf file -- we've tested it.

Don't bother trying to combine tos minclock 4 minsane 4 with this option. Doing this would be like putting a stick of dynamite in a Yugo, and then gluing on foam rubber onto the thing to make it safer -- yes, it will go unbelievably fast, but it may not be particularly reliable or useful after you light the fuse.

-- BradKnowles - 08 Feb 2005
Topic revision: r17 - 04 Oct 2022, TodaysTest
This site is powered by FoswikiCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding Network Time Foundation's NTP Support Wiki? Send feedback