1
Design Considerations for Software Only Implementations
of the IEEE 1588 Precision Time Protocol
Kendall Correll, Nick Barendt
VXI Technology, Inc.
Cleveland, Ohio, USA
Michael Branicky
EECS Dept., Case Western Reserve University
Cleveland, Ohio, USA
Abstract – This paper investigates adjusting computer clock
frequency and time to provide a precise clock for test and
measurement systems. In particular, it is concerned with the
precision achievable using IEEE 1588 Precision Time Protocol
systems without the support of specialized hardware. This paper
outlines the design of a free IEEE 1588 implementation named
PTPd. Particular attention is paid to the design of the clock
servo—the system that steers the clock rate. This paper evaluates
the implementation by the precision of the time coordination
between networked test and measurement systems.
I. INTRODUCTION
The IEEE 1588 Precision Time Protocol (PTP) [1]
provides a means by which networked computer systems can
agree on a master clock reference time, and a means by which
slave clocks can estimate their offset from master clock time.
PTP implementations typically have a clock servo that uses a
series of time offset estimates to coordinate the local slave
clock with the reference master clock time, a process referred
to as clock discipline.
This paper presents our software-only implementation of
PTP. Precise time coordination with PTP relies on precise
estimates of the send and receive times (time stamps) of
messages exchanged between the master and slaves. High
precision time stamps can be achieved with the support of
specialized hardware interfaces in the physical layer of the
network; however, many legacy systems lack such hardware
interfaces. A PTP implementation that is not supported by
specialized hardware is referred to as a software-only
implementation. These implementations must time stamp in
higher layers of the network, which introduces large degrees
of non-determinism in the time stamp latencies, known as
jitter. Achieving precise master-slave time coordination with
jittery time stamps is the primary obstacle in the design of
software-only PTP implementations.
This paper is organized as follows. Section II is a brief
introduction to IEEE 1588 (PTP). Section III introduces PTPd,
our open-source, software-only PTP implementation. Section
IV provides an overview of clock servo design and the
specifics of PTPd’s clock servo. Section V presents test results
of PTPd’s performance in a target application. PTPd achieved
precision on the order of microseconds. Section VI presents
conclusions, comments on future work, and a link to PTPd’s
source code.
II. PTP IN BRIEF
A. Masters and Slaves
In PTP, master clocks provide the reference time for one
or more slave clocks through the exchange of messages over a
network. The protocol determines a unique master among a
group of clocks using the Best Master Clock algorithm
(BMC). The BMC selects the most stable and accurate clock.
B. Sync Messages
PTP masters send Sync messages. The master records the
send time of Sync messages (t
1
), and slaves record the receipt
time (t
2
). The difference between the send and receipt times of
Sync messages is the master-to-slave delay (d
m2s
):
d
m2s
= t
1
– t
2
. (2.1)
Sync messages are sent once per Sync interval (T
sync
)
(typically 2 s). This makes the master-to-slave delay sampling
period (T
m2s
):
T
m2s
= T
sync
= 2 s. (2.2)
C. Delay Request Messages
PTP slaves send Delay Request messages. Slaves record
the send time of Delay Request messages (t
3
), and the master
records the receipt time (t
4
). The difference between the send
and receipt times of Delay Request messages is the slave-to-
master delay (d
s2m
):
d
s2m
= t
3
– t
4
. (2.3)
Delay Request messages are sent on intervals uniformly
distributed between 2 and 30 Sync intervals. This makes the
slave-to-master delay sampling period (T
s2m
):
T
s2m
= T
sync
* U[2,30]. (2.4)
D. One-Way Delay
PTP calculates an estimate of the message propagation
delay. This calculation assumes symmetric propagation
delays, so that an average of the master-to-slave and slave-to-
master delays cancels the time offset between master and
slave. This yields the message propagation delay, which the
specification refers to as the one-way delay (d
prop
):
d
prop
= (d
m2s
+ d
s2m
)/2. (2.5)
Assuming symmetric propagation delays is often, but not
always, valid. Asymmetric propagation delays cannot be
observed by the protocol. They will cause a constant bias in
the one-way delay and, in turn, the overall time coordination.
The bias will equal half of the magnitude of the delay
asymmetry.
Assuming a constant delay asymmetry, an asymmetric
delay bias can be eliminated by adding a latency correction to
the master-to-slave or slave-to-master delay that cancels the
asymmetry; however, assuming constant delay asymmetry
also may be invalid.
E. Offset From Master
PTP estimates the time difference between master and
slave clocks. This is the master-to-slave delay corrected for
message propagation delay, and it is referred to as the offset
from master (∆t):
∆t = d
m2s
– d
prop
. (2.6)
III. PTPd IN BRIEF
A. Background
The Precision Time Protocol daemon (PTPd) is a
software-only PTP implementation. It was developed by two
评论18