threats (denial-of-service and man-in-the-middle attacks being some of the
more obvious). It must accept these
penalties or, in the case of security, account for these challenges.
Security in particular is worth highlighting, since PTP includes only an
experimental extension to the protocol to address security concerns, but
NTP defines the use of access-control
lists and a variant of public-key cryptography called Autokey.
6 Also note
that NTP can use a multicast mode to
discover servers automatically when
used on a LAN, and PTP can operate in
a unicast mode to be used over a WAN.
Neither of these uses, however, is the
most common and may impose additional configuration costs.
Another PTP objective is administration-free operation, where the
devices that make up a system can be
deployed with little or no configuration
yet still achieve optimum time synchronization for the given environment.
Devices can be added, removed, or re-configured while the system is in use,
and the PTP devices that make up the
system will automatically negotiate a
new hierarchy in order to maintain optimum synchronization performance.
PTP’s BMC algorithm is responsible for
this behavior. NTP’s optimization algorithm does not permit the same degree
of autonomy in allowing any device to
become the equivalent of a PTP grandmaster if necessary, despite the inclusion of a dynamic discovery scheme in
the latest NTP specification.
NTP defines a series of mitigation algorithms to be used in finding the optimal network path,
6 provided an NTP
client has been configured to select
among more than one server.
While the synchronization methodologies employed by PTP and NTP are similar in that they both ultimately compute clock offset and message delays,
the protocols differ greatly in various
mechanisms that must be considered
when selecting the appropriate technology. For example, PTP relies on boundary clocks and transparent switches to
achieve maximum performance in certain environments. Not including these
devices or incorrectly using them could
significantly reduce PTP performance.
More relevant to implementers of
these specifications is the fact that
PTP does not define a servo algorithm
for applying the information PTP gives
a device to the device’s oscillator. In-
stead, the servo definition is imple-
mentation-specific, and there are no
guarantees that different PTP software
stacks will exhibit the same synchroni-
zation behavior on the same device. In
stark contrast, NTP “defines a highly
evolved, adaptive-parameter, hybrid
phase-frequency lock loop” used to ad-
just the device’s timekeeper from data
provided by NTP.
PTP has the capability to synchronize
devices to within nanoseconds of each
other over a common networking infrastructure, allowing system designers to replace synchronization solutions that are more expensive, limited,
or both. NTP has similar use cases, but
usually falls short for applications that
require the level of performance typical of measurement and control systems. PTP’s BMC algorithm allows it to
adapt to changing conditions to ensure
devices always have the highest-quality
time reference. PTP boundary clocks
and transparent switches ensure high
synchronization performance even
in a non-ideal network topology. In
contrast, NTP requires that all devices
be configured to reference a predetermined set of time servers prior to
use, and its performance suffers when
messages have to traverse network elements such as switches.
PTP’s intended environment is different from NTP’s, however, and depending on the application, NTP may
be a better choice. For example, NTP’s
more established security mechanism
and publicly available pool of time
servers9 make it better suited for synchronizing time over the Internet when
performance requirements permit.
PTP has filled a niche that NTP has
not been able to, but it has not replaced
it. Instead, PTP offers system designers
a new synchronization tool to put in
Principles of Robust Timing
over the Internet
Julien Ridoux, Darryl Veitch
Modern Performance Monitoring
The One-Second War
(What Time Will You Die?)
1. eidson, J. Ieee-1588 standard for a precision clock
synchronization protocol for networked measurement
and control systems. agilent technologies, 2005; http://
2. Ieee std. 1588-2008 section 6. 2. Ieee 1588
precision time protocol demonstration for stM32F107
connectivity line microcontroller (2011); http://www.
3. Ieee std. 1588-2008 section 19. 3.
4. Ieee std. 1588-2008 section 1. 2.
5. Ieee std. 1588-2008 section 7. 2.
6. Mills, d. Ieee 1588 Precision time Protocol (PtP),
7. Mills, d., Martin, J., burbank, J. and kasch, W. network
time Protocol Version 4: Protocol and algorithms
specification (2010); http://tools.ietf.org/html/rfc5905.
8. novick, a.n., Weiss, M.a., lee, k.b. and sutton,
d.d. examination of time and frequency control
across wide area networks using Ieee-1588v2
unicast transmissions (2011); http://www.nist.gov/
9. ntP Pool Project; http://www.pool.ntp.org.
Rick Ratzel ( firstname.lastname@example.org, email@example.com)
is a senior software engineer at national Instruments
in austin, texas, where he works in the timing &
synchronization group as a technical lead and developer.
he has developed software at an electronic design
automation start-up and a consulting start-up specializing
in scientific computing prior to joining nI. he has taught
Python classes for engineers.
Rodney Greenstreet ( firstname.lastname@example.org) is
a technical lead in the timing & synchronization group
at national Instruments with 20 years of industry
experience. he is responsible for implementing the
firmware for nI’s first usb device and designing the
first CompactPCI board, which served as the impetus
to the PXI platform. as a technical lead in the timing &
synchronization group, he is instrumental in architecting
sub-nanosecond hardware and software synchronization
products that leverage gPs, Ieee 1588, IrIg, and others.