r45 - 2014-12-14 - 07:22:32 - JanCeuleersYou are here: NTP >  Support Web > ConfiguringNTP
NTF needs your help to qualify to participate in the Combined Federal Campaign so we can continue our mission to improve Network Time. We only need a few thousand dollars more by December 31st - any sized donation helps! Please join an NTF Consortium or make a donation to NTF now! THANKS!
REFACTOR See ConfiguringNTPDev for discussion of this topic.

6. Configuring NTP

6.10. Simple Client Configuration

6.10.1. 4.2.7 and Later Simple Client Configuration, Visible on the Internet

This is the minimum configuration for an NTP Client running 4.2.7 or later which just needs "good enough" time.

  # NTP 4.2.7 or later, visible to the Internet
  restrict default -4 nomodify nopeer noquery notrap
  restrict default -6 nomodify nopeer noquery notrap   # if your machine has IPv6 connectivity
  restrict source nomodify noquery notrap              # Don't use nopeer with pool servers
  restrict 224.0.1.1 mask 255.255.255.255 nomodify     # if you are using multicast (most folks are not)
  restrict 127.0.0.1
  restrict ::1
  restrict 192.168.0.0 mask 255.255.255.0   # Use your network address and mask
  driftfile /var/db/ntp/ntp.drift
  pool 0.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 writable by the ntp user

6.10.2. 4.2.6 and Later Simple Client Configuration, Visible on the Internet

This is the minimum configuration for an NTP Client running 4.2.6 which just needs "good enough" time.

  # NTP 4.2.6, visible to the Internet
  restrict default -4 nomodify nopeer noquery notrap
  restrict default -6 nomodify nopeer noquery notrap   # if your machine has IPv6 connectivity
  restrict 224.0.1.1 mask 255.255.255.255 nomodify     # if you are using multicast (most folks are not)
  restrict 127.0.0.1
  restrict ::1
  restrict 192.168.0.0 mask 255.255.255.0   # Use your network address and mask
  driftfile /var/db/ntp/ntp.drift
  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 writable by the ntp user

6.11. Important Notes

First, 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 I recommend having at least four or five of them, and use iburst for each. See SelectingOffsiteNTPServers for more.

Be very careful with burst as it is only rarely needed and will significantly increase the traffic. Do not use burst 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 burst is appropriate.)

6.12. DHCP Auto-configuration

6.12.1. 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).

6.13. How dynamic IP addresses affect ntpd

Currently, ntpd does not rescan the network interfaces after it has started. If you are have a dynamic IP (use DHCP), this means ntpd will no longer be able to communicate with "outside" sources after your IP changes.

The script in bug_small.png 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 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 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 where 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.

The file can also be obtained from http://www.ietf.org/timezones/data/leap-seconds.list

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 ntpd evaluates the leap second file only if the autokey feature has been enabled. The autokey 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

6.15.1. 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 e.g. in http://www.pasieronen.com/publications/haverinen_siren_eronen_vtc2007.pdf , from the mobile device power consumption point of view.

6.15.2. 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.

6.15.3. 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 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.

6.15.4. Disclaimer

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

Topic attachments
I Attachment Action Size Date Who Comment
pngpng timesync18_20052013.png manage 23.7 K 2013-05-28 - 07:54 MarkkuVimpari A sample time sync results over 3G.
Edit | WYSIWYG | Attach | Printable | Raw View | Backlinks: Web, All Webs | History: r45 < r44 < r43 < r42 < r41 | More topic actions
 
SSL security by CAcert
Get the CAcert Root Certificate
This site is powered by the TWiki collaboration platform
IPv6 Ready
Copyright & 1999-2014 by the contributing authors. All material on this collaboration platform is the property of the contributing authors. Ideas, requests, problems regarding the site? Send feedback