See ConfiguringNTPDev for discussion of this topic.
6. Configuring NTP
6.10. Simple Client Configuration
This is the minimum configuration for an NTP Client
which just needs "good enough" time.
server 0.pool.ntp.org iburst
server 1.pool.ntp.org iburst
server 2.pool.ntp.org iburst
server 3.pool.ntp.org iburst
- This configuration uses the Global NTP Pool. Please visit the NTP Pool web-site to learn about the Pool Zones which may be used to choose servers in your geographical area
- The drift file must in a directory writeable by the ntp user
6.11. Important Notes
needs a majority of servers to agree on the time before it can sync. If you only have one server, that server WILL be believed. If you have two or three servers and they disagree, no majority will be found.
If you are going to have
I recommend having at least four or five of them, and use
for each. See SelectingOffsiteNTPServers
as it is only rarely needed and will significantly increase the traffic. Do not use
unless you have a very good reason for doing so. (I'd like to have a URL to the pages that describe the rare cases where
6.12. DHCP Auto-configuration
6.12.1. ISC dhcp 3
is able to automatically configure the servers used by
. Here's how to get it working:
- The dhcp server you are using must be configured to provide the
- Configure your
dhclient to request
ntp-servers (it doesn't by default). To do this add
ntp-servers to the default
request line in
- Create an
/etc/ntp.conf with all of the other settings that you wish to use. This file will be used to create
/etc/ntp.conf.dhcp, it won't be over written.
ntpd must be told to use
/etc/ntp.conf.dhcp if it exists. This is usually accomplished in the ntp init script (e.g.
6.13. How dynamic IP addresses affect ntpd
does not rescan the network interfaces after it has started. If you are have a dynamic IP (use DHCP), this means
will no longer be able to communicate with "outside" sources after your IP changes.
The script in Bug #51
will not help you unless it's the remote site's IP address that has changed.
6.14. Using the NIST Leap Second File
The U.S. National Institute of Standards and Technology (NIST)
is publishing a file which contains a table of past and upcoming leap seconds. This file can be used by
to become aware of leap second announcements and thus be able to handle leap seconds gracefully.
Graceful handling of leap seconds implies applying the leap second locally at the appropriate time, rather than having the clock off by one second until the discrepancy witih sources is noticed and corrected at a later time. ntpd will gracefully handle leap seconds which it knows about in advance, via one of two means. If a leap second file is configured in ntp.conf or acquired via autokey, ntpd will inform clients of the pending leap for one day in advance via the leap field of the NTP packet, and it will be applied locally. Lacking a leapfile, ntpd is at the mercy of its sources to inform it of the pending leap second.
In the case of network sources, this means ntpd is at the mercy of the Stratum 1 sources at the top of its synchronization chain either having a current leapfile installed, or using a reference clock driver which provides advance notice of pending leap seconds. While some reference clocks do provide this information, many do not. For example, GPS provides notification to receivers of pending leap second insertions. That does not imply all stratum 1 servers using GPS will receive that notification. The popular NMEA reference clock driver does not, as the NMEA sentences its decodes do not carry advance notification of leap seconds.
Past experience has shown many stratum 1 servers do not advertise pending leap seconds during the day prior to the event. Installing a leapfile on your NTP server ensures it will notify its clients of the pending leap as well as handle the event gracefully. If you operate a stratum 1 server, your downstream clients are depending on your server to notify them, so it is best practice to download and configure the leapfile at least one day in advance of the scheduled insertion or deletion. The only exception is if you know all your reference clocks and their ntpd drivers will provide notification at least one day in advance.
The way to configure ntpd to use this file has changed with version 4.2.6 of ntpd.
The file is available available at ftp://time.nist.gov/pub/
as well as ftp://tycho.usno.navy.mil/pub/ntp/
The file name is: leap-seconds.nnnnnnnnnn
is a time the file was updated expressed as an NTP timestamp rounded to whole seconds, that is, the number of seconds since the start of the year 1900 (ignoring leap seconds).
As of this writing the name of the current NIST leap seconds file is leap-seconds.3535142400
As of early 2012, the USNO tycho FTP server is accessible to some clients which cannot access the NIST time FTP server, possibly related to an inferior NAT ALG for FTP and/or the server load balancer involved.
6.14.1. NTP Versions 4.2.6 and newer
Copy the leap seconds file onto your system running ntpd and add a line to your ntp.conf:
leapfile "/path/to your/leap-file"
You need to restart ntpd to apply your configuration changes.
6.14.2. NTP Versions before 4.2.6
Pre-4.2.6 versions of
evaluates the leap second file only if the
feature has been enabled. The
feature also provides a mechanism to forward the information from the leap second file to clients which are using autokey authentication of the server, that is, clients which have the autokey keyword on the server directive in ntp.conf.
The leap second file must be copied to the crypto directory
configured for ntpd, and inside that directory a link
must be created which points to that file. The standard name for the link is ntpkey_leap
. However, this can be overridden by a configuration parameter.
So assuming the name of the leap second file as mentioned above, the standard link to the leap second file inside the NTP crypto directory should look like this:
ntpkey_leap -> leap-seconds.3535142400
You need to restart ntpd to apply your configuration changes.
6.15. NTP over cellular - a brief study
A customer asked to study how good relative time sync can be achieved, when the connection is over cellular packet networks, which are characterised by long, variable, asymmetric delays. The delays are due to the state transitions between the cell states in 3G networks. They are discussed e.g. in http://www.pasieronen.com/publications/haverinen_siren_eronen_vtc2007.pdf
, from the mobile device power consumption point of view.
The units used for this test were Raspberry Pi (RPi). NTP package were from the Raspbian repository and version 1:4.2.6.p5+dfsg-2. Various USB 3G modems directly connected to the RPi were tested and they behaved in the same way - excluding longer term stability.
In other HW platforms the HW clock is likely more stable and does not drift as extensively as RPi does and thus, likely tolerates lower frequency NTP polling.
However, the optimal keep-alive period is depending on the cellular network and targeted accuracy. Here the target relative time sync accuracy was 10ms and it seems to be achievable most of the time.
To achieve reasonable timing performance over 3G cellular network, there has to be enough traffic to keep the cellular radio on CELL_FACH as much as possible, but preferably avoiding unnecessarily transitions to CELL_DCH.
Generating periodic ping packets parallel to a traditional NTP daemon configuration was also tested, but it didn't provide any measurable benefit; NTP packets are small enough.
Since even with the ignored (noselect) keep alive packets there is quite a lot of jitter in the packet delays, the number of the servers, which the NTP daemon can utilise, has to be higher than in normal (from the NTP point of view much better) access networks.
# Keep the cellular modem on CELL_FACH with this, do NOT poll pool server with this frequency.
server server1.mydomain.com iburst minpoll 3 maxpoll 3 noselect
# obtain the time
server 0.xxx.pool.ntp.org iburst maxpoll 9
server 1.xxx.pool.ntp.org iburst maxpoll 9
server server2.mydomain.com iburst maxpoll 9 prefer
server 2.xxx.pool.ntp.org iburst maxpoll 9
server 3.xxx.pool.ntp.org iburst maxpoll 9
Replace xxx with a suitable pool.
This sample configuration was published in the hope that it could be useful, butwithout any warranty of any kind.
The configuration has been tested just in one network (Sonera Finland) and only in one physical location. Other networks may behave in different way.
Setup own stratum 3 server to receive the keep-alive traffic. For wider usage it's a good idea to setup a pool of own NTP servers for this purpose. The cellular network causes
in any case much more jitter than using dedicated higher stratum servers instead of the public NTP pool.
The keep-alive generates quite a lot of traffic (several MBs weekly), so the cellular subscription fee should be flat rate i.e. paid for the speed, not for the data.
6.16. Third-party HOWTOs and guides