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.

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:
Current versions of NTP under Windows NT have problems with DNS name resolution if support for MD5 authentication has been compiled in. In this case, all TCP/IP addresses in the file ntp.conf 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 which can be installed in order to make Meinberg plug-in cards available as reference time sources under Linux. The driver is available at the Meinberg software download page. Note: That driver is only required for plug-in radio clocks. Radio clocks which are connected via a serial interface are directly supported by NTP.

The actions 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 device names /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 device name must point to a physical device which represents an existing radio clock. In most cases the physical device is a serial port which has a radio clock connected to.

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/mbgntp /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:

        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 ot 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 NTP must be configured and compliled 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)

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

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
          

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

Checking the NTP Status

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 displayed as octal values. If the NTP daemon has just 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 0, 1, 3, 7, 17, 37, 77, 177, 377. The maximum value 377 means that the eight last queries were completed successfully. 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.

Meinberg NTP Download Page

The NTP Homepage (http://www.ntp.org) provides links to, and descriptions of, "The NTP Project" and "The NTP Public Services Project".

NTP Online Documentation

Answers to Frequently Asked Questions regarding NTP can be found in the NTP FAQ at http://www.ntp.org/ntpfaq/NTP-a-faq.htm A wealth of other community supported docs are accessible on the NTP Community Supported Documentation Page.

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