Network Time Protocol (NTP)

Currently there are two versions of NTP which can be used intermixed: NTP v3 is the latest released version which runs very stable on many operating systems. NTP v4 has some enhancements over v3 and has better support for some operating systems. Additionally, there's also a simplified version of the protocol called SNTP (Simple Network Time Protocol). SNTP uses the same TCP/IP packet structure like NTP but due to the simpler algorithms, it provides only very reduced precision. The NTP package contains a background program (daemon or service) which synchronizes the computer's system time to one or more external reference time sources which can be either other devices on the network, or a radio clock which is connected to the computer.

Additionally, the NTP distribution contains programs which can be used to control or monitor the time synchronization status, and a complete set of documentation in HTML format.

The standard NTP distribution can not be run under Windows 9x/ME because there are some kernel features missing which are required for precision time keeping. For Windows 9x/ME and other platforms which are not supported directly by the NTP package there are some NTP or SNTP programs available on the internet. An overview of available programs can be found on the NTP support home page.

Nowadays many workstations are shipped with a pre-installed NTP client, so Meinberg also offers various plug-and-play NTP time servers called LANTIME NTP time server with different reference clock options, e.g. built-in GPS or DCF77 PZF receivers. The devices also have a network interface and power supply included, are assembled in a standalone case and ready to operate.

Beginning with NTP version 4, the naming conventions were changed to be more straightforward, so now the name of the NTP distribution itself and the names of all the programs included start with ntp (e.g. ntpd, ntpq).

Some Unix-like operating systems use a script to start the NTP daemon at system start-up. Sometimes the script still has a name starting with xntp even though the real name of the daemon started by the script is ntpd. This is the case, for example, for SuSE Linux.

• As client it queries the reference time from one or more servers.
• As server it makes its own time available as reference time for other clients.
• As peer it compares its system time to other peers until all the peers finally agree about the "true" time to synchchronize to.

These features can be used to set up a hierarchical time synchronization structure. The hierarchical levels of the time synchronization structure are called stratum levels. A smaller stratum number means a higher level in the hierarchy structure. On top of the hierarchy there is the daemon which has the most accurate time and therefore the smallest stratum number.

By default, a daemon's stratum level is always one level below the level of its reference time source. The top level daemon often uses a radio clock as reference time source. By default, radio clocks have a stratum number of 0, so a daemon who uses that radio clock as reference time will be a stratum 1 time server, which has the highest priority level in the NTP hierarchy. In large networks it is a good practice to install one ore more stratum 1 time servers which make a reference time available to several server computers in each department. Thus the servers in the departments become stratum 2 time servers which can be used as reference time source for workstations and other network devices of the department.

Unlike in telecom applications where the word stratum is used e.g. to classify oscillators according to their absolute accuracy, the term stratum in the NTP context does not indicate a certain class of accuracy, it's just an indicator of the hierarchy level.

If the time source currently selected as system peer becomes unavailable then a new system peer is determined based on this selection algorithm. The stratum level under which a daemon is visible on the network corresponds to the current system peer's stratum level plus 1.

For details on the selection algorithm see:
http://www.eecis.udel.edu/~mills/ntp/html/prefer.html

For details on the number of time sources to be used see:
http://support.ntp.org/bin/view/Support/SelectingOffsiteNTPServers#Section_5.3.3.

On Windows platforms, if a recent NTP version has been installed using the GUI installer from the Meinberg NTP download page, the ntp.conf file is located in an etc\ directory below the NTP program directory, e.g. in c:\Program Files\NTP\etc.

Earlier versions of NTP for Windows assumed the ntp.conf file to be located in either %systemroot% or %systemroot%\system32\drivers\etc, where %systemroot% corresponds to c:\winnt or c:\windows in standard installations.

In most installations the ntp.conf file contains at least one or more lines starting with the keyword server. Each of those lines specifies one reference time source which can be either another computer on the network, or a radio clock connected to the local computer.

Reference time sources are specified using IP addresses, or host names which can be resolved by a name server. If an IP address represents a real node on the network then the NTP daemon assumes another NTP daemon running on a computer with that address. Additionally, NTP uses some pseudo IP addresses to specifiy special reference time sources.

For example, NTP uses a pseudo IP address 127.127.8.n to access a Meinberg radio clock installed at the local computer. To access its own system clock, also called the local clock, NTP uses the pseudo IP address 127.127.1.0. This IP address must not be mixed up with 127.0.0.1, which is the IP of the localhost, i.e. the computer's loopback interface.

Attention:
Some versions of NTP have problems with DNS name resolution under Windows if support for MD5 authentication has been compiled in. In this case all TCP/IP addresses in the ntp.conf file must be entered in dotted decimal notation (e.g. 172.16.1.1) rather than DNS name like host.domain.com.

Configuration With Meinberg Radio Clock (Unix)

There's also a Linux driver for Meinberg PC plug-in cards available on the Meinberg software download page. Besides ways to configure and monitor the plug-in cards this driver provides a software interface which lets NTP's parse driver read the reference time from a plug-in card rather than via a serial port under Linux. This driver is not required for devices which are directly connected via a serial port.

The configuration steps described below must be done by a user with sufficient rights on the system, e.g. root. The parse driver accesses radio clocks via symbolic links /dev/refclock-n, where n is an index number in the range 0 through 3 since the parse driver can handle up to four reference clocks at the same time.

Each symbolic link must point to a physical device which represents an existing radio clock. In most cases the physical device is a serial port at which a radio clock has been connected externally. However, under Linux this link can also point to a device node which represents a plugin card.

Each of the reference clocks must also be specified in the ntp.conf file using a server line with the pseudo IP address 127.127.8.n, where n must correspond to the index numbers used with the symbolic device names /dev/refclock-n mentioned above.

The pseudo IP address must be followed by a mode m parameter which specifies the type of radio clock represented by the device. The table below lists the mode values which can be used with Meinberg radio clocks:

For example, if a single radio clock is connected to the serial port /dev/ttyS0 then a symbolic link for the clock must be set up using the command

  ln -s /dev/ttyS0 /dev/refclock-0

  ln -s /dev/mbgclock0 /dev/refclock-0

In the next step the file ntp.conf must be edited to configure the NTP daemon and tell it which reference clocks to use. The file should include a server line for the refclock-0 device created above. If the radio clock sends the Meinberg standard time string at 9600 baud and framing 7E2 then, as can be seen from the table above, the mode for refclock-0 must be set to 2. Also, if plug-in card is used under Linux then mode 2 must always be used:

  server 127.127.8.0 mode 2     # standard time string with 9600, 7E2

  server 127.127.1.0            # local clock
  fudge 127.127.1.0 stratum 12

Now the NTP daemon must be started (or restarted) to let the changes take effect. If the daemon has been shipped with the operating system then it may have support for Meinberg clocks compiled in, or not.

If the output of the command ntpq -p lists a clock labeled generic then everything is fine and the NTP daemon supports the reference clock.

If the generic clock it not listed in the ntpq output then the NTP package may have been compiled without support for the parse clocks, or the NTP daemon may not have permission to access the device. The syslog messages from the NTP daemon after startup should indicate the real reason for the problem.

The permission denied problem can occur with plug-in cards under recent Linux distributions which come with AppArmor or SELinux security tools enabled. See the README file from the Linux driver package for details and how to fix this problem.

If the existing NTP daemon has been built without support for the parse clocks then the NTP package must be reconfigured and recompliled on the target platform. This requires a compiler package installed on the target platform, and the source code of the NTP distribution.

In the example below name is the base name of the NTP source package which is normally distributed as a file name.tar.gz which must be uncompressed on the target computer:

  tar xvzf name.tar.gz

  cd name
  ./configure --enable-MEINBERG
  make

  ntpd/ntpd

  xntpd/xntpd

The command ntpq -p can be used to verify that the new daemon works correctly. Finally the newly compiled programs should be copied to the destination directories. The standard procedure to do that is by simply running the command

  make install

Care must be taken especially if the NTP version changes between v3.x and v4.x because the naming conventions have changed between those version (e.g xntpd/ntpd).

Configuration With Meinberg Radio Clock (Windows)

If NTP is installed using the GUI installer from the Meinberg NTP download page and the setup program detects the Meinberg driver package which has already been installed before then the NTP installer suggests to create an appropriate NTP configuration labelled "Follow Meinberg Time Service".

This configuration should include the following lines:

  server 127.127.1.0            # local clock
  fudge 127.127.1.0 stratum 0   # disciplined by radio clock

Unlike stated before on this page, the config file should not contain the line disable ntp since this may be the reason that the time server is not accepted by its clients.

Also, there should be no driftfile specified, and if a file ntp.drift already exists on the machine, it should be deleted. Otherwise the NTP service might try to correct the system clock drift, thus working against the radio clock driver, resulting in a poor quality of time synchronization.

Configuration Without Radio Clock

  server 127.127.1.0            # local clock
  fudge 127.127.1.0 stratum 12  # not disciplined

  server ntp_server_1
  server ntp_server_2
  server ...

where ntp_server_1, ntp_server_2, etc. must be the real host names or IP addresses of existing NTP servers.

Additional Configuration Options

  driftfile /etc/ntp.drift

Attention: If the NTP service under windows works together with the Meinberg driver package then a driftfile should not be configured. See also: Configuration With Meinberg Radio Clock (Windows).

There are many more options which can be set up using the configuration file. Please refer to the NTP documentation for details.

ntpq can be run in an interactive mode or in batch mode. In batch mode, ntpq executes a command and returns to the command prompt. The parameter -p ('peers') lets ntpq print the status of a NTP daemon. Enter

  ntpq -p

  ntpq -p ntp_server

     remote      refid      st t when poll reach   delay   offset  jitter
  =======================================================================
   LOCAL(0)      LOCAL(0)   12 l   30   64  377    0.000    0.000   0.000
  *GENERIC(0)    .DCFa.      0 -   24   64  377    0.000    0.050   0.003
  +172.16.3.103  .PPS.       1 u   36   64  377    1.306   -0.019   0.043

If the first character of a line is not blank then it contains a qualifier for the corresponding reference time source. Immediately after the daemon has been started all qualifiers are blank. The NTP daemon needs several polling cycles to check the available time sources and declare one of them as the reference it synchronizes to.

An asterisk * in the first column marks the reference time source which is currently preferred by the NTP daemon, the + character marks high quality candidates for the reference time which could be used if the currently selected reference time source should become unavailable.

The column remote displays the IP address or the host name of the reference time source, where LOCAL refers to the local clock. The refid shows the type of the reference clock, where e.g. LOCAL or LCL refers to the local clockagain, .DCFa. refers to a standard DCF77 time source, and .PPS. indicates that the reference clock is disciplined by a hardware pulse-per-second signal. Other identifiers are possible, depending on the type of the reference clock.

The column st reflects the stratum number of the reference time source. In the example above, the local clock has stratum 12, the remote time server at 172.16.3.103 has stratum 1 which is the best you can see across the network, and the local radio clock has stratum 0, so the radio clock is currently being preferred.

Every time a when count reaches the poll number in the same line, the NTP daemon queries the time from the corresponding time source and resets the when count to 0. The query results of each polling cycle are filtered and used as a measure for the clock's quality and reachability.

The column reach shows if a reference time source could be reached at the last polling intervals, i.e. data could be read from the reference time source, and the reference time source was synchronized. The value must be interpreted as an 8 bit shift register whose contents is for historical reasons displayed as octal values. If the NTP daemon has just been started, the value is 0. Each time a query was successful a '1' is shifted in from the right, so after the daemon has been started the sequence of reach numbers is 0, 1, 3, 7, 17, 37, 77, 177, 377. The maximum value 377 means that the eight last queries were completed successfully.

Queries are considered successful if data can be received from the time source, and the time source in turn claims to be synchronized to some other timesource. In case of a hardware reference clock this means the query considered unsuccessful if the hardware reference clock is not synchronized to its incoming time signal, e.g. because the clock's antenna has been disconnected, or if no data can be received e.g. because the serial cable to an external device has been disconnected.

The NTP daemon must have reached a reference time source several times (reach not 0) before it selects a preferred time source and puts an asterisk in the first column.

The columns delay, offset and jitter show some timing values which are derived from the query results. In some versions of ntpq the last column is labeled disp (for dispersion) instead of jitter. All values are in in milliseconds. The delay value is derived from the roundtrip time of the queries. The offset value shows the difference between the reference time and the system clock. The jitter value indicates the magnitude of jitter between several time queries.

NTP Homepage

Meinberg NTP Download Page

NTP Online Documentation

The latest documents can also be viewed online at the NTP home page http://www.ntp.org.

User contributed documentation, a bug reporting system, mailing lists etc. can be found at the NTP Public Services Project page at http://support.ntp.org.

NTP Usenet Discussions

There is also an internet news group comp.protocols.time.ntp where users from all over the world discuss NTP or ask questions about special configurations.

Older articles on NTP can be retrieved by keyword search from Google http://groups.google.com/advanced_group_search.

Here are some example searches on Google for NTP and ...

• AIX | AIX problem | AIX ulimit problem
• VMS | VMS problem
• Sun | Sun Patches | Solaris "kvm_open" Error
• AS/400
• QNX

To refine the search click on the the link Advanced Group Search at the top of the Google result page.

RFCs related to NTP and Network Time Synchronization