See ConfiguringNTPDev for discussion of this topic.

Configuring NTP

Simple Client Configuration

The example ntp.conf files below are different between 4.2.6 and earlier vs. 4.2.7 and later, because the latter has an improved pool implementation that gives superior results compared to the server directive.

4.2.7 and Later Simple Client Configuration, Visible on the Internet

This is the minimum recommended configuration for an NTP Client running 4.2.7 or later which just needs to synchronize within approximately 100ms.

  
# NTP 4.2.7 or later, visible to the Internet
  restrict default nomodify nopeer notrap noquery
# Don't use nopeer with pool servers
  restrict source nomodify noquery notrap
# if you are using 'multicast ...', nopeer is incompatible
  restrict 224.0.1.1 mask 255.255.255.255 nomodify noquery notrap
# Allow everything from this system (localhost)
  restrict 127.0.0.1
  restrict ::1
# If you want to allow everything from your subnet,
# use your network address and mask below
  restrict 192.168.0.0 mask 255.255.255.0   
  driftfile /var/db/ntp/ntp.drift
  pool 2.pool.ntp.org iburst

4.2.6 and Later Simple Client Configuration, Visible on the Internet

This is the minimum recommended configuration for an NTP Client running 4.2.6 which just needs to synchronize within approximately 100ms.

  
# NTP 4.2.6, visible to the Internet
  restrict default nomodify noquery notrap nopeer
# if you are using 'multicast ...', nopeer is incompatible
  restrict 224.0.0.0 mask 240.0.0.0 nomodify noquery notrap
# Allow everything from this system (localhost)
  restrict 127.0.0.1
  restrict ::1
# If you want to allow everything from your subnet,
# use your network address and mask below
  restrict 192.168.0.0 mask 255.255.255.0   
  driftfile /var/db/ntp/ntp.drift
  server 2.pool.ntp.org iburst
  server 2.pool.ntp.org iburst
  server 2.pool.ntp.org iburst
  server 2.pool.ntp.org iburst

Important Notes

The configurations above use the NTP Pool. Please visit the NTP Pool website for more information. If you are embedding ntpd into a product or OS where the end-user may not even be aware of ntp.conf, please use a pool vendor zone. Note the pool DNS servers automatically select pool servers geographically close to you, so there is generally no reason to use the geographic subzones like 2.eu.pool.ntp.org, and it can actually make things worse if there are not enough pool servers in that zone, as has repeatedly happened with cn.pool.ntp.org. If you are wondering why these examples use only 2.pool.ntp.org and not 0, 1, or 3.pool.ntp.org, it is because 2.pool.ntp.org is the only one enabled for IPv6 as well as IPv4. There are many more IPv6 pool servers per pool client than with IPv4, so you will get better service and conserve the resources of the sometimes overloaded IPv4 pool service. If you have IPv6 access to the internet that is stable, you might want to add -6 before each of the 2.pool.ntp.org references above to avoid IPv4 entirely.

The drift file must in a directory writable by the ntp user, if ntpd is not run as root.

ntpd 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 server or peer lines in ntp.conf we recommend having at least four or five of them, and use iburst for each. See SelectingOffsiteNTPServers for more.

Please do not burst as it will send 6 queries every poll interval rather than one, which is abusive and doesn't help ntpd to sync. burst is only useful when your sources are reachable only intermittently and you are using a very large maxpoll (14 to 17). It was introduced to enable once-every-36-hours dialup telephone synchronization using the modem driver with the NIST or USNO dialup services. It can also be useful if your internet connects and disconnects automatically when there is traffic, and it is expensive to connect so you configure ntpd with a high poll interval. It is abusive to use burst with the always-on internet most of the world is accustomed to today. On the other hand, iburst sends 6 polls in short succession only at startup or after a prolonged failure to communicate with a source, and is not considered abusive.

DHCP Auto-configuration

ISC dhcp 3

ISC's DHCP is able to automatically configure the servers used by ntpd. Here's how to get it working:

1. The dhcp server you are using must be configured to provide the ntp-servers option
2. Configure your dhclient to request ntp-servers (it doesn't by default). To do this add ntp-servers to the default request line in /etc/dhcp3/dhclient.conf
3. 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.
4. Your ntpd must be told to use /etc/ntp.conf.dhcp if it exists. This is usually accomplished in the ntp init script (e.g. /etc/init.d/ntp).

How dynamic IP addresses affect ntpd

When run as a non-root user, which is common on Linux distributions, ntpd does not rescan the network interfaces after it has started. If you are have a dynamic IP (e.g., from DHCP), this means ntpd will no longer be able to communicate with "outside" sources if your IP changes. When run as root, ntpd does rescan network interfaces. Windows ntpd also rescans network interfaces automatically, whether it runs as SYSTEM or another user. If you run ntpd is on a non-Windows OS as a non-root user, you might configure your system to restart ntpd when there's a network change.

Using the Leap Second File

The International Earth Rotation and Reference Systems Service publishes a file which contains a table of past and upcoming leap seconds. This file can be used by ntpd 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 with 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. An exception is if you are sure 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 can be obtained from https://data.iana.org/time-zones/data/leap-seconds.list

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.

NTP Versions before 4.2.6

Pre-4.2.6 versions of ntpd evaluates the leap second file only if the Autokey mechanism is enabled. Autokey also forwards the information from the leap second file to clients which are using Autokey authentication with 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.3676924800

You need to restart ntpd to apply your configuration changes.

NTP over cellular - a brief study

Background

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 from the mobile device power consumption point of view.

Environment

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.

Configuration

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 use minpoll or maxpoll less than 6 with pool servers, querying more often
# than 64 seconds is considered abusive, except for =iburst= which polls 6 times
# 2 seconds apart only when first contacting a server, or after an outage.
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.

Disclaimer

This sample configuration was published in the hope that it could be useful, but without 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.

Set up your own stratum 3 server to receive the keep-alive traffic. For wider usage it's a good idea to setup a pool of your own NTP servers for this purpose. The cellular network causes in any case so much jitter that using higher stratum servers instead of the public NTP pool will do you no good, and will provide unwanted traffic to those servers.

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.

Third-party HOWTOs and guides

• Setting up NTP on Windows - includes pointers to using GPS 18x LVC and the Sure Electronics board on both FreeBSD and Windows - DavidTaylor
• Using NTP on a Raspberry Pi - includes both using a modified kernel for PPS, and a user-mode PPS program.