Coordinated Universal Time
The Coordinated Universal Time (UTC) is the universally accepted time standard based on atomic clocks with leap seconds added judiciously to keep it in tune with the traditional solar time. The UTC is available as standard from designated national measurement institutes (NMIs) in most countries. It is used as the standard by computers around the world for keeping the clock time, using it in time fields in applications and for recording the time of transactions. The local time is expressed as an offset from the UTC.
Network Time Protocol
The Network Time Protocol (NTP) is for synchronizing the clock of computers on a subnet with the UTC. A host on this subnet may be a primary server, or a secondary server or a client. The primary servers are directly synchronized with a reference atomic clock over the wire (RS232C) or radio. The reference atomic clocks are, run by NMIs, are at top of the network, at stratum 0. The next level below is that of primary network time servers at stratum 1. Stratum 1 primary time servers are directly connected to the reference clocks. After that we have secondary servers below, from stratum 2 onwards. The leaves of the network are the secondary servers and clients. The clients synchronize with the upstream servers but do not provide synchronization information to others. The servers also work in the symmetric mode where, they exchange the time synchronization data with peer servers and try to improve the accuracy of their time information. There is also a broadcast mode, where a server broadcasts time on a subnet and hosts working as broadcast clients pick up the time synchronization packets and update their time. NTP clients account for the round trip delay and other inherent latencies and uncertainties while processing the time information received from multiple servers. As the time information comes from multiple sources, NTP processes are able to distinguish between truechimers, the clocks that give time as per their published standards, and, falsetickers, which are the clocks that are not able to give time as per their published standards. The algorithms discard falsetickers and use truechimers for synchronizing the time data stored in the system.
Figure 1: NTP reference clocks, servers and clients
NTP works over the User Datagram Protocol (UDP) on port 123.
An organization or setup, wishing to synchronize its network, should establish a few secondary time servers at stratum 2, that synchronize time with the primary time servers available in the area. Then, depending upon the number of clients more secondary servers at lower strata (with increasing stratum numbers) should be established. NTP is a low overhead protocol and higher strata secondary servers can easily be located on hosts on the subnet providing other services.
NTP data structures
The 64-bit timestamp has a 32-bit seconds field and 32-bit fraction field. The 32-bit unsigned integer seconds field can keep seconds for 136 years. The 32-bit fraction part resolves into a precision of 232 picoseconds (1 / (232) * 10-12 seconds). The epoch is January 1, 1900, 00 hours UTC. Even though UTC did not exist at that time, NTP assumes it to exist for dates prior to January 1, 1972, so that earlier dates can be referenced. All this will work fine till some time in the year 2036. NTP takes care of this by recognizing eras. The era 0 is from the year 1900 to 2036, era 1 is from February 8, 2036 for the next 136 years and so on. NTP has a 128 bit date format, comprising of a 32-bit era number, a 32-bit era offset in seconds and a 64-bit fraction seconds. The 64-bit era number and offset seconds are good enough for 584 billion years and 64-bit fraction second gives a resolution of 0.05 attosecond (0.05 * 10-18 seconds). Lastly, there is a 32 bit short format, comprising of 16-bit unsigned integer seconds and another 16-bit fraction. The short format is used for delays and similar fields, where the range of values does not justify the larger formats.
Time Accuracy
The accuracy of the synchronized time at the client depends on the distance of the server from the client. We need to choose the servers closest to us so as to minimize the client-server propagation delay. The accuracy of client's synchronized time could be about tens of milliseconds on the Internet and about 1 millisecond on a local area network (LAN). Then the frequency of synchronization needs to be chosen judiciously. If the client is synchronized too often, there will be more network and client and server load. But if the synchronization is at large intervals of time, the accuracy of time kept would go down. As a rule of thumb, the primary servers may be queried every minute and the secondary servers less often, the frequency of synchronization decreasing with increase in the server stratum number. Then there is the dependency on the ambient temperature. The clock oscillator loses oscillations at higher temperatures. So, with proper air conditioning, we need to keep the ambient temperature below 25° Celsius.
Security considerations
Like other Internet protocols, NTP is subject to the underlying security threat that the remote server may not be authentic and also the packets received may be fake from an intruder. The dangers are most severe for strata 1 and 2 timeservers, as these are on top of the subnet, and any compromise would have a cascading effect downstream. To take care of the security aspect, NTP has provisions for public certificates for traceable authority, digital signatures to verify credentials and message digests for checking for packet modification. NTP version 4 provides authentication based on public key cryptography using the Autokey protocol. With proper authentication procedures, it is possible to maintain the security of the timeservers.
Configuring the NTP
The first step is to install the NTP software on the host. This will depend upon the operating system installed on the host. On a Debian based Linux system, one has to give the command,
sudo apt-get install ntp
After installation, NTP runs as the ntpd daemon. The default configuration file is /etc/ntp.conf. It is a typical configuration file, with comments starting with the #
character and ending with the end of line. The commands are single line commands. A command may be a configuration command for configuring a remote server, peer or a reference clock. Then, there are auxiliary command for setting options for various operations. A sample /etc/ntp.conf is given below:
# /etc/ntp.conf, configuration for ntpd
driftfile /var/lib/ntp/ntp.drift
# Specify NTP servers.
server 0.pool.ntp.org iburst
server 1.pool.ntp.org iburst
server 2.pool.ntp.org iburst
server 3.pool.ntp.org iburst
# By default, we do not talk to anyone
restrict default ignore
# But we provide full access to local users
restrict 127.0.0.1
# Provide time to clients on the subnet
restrict 192.168.1.0 mask 255.255.255.0 kod notrap nomodify nopeer noquery
# And for the servers,
restrict 0.pool.ntp.org kod notrap nomodify nopeer noquery
restrict 1.pool.ntp.org kod notrap nomodify nopeer noquery
restrict 2.pool.ntp.org kod notrap nomodify nopeer noquery
restrict 3.pool.ntp.org kod notrap nomodify nopeer noquery
# Enable logging of statistics.
statsdir /var/log/ntpstats/
statistics loopstats peerstats clockstats
filegen loopstats file loopstats type day enable
filegen peerstats file peerstats type day enable
filegen clockstats file clockstats type day enable
As per the above configuration file, the drift file is /var/lib/ntp/ntp.drift. The drift file contains the frequency offset of the local clock oscillator, measured in parts per million (PPM). It is updated by the ntpd daemon every hour. Then, there is the all important specification of NTP servers from where we synchronize our time. In the above example, we have <number>.pool.ntp.org, which point to random servers at the NTP Pool Project. For the best results, servers that are geographically close should be be used. One can find nearby servers from the NTP Pool Project. We have used the option iburst, which means that when the server is unreachable, a burst of eight packets should be sent instead of one. With the restrict commands, we restrict the way other hosts interact with us. By default, we ignore the packets received, Since we have put such a restrictive clause, we need to put separate restrict statements for all hosts which whom we interact. Thus there are separate restrict statements for the local users, hosts on the subnet and each of the servers. Finally, we enable the recording of the NTP statistics.
With the above configuration, we establish a secondary NTP server. Next, we can have local clients that synchronize with this server. The NTP software needs to be installed on the client machines also. Assuming the internal IP address of the server as 192.168.1.100, the /etc/ntp.conf file on a client could be,
# /etc/ntp.conf, configuration for ntpd
driftfile /var/lib/ntp/ntp.drift
# Specify one or more NTP servers.
server 192.168.1.100 iburst
# By default, no access
restrict default ignore
# Local users (on this host) have the full access
restrict 127.0.0.1
# Allow (restricted) access to the server
restrict 192.168.1.100 kod notrap nomodify nopeer noquery
We would normally have more than one server, so that clients can get time from multiple sources and arrive at more accurate value of time. Similarly, servers should synchronize with multiple upstream servers and have peer connectivity amongst themselves.
Related commands
ntpq, ntpdc and ntpdate.
References
- D. Mills, J. Martin, J. Burbank and W. Kasch,
Network Time Protocol Version 4: Protocol and Algorithms Specification
, RFC 5905, June 2010. - NTP: The Network Time Protocol
- Executive Summary: Computer Network Time Synchronization
- The World Time System
- Coordinated Universal Time (UTC) – Bureau International des Poids et Mesures (BIPM)
- NIST Internet Time Service (ITS)
- Time Dissemination Services
- NTP Security Analysis
- man ntp.conf
- ntp-doc installed in /usr/share/doc/ntp-doc/html/
- Configuring NTP
- NTP Pool Project
