Network Time Protocol (NTP)

Some communications protocols in the IP protocol suite are quite recent, whereas others have a long and rich history that extends back to the start of the Internet. The ARPANET switched over to use the TCP/IP protocol suite in January 1983, and by 1985 NTP was in operation on the network. Indeed it has been asserted that NTP is the longest running, continuously operating, distributed application on the Internet.

The objective of NTP is simple: to allow a client to synchronize its clock with UTC time, and to do so with a high degree of accuracy and a high degree of stability. Within the scope of a WAN, NTP will provide an accuracy of small numbers of milliseconds. As the network scope gets finer, the accuracy of NTP can increase, allowing for sub-millisecond accuracy on LANs and sub-microsecond accuracy when using a precision time source such as a Global Positioning System (GPS) receiver or a cesium oscillator.

Network Time Protocol (NTP) is a TCP/IP protocol used to synchronize computer clocks across data networks. NTP was developed in the 1980s by D.L. Mills at the University of Delaware to achieve highly accurate time synchronization and to sustain the effects of variable latency over packet-switched data networks through a jitter buffer.

NTP enables the synchronization of computer clocks distributed across the network by ensuring accurate local timekeeping with reference to some particular time on the Internet. NTP communicates between clients and servers using the User Datagram Protocol on port No.123. The NTP software package includes a background program known as a daemon or service, which synchronizes the computer’s clock to a particular reference time such as radio clock or a certain device connected to a network.

NTP uses a systematic, hierarchical level of clock sources for its reference. Each level is called a stratum and has a layer number that usually begins with zero. The stratum level serves as an indicator of the distance from the reference clock in order to avoid cyclic dependence in the hierarchy. However, the stratum does not represent the quality or reliability of time.

NTP, Time, and Timekeeping

To consider NTP, it is necessary to consider the topic of timekeeping itself. It is useful to introduce some timekeeping terms at this juncture:

Stability:	How well a clock can maintain a constant frequency
Accuracy:	How well the frequency and absolute value of the clock compares with a standard reference time
Precision:	How well the accuracy of a clock can be maintained within a particular timekeeping system
Offset:	The time difference in the absolute time of two clocks
Skew:	The variation of offset over time (first-order derivative of offset over time)
Drift:	The variation of skew over time (second-order derivative of offset over time)

NTP is designed to allow a computer to be aware of three critical metrics for timekeeping: the offset of the local clock to a selected reference clock, the round-trip delay of the network path between the local computer and the selected reference clock server, and the dispersion of the local clock, which is a measure of the maximum error of the local clock relative to the reference clock. Each of these components is maintained separately in NTP. They provide not only precision measurements of offset and delay, to allow the local clock to be adjusted to synchronize with a reference clock signal, but also definitive maximum error bounds of the synchronization process, so that the user interface can determine not only the time, but the quality of the time as well.

Servers and Clients

NTP uses the concepts of server and client. A server is a source of time information, and a client is a system that is attempting to synchronize its clock to a server.

Servers can be either a primary server or a secondary server. A primary server (sometimes also referred to as a stratum 1 server using terminology borrowed from the time reference architecture of the telephone network) is a server that receives a UTC time signal directly from an authoritative clock source, such as a configured atomic clock or—very commonly these days—a GPS signal source. A secondary server receives its time signal from one or more upstream servers, and distributes its time signal to one of more downstream servers and clients. Secondary servers can be thought of as clock signal repeaters, and their role is to relieve the client query load from the primary servers while still being able to provide their clients with a clock signal of comparable quality to that of the primary servers. The secondary servers need to be arranged in a strict hierarchy in terms of upstream and downstream, and the stratum terminology is often used to assist in this process.

As noted previously, a stratum 1 server receives its time signal from a UTC reference source. A stratum 2 server receives its time signal from a stratum 1 server, a stratum 3 server from stratum 2 servers, and so on. A stratum n server can peer with many stratum n – 1 servers in order to maintain a reference clock signal. This stratum framework is used to avoid synchronization loops within a set of time servers.

Clients peer with servers in order to synchronize their internal clocks to the NTP time signal.

How NTP Protocol works

At its most basic, the NTP protocol is a clock request transaction, where a client requests the current time from a server, passing its own time with the request. The server adds it’s time to the data packet and passes the packet back to the client. When the client receives the packet, the client can derive two essential pieces of information: the reference time at the server and the elapsed time, as measured by the local clock, for a signal to pass from the client to the server and back again. Repeated iterations of this procedure allow the local client to remove the effects of network jitter and thereby gain a stable value for the delay between the local clock and the reference clock standard at the server. This value can then be used to adjust the local clock so that it is synchronized with the server. Further iterations of this protocol exchange can allow the local client to continuously correct the local clock to address local clock skew.

NTP operates over the User Datagram Protocol (UDP). An NTP server listens for client NTP packets on port 123. The NTP server is stateless and responds to each received client NTP packet in a simple transactional manner by adding fields to the received packet and passing the packet back to the original sender, without reference to preceding NTP transactions.

Upon receipt of a client NTP packet, the receiver time-stamps receipt of the packet as soon as possible within the packet assembly logic of the server. The packet is then passed to the NTP server process. This process interchanges the IP Header Address and Port fields in the packet, overwrites numerous fields in the NTP packet with local clock values, time-stamps the egress of the packet, recalculates the checksum, and sends the packet back to the client.

The NTP packets sent by the client to the server and the responses from the server to the client use a common format, as shown in Figure 1.

Figure 1: NTP Message Format

The header fields of the NTP message are as follows:

LI	Leap Indicator (2 bits) This field indicates whether the last minute of the current day is to have a leap second applied. The field values follow: 0: No leap second adjustment 1: Last minute of the day has 61 seconds 2: Last minute of the day has 59 seconds 3: Clock is unsynchronized
VN	NTP Version Number (3 bits) (current version is 4).
Mode	NTP packet mode (3 bits) The values of the Mode field follow: 0: Reserved 1: Symmetric active 2: Symmetric passive 3: Client 4: Server 5: Broadcast 6: NTP control message 7: Reserved for private use
Stratum	Stratum level of the time source (8 bits) The values of the Stratum field follow: 0: Unspecified or invalid 1: Primary server 2–15: Secondary server 16: Unsynchronized 17–255: Reserved
Poll	Poll interval (8-bit signed integer) The log2 value of the maximum interval between successive NTP messages, in seconds.
Precision	Clock precision (8-bit signed integer) The precision of the system clock, in log2 seconds.
Root Delay	The total round-trip delay from the server to the primary reference sourced. The value is a 32-bit signed fixed-point number in units of seconds, with the fraction point between bits 15 and 16. This field is significant only in server messages.
Root Dispersion	The maximum error due to clock frequency tolerance. The value is a 32-bit signed fixed-point number in units of seconds, with the fraction point between bits 15 and 16. This field is significant only in server messages.
Reference Identifier	For stratum 1 servers this value is a four-character ASCII code that describes the external reference source (refer to Figure 2). For secondary servers this value is the 32-bit IPv4 address of the synchronization source, or the first 32 bits of the Message Digest Algorithm 5 (MD5) hash of the IPv6 address of the synchronization source.

When a client is configured with a single server, the client clock is adjusted by a slew operation to bring the offset with the server clock to zero, as long as the server offset value is within an acceptable range.
When a client is configured with numerous servers, the client will use a selection algorithm to select the preferred server to synchronize against from among the candidate servers. Clustering of the time signals is performed to reject outlier servers, and then the algorithm selects the server with the lowest stratum with minimal offset and jitter values. The algorithm used by NTP to perform this operation is Marzullo's Algorithm.
When NTP is configured on a client, it attempts to keep the client clock synchronized against the reference time standard. To do this task NTP conventionally adjusts the local time by small offsets (larger offsets may cause side effects on running applications, as has been found when processing leap seconds). This small adjustment is undertaken by an adjtime() system call, which slews the clock by altering the frequency of the software clock until the time correction is achieved. Slewing the clock is a slow process for large time offsets; a typical slew rate is 0.5 ms per second.

Why is NTP important?

Accurate time across a network is important for many reasons; discrepancies of even fractions of a second can cause problems. For example, distributed procedures depend on coordinated times to ensure proper sequences are followed. Security mechanisms depend on consistent timekeeping across the network. File-system updates carried out by a number of computers also depend on synchronized clock times.

Desirable to keep IP network nodes set to same time

While the nodes on an IP network do not require lock-step frequency synchronization, it is desirable to keep their time of day clocks set to the same time. The benefits are obvious -- comparing log files for troubleshooting or incident investigation requires a common clock; distributed databases, including things like Active Directory, use timestamps as one of the mechanisms to resolve simultaneous changes to the same object.

How do I find my NTP Server?

Windows

To verify the NTP server list:

1. Hold the windows key and press X to bring up the Power User menu.
2. Select Command Prompt
3. In the command prompt window, enter w32tm /query /peers
4. Check that an entry is shown for each of the servers listed above.

To manually configure the list of NTP servers:

1. Hold the windows key and press X to bring up the Power User menu.
2. Select Command Prompt (Admin)
3. Select Yes in the UAC dialog.
4. In the command prompt window, enter w32tm /config /update /manualpeerlist:"NEW-PARSLEY.SRV.CS.CMU.EDU NEW-SAGE.SRV.CS.CMU.EDU NEW-ROSEMARY.SRV.CS.CMU.EDU CORIANDER.SRV.CS.CMU.EDU FENNEL.SRV.CS.CMU.EDU PAPRIKA.SRV.CS.CMU.EDU"
5. Enter w32tm /query /peers
6. Check that an entry is shown for each of the servers listed above.

MacOS X

MacOS X systems currently cannot be configured to obtain NTP server information from DHCP. Systems which are enrolled in the SCS Facilities JSS service receive correct NTP configuration via that service and should not be reconfigured. Other systems must be configured manually. To verify the NTP server list setting:

1. Open System Preferences
2. Click Date & Time
3. Click on the Date & Time tab.
4. Verify that Set Date & Time automatically is checked.
5. In the server name field, enter NEW-PARSLEY.SRV.CS.CMU.EDU NEW-SAGE.SRV.CS.CMU.EDU NEW-ROSEMARY.SRV.CS.CMU.EDU CORIANDER.SRV.CS.CMU.EDU FENNEL.SRV.CS.CMU.EDU PAPRIKA.SRV.CS.CMU.EDU

Debian, Ubuntu

Debian and Debian-derived systems, including Ubuntu, will use NTP servers from DHCP by default when DHCP is used without NetworkManager. If NTP servers from DHCP are being used, they will be listed in the file /var/lib/ntp/ntp.conf.dhcp. If that file does not exist, then NTP servers are not being obtained from DHCP.
Unfortunately, Ubuntu systems use use NetworkManager by default, and there is a bug which prevents NTP configuration from being updated in this case. Systems running the Facilities-supported Dragon Ubuntu 12.04 or 14.04 contain a fix for this problem. On systems which are not Facilities-supported, one of two workarounds is required. Either the list of servers may be configured manually, or a simple script may be installed to enable automatic operation.
To manually configure the list of NTP servers, edit the file /etc/ntp.conf. Remove or comment out any lines beginning with the keywords "server" or "peer", and replace them with the lines shown below. Then run service ntp restart.

  server new-parsley.srv.cs.cmu.edu  iburst

  server new-sage.srv.cs.cmu.edu     iburst

  server new-rosemary.srv.cs.cmu.edu iburst

  server coriander.srv.cs.cmu.edu    iburst

  server fennel.srv.cs.cmu.edu       iburst

  server paprika.srv.cs.cmu.edu      iburst

To enable automatic NTP configuration when using NetworkManager, you can apply a workaround similar to that used on Facilities-supported Ubuntu platforms. This is done by installing a NetworkManager dispatcher script which triggers automatic update of NTP configuration whenever a DHCP lease is obtained. Note this method will not work on older versions of Ubuntu, including Ubuntu 10.04, because they lack the required script to correctly update the NTP server configuration. To apply this workaround, install the following shell script as /etc/NetworkManager/dispatcher.d/05ntp:

#!/bin/sh

if [ "$2" = "up" -a -n "${DHCP4_NTP_SERVERS}" ] ; then

  export reason=BOUND

  export new_ntp_servers="${DHCP4_NTP_SERVERS}"

  sh /etc/dhcp/dhclient-exit-hooks.d/ntp

elif [ "$2" = "dhcp4-change" -a -n "${DHCP4_NTP_SERVERS}" ] ; then

  export reason=RENEW

  export new_ntp_servers="${DHCP4_NTP_SERVERS}"

  sh /etc/dhcp/dhclient-exit-hooks.d/ntp

elif [ "$2" = "down" ] ; then

  export reason=STOP

  sh /etc/dhcp/dhclient-exit-hooks.d/ntp

fi

exit 0

After installing the NetworkManager dispatcher script, you will need to perform one of the following actions to update NTP settings. Warning: Taking any of these actions will also result in a disruption of network access.

• Disable and then re-enable the network interface, using either nmcli or the NetworkManager applet menu. Note that the menu location and appearance will vary depending on the Ubuntu version and desktop environment in use.
• Restart NetworkManager by entering the command service network-manager restart
• Reboot the system.

Fedora, RHEL

Fedora and its derivatives, including RHEL, will use NTP servers from DHCP by default when DHCP is used. For this to work, the setting PEERNTP=NO must not be present in /etc/sysconfig/network, or in the interface-specific file /etc/sysconfig/network-scripts/ifcfg-DEV, where DEV is the interface name.

Advantages

Some of the advantages of using NTP include:

1. NTP can be easily deployed on servers hosting different services.
2. NTP requires less resource overhead.
3. NTP has minimal bandwidth requirements.
4. NTP can handle hundreds of clients at a time with minimum CPU usage.

Conclusion

NTP is in essence an extremely simple stateless transaction protocol that provides a quite surprising outcome. From a regular exchange of simple clock readings between a client and a server, it is possible for the client to train its clock to maintain a high degree of precision despite the possibility of potential problems in the stability and accuracy of the local clock and despite the fact that this time synchronization is occurring over network paths that impose a noise element in the form of jitter in the packet exchange between client and server. Much of today's distributed Internet service infrastructure relies on a common time base, and this base is provided by the common use of the Network Time Protocol.

Reference

• https://www.techopedia.com/definition/4512/network-time-protocol-ntp
• https://www.cisco.com/c/en/us/about/press/internet-protocol-journal/back-issues/table-contents-58/154-ntp.html
• http://searchnetworking.techtarget.com/definition/Network-Time-Protocol
• https://www.cs.cmu.edu/~help/networking/ntp.html