NTP users are strongly urged to take immediate action to ensure that their NTP daemon is not susceptible to use in a reflected denial-of-service (DRDoS) attack. Please see the NTP Security Notice
for vulnerability and mitigation details, and the Network Time Foundation Blog
for more information. (January 2014) See StartingNTP4Dev for discussion of this topic.
7.1. Starting NTP 4
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
7.1.2. Avoid DNS Delays
22.214.171.124. Use IP Addresses or
If you choose to start
before starting the nameserver, you will have to either use IP numbers in your
file or provide an alternate way to convert hostnames into IPs (perhaps using
126.96.36.199. 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
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
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.
7.1.3. Wait Before Starting Time-sensitive Services
If you have services (like some database servers) that require that the time is never "stepped" backwards, run:
as late as possible in the boot sequence, before starting these time-sensitive services.
Also note that should you have to restart
, you should not use the
option as that may cause the time to be stepped backwards.
7.1.4. Configuration file tips
iburst for Faster Sync
in the appropriate
lines in your
file for faster sync (i.e. ~8-15 seconds instead of ~5-10 minutes)
188.8.131.52. Avoid Using Burst
Note that using
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
cannot be used with refclocks, only upstream time servers
184.108.40.206. Increase Number of Time Servers for Time-sensitive Systems
220.127.116.11.1. 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
will sync to. Of course,
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 (see http://lists.ntp.org/pipermail/questions/2003-September/000737.html
To increase your ability to detect and eliminate falsetickers (especially during startup), you should use the following configuration command in your
tos minclock 4 minsane 4
Note that the values you specify here for
should be at least four, and at least two less than the total number of servers you have defined in your
18.104.22.168.2. Number of Time Servers Specified in
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
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
, 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.
22.214.171.124. 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
, making use of
for each, etc.... If you list six servers by IP address, make use of
, 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
, which reduces the number of reply packets that
waits for. This is likely to greatly reduce your clock accuracy on startup (because
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
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
won't be able to recover, with the program finally deciding to give up and commit suicide.
Those caveats aside, the option is
, and is used like this:
tos maxdist 16
tos maxdist 16
by itself with just four servers specified by IP address in
, 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
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.
- 08 Feb 2005