IEEE ISIE 2006, July 9-12, 2006, Montreal, Quebec, Canada

N TP versus PTP in Com puterN etw orks Clock

Synchronization

Teodor Neagoe, Arrow Electronics, Montreal tgo rcom Valentin Cristea, University Politehnica, Bucharest va Logica Banica, University of Pitesti, Romania o i iRo
Abstract

Trusted and precise time sources are required in computer networks and Internet for various reasons: time stamps for electronic documents, online transactions, storage and document retrieval, electronic mail, multimedia applications and many others. Also, the demand for Ethernet as a real-time control network is increasing, as manufacturers realize the benefits of employing a single network technology across the plant. For control and measurement applications, the need of an accurate distribution-wide sense of time is even more stringent than regular applications. This paper is comparing two clock synchronization protocols, the Network Time Protocol and the IEEE-1588 Precision Time Protocol. It gives an overview of synchronization methods by the time stamping employed in IP-based realtime applications looking at the possible sources of errors as well as the achievable performance of the two standards.
1.Clock Synchronization protocols

that may be a long distance call so, not economically in many applications. Today's data communication networks based on the TCP/IP protocol are found everywhere so, it became naturally to use them as the communication medium in time synchronization. Time keeping via the Internet has become a popular service, extending to hundreds of thousands public servers and clients in many countries all over the world [11]. Several clock synchronization protocols were developed over time and among them the followings can be cited: Time Protocol, Daytime Protocol, Network Time Protocol (NTP) and Simple Network Time Protocol (SNTP) [1].
2. N etw ork T im e P rotoco 1

Clock synchronization and time distribution have been part of communication networks from the beginning. Currently, the distribution of time information is achieved through the use of radio signals, telephone lines or data communication networks, such as Internet [1]. Radio based protocols are expensive as they need a great amount of hardware equipment. Despite this, they are still largely used and the motivation is the trustworthiness of the time source. In the TDM telephone networks, synchronization is a physical layer parameter that is designed to meet certain performance standards [9]. In order to use these lines to achieve clock synchronization, it is necessary to establish a dial connection

Network Time Protocol (NTP) is one of the most popular protocols used for Internet time synchronization. Version 3 of the protocol was developed by David Mills in 1992 and is specified in IETS RFT 1305. Version 4 started as Simple Network Time Protocol (SNTPv4 - TFC 2030) and is still under development. The basic difference compared to version 3 is the header structure that accommodates IPV6 addressing [9]. The NTP protocol is used to achieve clock synchronization between a trusted timeserver and it's clients. On a Local Area Network, without too much network equipment such as switches and routers it can achieve a precision of tens of milliseconds. A massive survey of the protocol in the global Internet revealed that most NTP clocks are within 21ms of their synchronization sources and all are within 29ms on average [11].

1-4244-0497-5/06/$20.00 2006 IEEE

31-7

stratumO 0

tFr eference Clock

sends back to the client, the N TP_response with the originate timestamp ST2.
Client

Server

Straitum 1

CT1

ST1

Stratum 2
Server Se-rver
e Hr-

Processing

Request

NTP_Resp
Stratum
--

ST2

CT2
e .E

ver

Stratu m

(I )
+

Time
erer

Time

Server

Server

Figure 2 NTP Requestand Response

Figure 1TypicalNTP H ierarchy

The synchronization architecture uses a stratum concept, that is, a hierarchical model (tree type) with each server on one level (stratum) serving as a time server to lower levels. Primary servers are set at the root of the tree as stratum 1 and are synchronized to external clock reference sources such as national standards or on-site atomic standard clocks (stratum o). Each following level towards the leaves, has a stratum one higher that the preceding level and the maximum allowed value for the stratum is 15 (Figure 1).
2.1 Protocol Implementation

The client receives the N TP response and generates the receive timestamp CT2. The following calculations are performed at the Client and Slave level. ST1=CT1+D cs +
cs

(1)

where DCS is the network delay between client and server and Ocs is the clock offset of the client with reference to the server.
CST2 =82 +Dsc +0SC
(2)

The basic synchronization principle is that each client sends periodic requests to a set of time-servers that respond with their local time stamp. The list of suitable servers is maintained in each client and is updated periodically. Internal algorithms evaluate the timestamps from all servers in order to select the best server, with the lowest stratum and synchronization distance, which will be used for setting the clock update. The time offset is calculated from a collection of four timestamps (two from the server and two from its own) (Figure 2). A Client, sends an N TP_ request message that contains the originate timestamp CT1 (Client Timestamp). Upon receiving the N TP_request, the Server generates the receive timestamp ST1 (Slave Timestamp). After processing the request, the server
318

where Dsc is the network delay between server and client and oSC is the clock offset of the server with reference to the client.

Adding (1) and (2) and because 0 cs=-o sc the round trip delay is:

D sc

+DC S

=(ST,1-CiT1)+(CT2 ST2)(3
-

same delay, D cs=D sc, the offset is:

Subtracting (2) from (1) and assuming the

cs-

(ST,r1-CTi1)-(CT2 -8ST2)
2

(4)

is built on UDP/IP and its is pure implementation software, timestamps being taken at the application level.
NTP

2.2 Possible Sources of Error in NTP

Several factors could affect the timing quality and offset/delay calculations: * Asymmetric propagation delays between client and server; * Fluctuations in network protocol stack between the application level and physical connection; Timestamp measurement errors; * Clock oscillator stability Each NTP server, maintains its local clock offset and round trip delay, relative to the primary reference source located at the root of the synchronization tree. Therefore, when a client sends an N TP request before sending a response with timestamps, the server adds its accumulated errors from the time its clock was last updated. Thus the clock offset and round trip delay increases as the stratum level increases from the primary reference source.
2.3 NTP Achievable Performance

A study conducted by Mills on the Internet revealed that peer-to-peer time offsets for servers using the NTP protocol had a cumulative distribution function where the median is 20.1ms and mean 28.7ms [11].
3. P recision T im e P ro to co l

Two indicators are important when evaluating a synchronization protocol: time offset, measured by the client relative to its time-server and the time offset, measured by the server relative to the peer server for each association. According to the standard, an NTP client is synchronized with the server if the time offsets are within 128ms. The local clock is adjusted gradually in small steps if the offset is less than 128ms. For offsets larger than 128ms, the synchronization process may take longer or never happens. The algorithm resets or the whole process reboots when the clocks difference is greater than looos. In most NTP implementations, Stratum 1 is located somewhere in the Internet, Stratum 2 near the gateway, with Stratum 3 and Stratum 4 at the Local Area Network level. In this configuration, peer-to-peer time offset were found with a mean value of 8.2ms, median of 1.8ms and standard deviation of 18ms. Dispersion to the root, or the primary server was found to be with a mean value of 88ms, median of 3oms and of deviation Published 175ms. measurements indicate that the offset of Stratum 4 based NTP client from different Stratum 1 server clocks in the Internet would be of the order of iooms [9].
339

IEEE 1588 is a Standard for Precision Clock Synchronization Protocol for Networked Measurement and Control Systems [1]. It is also known as Precision Time Protocol [PTP] and is used for time/clock synchronization in packet-based networks that support multicasting. As the name states, this standard was originally introduced for testing and automation industry, to achieve synchronization accuracies in the order of sub microseconds. Later on, it gained popularity and several other groups are showing interest, electrical power telecommunication, distribution and military applications [8]. The basic principle is that the most precise clock on the network synchronizes all other users. A grand master clock is located at the root of the hierarchy and is selected through so-called best master clock algorithm, based on the source of time it is connected to [4]. A PTP system includes several masters, serving groups of local clocks or slaves Figure 3.
Stratum 1

Reference Clock

Stratum 2
Grand

Stratum 3

StratIum 4

-.1588 Clock 1588 Clock

1588 Clock

1588 Clock

Figure 3 M aster-S lave hierarchy inT EE 1588

PTP uses stratum numbers similar to NTP and clock identifiers to describe the quality of a particular clock [9]. Stratum 1 clocks include an atomic clock, a GPS receiver or a high precision local oscillator. The maximum number allowed for stratum based classification is 256 with only four

being currently defined in the IEEE 1588 standard. A master sends continuous multicast messages to the slaves while slaves respond to the master by unicast messages. PTP is built over IP and UDP and uses several variables to calculate the offset and delay of a local clock with reference to the master. The protocol uses basically four messages: Sync, Folbw _U p, D elay_R equest and D e]ay_R esponse between a master and slaves. Sync and D e]ay_R equestare used for time stamps, while the other two carry the precise time stamps from the master, respective the slave.
3.1 Protocol implementation Every slave synchronizes to it's master's clock, by exchanging specific messages. The PTP protocol utilizes two phases for setting the local clock (time): 0 fset measurement phase and D elay measurement phase (Figure 4).
Master
C iT1 Offset measurement

exact time (MT1) of transmission of the Sync, measured as close as possible to the transmission media. After the first Sync and Folbw _Up messages the Slave concludes the following equation: ST1= M T1+ 0 fFset+ Delay (5)

The difference between the slave time ST 1 and the master time M Ti is made up of both the o ffsetand the D elay. To determine the Delay, the slave at time ST2, sends a D elay_Requestmessage to the master that in return sends back a D elay_R esponse containing the precise time when D elay_R equest has arrived a the master. As a result:
M T12 = ST2-0 fFset+ D elay

(6)

By adding (5) to (6) a fEet cancels out and we can calculate the Delay assuming it is the same in both directions:
De]ay

Slave

phase

Sync

-(ST1-MT1)+ M T2-ST2)
2

ST1

(MTT1:)

measurement

Delay

Delay_
-F

ST2

Now, the offset can be calculated on the following Sync/Folbw -Up message exchange:
O fFet= ST3-M T3-Delay

phase

(8)

Synchronization

Final

MT3 h T

(MT2)
i ST3 i

At this point synchronization is achieved by adjusting the time at the slave: NewST = 0ldST-O0ft-D elay

Follow-Up

(MVT3)

(9)

Time

Ti- ime

Figure 4 0 ffsetand D elaym easurem ent

During the 0 fSet measurement, the master periodically transmits sync messages to related slaves using multicasting. These messages are sent at pre-defined intervals, by default every 2 seconds. The sync message contains the estimated time when the message will leave the master. The master measures the exact time of transmission M T (Mater Time) and the slaves measure the exact time of reception ST (Slave Time). Optionally, for highly accurate synchronization, the master can send a Fo]lw _up message that contains the
340

The D elay measurement is performed irregularly and at larger time intervals then the o fset measurement, in order to reduce the traffic on the network.

3.2 Possible Sources of Error in PTP

affected by several factors: network protocol stack delay fluctuations, network technology architecture, clock timestamp accuracy and clock oscillator stability [5]. Timestamps are more accurate in PTP because of the usage of the Fo]lw -Up and Similar to the NTP protocol, offset measurements and synchronization are

D elay_R esponse messages that carry the exact timestamps measured as close as possible to the physical transmission line. Also, 1588 uses two sets of measurements with one (sync) executed more often than the other. When compared to NTP, traffic is almost double in a PTP based system. This can cause problems on low bandwidth links. To overcome the problem, the 1588 specification requires a certain local clock oscillator stability that will allow its messages to be sent at much larger time intervals.

3.3 Hardware Versus Software IEEE 1588 Implementations

At the present time two implementations of the 1588 PTP exist in the industry: software only implementations and hardwareassisted software implementations [5]. In software only implementation (Figure 5) the whole protocol is executed at the application level, including the processing of the timestamps and control of the Real Time Clock.

milliseconds, depending on the operating system [5]. Going down on the IEEE-1588 message path, and processing the timestamp at the physical layer, could lead to greater accuracy, in the order of tens of nanoseconds. Hardware assist methods, generate and process timestamps as close as possible to the transmission media and typically incorporate other functions like hardware Real Time Clock, Processor Interface, etc. Figure 6 presents a proposed hardware assisted software implementation of the IEEE 1588 protocol [4].

Netwvork Protocol Stack (OS)

Mil IF
PH

Wire Physical ..j

Figure 6 IEE E-1588 HW Im plem en tation

F igu re 5 IE E E 15 8 8 S o ftw are Im p lem en tation

The Time Stamp Unit (TSU) is connected at the MII interface and is responsible for inserting or extracting the Time Stamp from the IEEE 1588 packets and send it to the protocol task. The HW Real Time Clock is programmed initially by the Operating System and updated by the 1588 software but it counts independently, based on the hardware clock of the processor. Most of today's hardware implementations are based on FPGA circuits connected at the MAC level of the network interface card [7]. Some manufacturers are offering hardware assisted 1588 implementations in the processor silicon. Intel( Corporation is one of the first ones with the new IXP465 family of xScale network processors [5].

Therefore, it yields the least accuracy, as the largest amount of errors is introduced into the timestamp, especially because of the fluctuations in the network. Typically, in a software implementation, errors range in the order of hundred of microseconds to

3.4 Limitations and Achievable Performance in PTP

IEEE 1588 defines two separate types of clocks: ordinary clocks, in devices that have a single port and boundary clocks in devices such as hubs or switches that have more
351

than one PTP port [12]. The acyclic topology specified by the standard (no more than one master clock per communication path) represents a single point of failure and may lead to loss of synchronization in parts of the network. Also, the IEEE 1588 standard does not specify details about robustness of clock synchronization. Things like failure recovery, timing paths and redundancy of the master clocks are left to implementation. Being a relatively new standard it was not yet implemented and tested to the full extent. However, compared to NTP, preliminary data shows on LANs, synchronizations in sub-millisecond range for software implementations. On the other hardware hand, implementations of 1588 fall in submicrosecond range for the same type of network. Experiments with an FPGA-based hardware assisted implementation realized by Agilent Technologies, observed synchronization between a master and a slave on the same LAN capable of keeping time within 2ons [17.
4 . C on clu sin s

R eferences

performance. NTP is well established and is widely used on the Internet. It is satisfactory for many applications with synchronizations in milliseconds for Local Area Networks and hundreds of milliseconds for Wide Area Networks and Internet. It doesn't satisfy the more stringent real-time multimedia or control applications. PTP is a relatively new standard, embraced mainly by the control and measurement industry and preliminary tests demonstrated achievable synchronization performance of sub-microseconds in Local Area Networks. However, Internet community is also interested and there are proposals for modified versions of the standard to be adopted in Metro Enterprise Solutions [13]. A combination of the two standards with NTP on the background Internet and PTP at the Local Area Network level, may be the ideal configuration.
362

Clock and time synchronization on computer networks and Internet is extremely important. This paper has examined two time synchronization protocols, NTP and PTP and compared their architecture, protocol implementation, of error and achievable sources

[1] J. da SilvaS. Dias, R. F. Custodio, D. B. Demetrio, C. R. De Rolt "Reliable Clock Synchronization for Electronic Documents", Santa Catarina State University, 2002. [2] IEEE Std. 1588-2002, Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems, November 2002 [3] S. Balasubramanian, K. R. Harris and A. Moldovansky "A Frequency Compensated Clock for Precision Synchronization using IEEE1588 and its Applications to Ehternet" IEEE-1588 Workshop September 2003. [4] Dirk S. Mohl, "IEEE1588 - Precise Time Synchronization as the Basis for Real Time Applications in Automation", WEB article. [1] Puneet Sharma, "Hardware Assisted IEEE 1588 Implementation in a Next Generation Intel Network Processor", IEEE-1588 Conference, September 2004. [6] David L. Mills "NTP Architecture, Protocol and Algorithms", University of Delaware, August 2004. [1] J. Guilford, "Design of an FPGA-Based Hardware IEEE-1588 Implementation", IEEE-1588 Conference, September 2005. [8] Dave Tonks, "IEEE 1588 in Telecommunication Applications", IEEE i588 Conference, September, 2005. Radha "Technical [g] Telikepalli, Assessment of Synchronization Methods in IP networks from Quality of Experience Perspective", TR41.4/o5-11-oo5, 2005. [io] T. Neagoe, M. Hamdi, V. Cristea "Frequency Compensated, Hardware IEEEi588 Implementation", Montreal 2006. [il] D. L. Mills, A. Thyagarjan, B. C. Huffman, "Internet Timekeeping Around the Globe", University of Delaware, 2002. [12] Paula Doyle, "Introduction to RealTime Ethernet", The Extension, Volume 5, Issue 4, July-August, 2004. [13] Glenn Algie, "IEEE 1588 proposal for Metro Ethernet Enterprise Solutions", Nortel Networks, IEEE 1588 Workshop, Sept. 2003