NTP Network Time Protocol (RFC 1305)

Introduction to Time in a Networked Environment

 

NTS-3000 Elproma NTP Network Time Server

 

 

 

 

NTP Resource Requirements

 

 

NTP requires little resource overhead. This allows NTP to be easily deployed on servers hosting other services, even if the servers are heavily loaded. Even a single processor NTP server can serve thousands of NTP clients using only a few percent of its CPU capacity. If the server is a broadcast or multicast server, even fewer resources are required. The bandwidth requirements for NTP are also minimal. Unencrypted NTP Ethernet packets are 90 bytes long (76 bytes long at the IP layer). A broadcast server sends out a packet about every 64 seconds. A non-broadcast client/server requires 2 packets per transaction. When first started, transactions occur about once per minute, increasing gradually to once per 17 minutes under normal conditions. Poorly synchronized clients will tend to poll more often than well synchronized clients. In NTP version 4 (NTPv4) implementations, the minimum and maximum intervals can be extended beyond these limits, if necessary.

 

 

 

Types of Clients and NTP Servers

 

The relationship between NTP servers and clients can be configured to operate in several ways. Computers using NTP can operate in different modes with respect to different machines. For instance, a single machine could be a client of a machine with a lower stratum number, while being a peer to a machine on the same stratum, and a broadcast server to a number of clients at a higher stratum number.

 

n Server – An NTP server serves time to clients. Clients send a request to the server and the server sends back a time stamped response, along with information such as its accuracy and stratum.

 

n Client – An NTP client gets time responses from an NTP server or servers, and uses the information to calibrate its clock. This consists of the client determining how far its clock is off and adjusting its time to match that of the server. The maximum error is determined based on the round-trip time for the packet to be received.

 

n Peer – An NTP peer is a member of a group of NTP servers that are tightly coupled. In a group of two peers, at any given time, the most accurate peer is acting as a server and the other peers are acting as clients. The result is that peer groups will have closely synchronized times without requiring a single server to be specified.

 

n Broadcast/multicast server – An NTP server can also operate in a broadcast or multicast mode. Both work similarly; broadcast servers send periodic time updates to a broadcast address, while multicast servers send periodic updates to a multicast address. Using broadcast packets can greatly reduce the NTP traffic on a network, especially for a network with many NTP clients.

 

n Broadcast/multicast client – An NTP broadcast or multicast client listens for NTP packets on a broadcast or multicast address. When the first packet is received, it attempts to quantify the delay to the server in order to better quantify the correct time from later broadcasts. This is accomplished by a series of brief interchanges

where the client and server act as a regular (non-broadcast) NTP client and server. Once these interchanges occur, the client has an idea of the network delay and thereafter can estimate the time based only on broadcast packets. If this interchange is not desirable, it can be disabled using NTP’s access control features.

 

 

 

Accuracy and Resolution

 

NTP may take several minutes or even hours to adjust a system’s time to the ultimate degree of accuracy. There are several reasons for this. NTP averages the results of several time exchanges in order to reduce the effects of variable latency, so it may take several minutes for NTP to even reach consensus on what the average latency is. Generally this happens in about 5 minutes. In addition, It often takes several adjustments for NTP to reach synchronization. The result is that users shouldn’t expect NTP to immediately synchronize two clocks. The ntpdate command can be used if instant synchronization is needed. The peers command can be used in ntpq to determine if synchronization has been achieved. When a client has synchronized, the synchronization server is listed with an asterisk in front of it.

 

To allow clocks to quickly achieve high accuracy, yet avoid overshooting the time with large time adjustments, NTP uses a system where large adjustments occur quickly and small adjustments occur over time. For small time differences (less than 128 ms), NTP uses a gradual adjustment. This is called slewing. For larger time differences, the adjustment is immediate. This is called stepping. If the accuracy of a clock becomes too insufficient (off by more than about 17 minutes), NTP aborts the NTP daemon, with the assumption that something has gone wrong with either the client or server. In order to synchronize well with a server, the client needs to avoid step adjustments.

 

The accuracy of NTP thus depends on the network environment. Because NTP uses UDP packets, traffic congestion could temporarily prevent synchronization, but the client can still self-adjust, based on its historic drift. Under good conditions on a LAN without too many routers or other sources of network delay, synchronization to within a few milliseconds is normal. Anything that adds latency, such as hubs, switches, routers, or network traffic, will reduce this accuracy. The synchronization accuracy on a WAN is typically within the range of 10-100 ms. The time synchronization accuracy on a LAN is typically better than 1-10ms. For the Internet, synchronization accuracy is unpredictable, so special attention is needed when configuring a client to use public NTP servers. If synchronization accuracies better than the above estimates are required, there are several options for obtaining even higher synchronization accuracy:

 

n Connecting directly to a reference clock – If a server is attached directly to a reference clock, the accuracy is limited only by the accuracy of the reference clock and the hardware and software latencies involved in the connections to it.

 

n Pulse Per Second (PPS) – Clocks can use PPS radio receivers, which receive on-thesecond radio pulses from a national standards organization. If the time is within a fraction of a second, the PPS pulses can be used to precisely synchronize to the tick of the second. This method achieves accuracies in the tens of microsecond range.

 

n Precision time kernel – The Solaris OE has a precision time kernel that allows the kernel clock to be updated to microsecond resolution (though not necessarily microsecond accuracy). By default, the precision time kernel is used by the versions of NTP which are included with the Solaris OE. Precision time kernels are defined in RFC 1589.

 

The maximum resolution of an NTP time stamp is about 200 picoseconds (about the time it takes an electrical pulse to travel through 2 cm of copper wire), so the ultimate accuracy of NTP is likely to be limited by hardware and latency concerns, rather than by the NTP protocol. The important thing to remember is that NTP accuracy is always limited by the time source. A client synced to an inaccurate server, will be inaccurate. This dependency is true all the way up the chain to the reference clock. If the reference clock is miscalibrated, all the clients will be affected.

 

 

Previous Ppage                                                                      Top of page                                                                                Next Page