Transcript IEEE 1588 master clock

Time Synchronisation via Ethernet
An introduction to
IEEE 1588
Andreas Jost
Instrument Control System Seminar, 20th-24th October 2014
Time Synchronisation VLT
Grandmaster
Instrument Control Systems Seminar 2014, 20th-24th October
VLT Time Synchronisation Network
Paranal Control building
NTP
PTP
ESO Time Bus
ESO Time bus
NTP
PTP
UT
AT
NTP
PTP
ESO Time Bus
NAP
UT1
NAP
UT2
NAP
UT3
NAP
UT4
Telescopes/VLTI
Instruments
Instrument Control Systems Seminar 2014, 20th-24th October
IEEE1588 Time Sync
Instrument Control System Seminar, 20th-24th October 2014
PTP Message Exchange
PTP
UDP
IP
MAC
Phy
Precision Time Protocol (Application Layer)
User Datagram Protocol (Transport Layer)
Internet Protocol (Network Layer)
Media Access Control
Physical Layer
Instrument Control Systems Seminar 2014, 20th-24th October
Determination of Phase Change Rate (Drift) –
one step
Instrument Control Systems Seminar 2014, 20th-24th October
Determination of Phase Change Rate (Drift) –
two step
Instrument Control Systems Seminar 2014, 20th-24th October
Time Synchronisation
Instrument Control System Seminar, 20th-24th October 2014
Determination of Delay and Offset
Instrument Control Systems Seminar 2014, 20th-24th October
Time delay round trip
Master  Slave
Line delay
round trip
= 2x Tld
Instrument Control Systems Seminar 2014, 20th-24th October
IEEE1588: Time Synchonisation
First, one node (IEEE 1588 master clock) transmits a
"Sync" telegram, which contains the estimated
transmission time. The exact transmission time is
captured by a clock and transmitted in a second "Follow
Up" message. Based on the first and second telegram
and by means of its own clock, the receiver can now
calculate the time difference between its clock and the
master clock. To achieve the best possible results, the
IEEE 1588 time stamps should be generated in hardware
or as close as possible to the hardware.
The telegram propagation time is determined cyclically
in a second transmission process between the slave and
the master ("delay" telegrams). The slave can
then correct its clock and adapt it to the current bus
propagation time.
Instrument Control Systems Seminar 2014, 20th-24th October
Residence Time
Sync message multicast
Grandmaster
Clock
residence time
transition
delay
residence time
Slave
Residence time
- depends on traffic load
- can be asymetric
- cannot be compensated accurately by sync message
Instrument Control Systems Seminar 2014, 20th-24th October
transition
delay
Boundary Clocks in Network
Instrument Control Systems Seminar 2014, 20th-24th October
Transparent Clock
Instrument Control Systems Seminar 2014, 20th-24th October
TC accumulates residence time in
correction field
Instrument Control System Seminar, 20th-24th October 2014
Transparent Clock Types
The IEEE1588-2008 standard knows two types of transparent clocks,
namely:
End-to-End (E2E)
&
Peer-to-Peer (P2P)
• End-to-End TCs only measure the time taken for a PTP event message (those who get time
stamped) to transit the bridge and provide this information to the receiving clocks in the correction
field. No propagation delay of the link connected to the port is corrected by the E2E TC. E2E TCs use
the delay request / delay response mechanism for the delay measurement whereby the Residence
time of the delay request /delay response messages are corrected in the same way stated above.
• Peer-to-Peer TCs use the peer delay mechanism for the delay measurement. In addition
to providing PTP event transit time information the P2P TC also provides corrections for the
propagation delay of the link connected to the port receiving the PTP event message (correction
field).
Instrument Control System Seminar, 20th-24th October 2014
Transparent Clock – End-to-End Delay
Measurement
Sync Stream
e2e Delay Measurement
Instrument Control System Seminar, 20th-24th October 2014
End to End Delay
MC
TC
TC
Ordinary
Switch
Permits the use of ordinary switches, routers etc, „residence time“ of ordinary network equipment
is considered as transition time delay ( results in larger time error)
Instrument Control Systems Seminar 2014, 20th-24th October
Transparent Clock – Peer-to-Peer Delay
Measurement
Instrument Control Systems Seminar 2014, 20th-24th October
Transparent clock: Peer-to-Peer
The peer delay mechanism
measures the port to port
propagation delay time between
two directly connected ports
sharing the same communication
technology. The peer delay
mechanism is
independent of the state of a port
(master or slave). It operates
separately in both directions of the
link. Clock A and Clock B perform
the calculation of the peer-delay
•
In case Clock B is two-step
Instrument Control System Seminar, 20th-24th October 2014
TC Peer-to-Peer
•P2P
TC require that all network devices support
IEEE1588
• Ordinary switches would ignore the Pdelay message,
 time sync would therefore fail due to lack of
response
• P2P takes traffic load of Master clock, as the Pdelay
request is exchanged only between neighbouring
network hardware
• it allows to improve the time synchronisation by more
frequent exchange of Pdelay messaging without
increasing the overall network traffic.
• It supports well ring networks
Instrument Control Systems Seminar 2014, 20th-24th October
Peer-to-Peer
All links are periodically measured, so delay between the
master and slave are already known when the network path
changes. Note that peer-delay messages are exchanged
even on ports blocked to prevent loops, such as by the
Rapid Spanning Tree Protocol.
There is no chance of Sync and Delay_Request messages
taking different paths, since there are no Delay_Request
messages.
There is no need to worry about the master clocks ability to
respond to Delay_Request messages when there are a lot
of slaves, it only has to send the Sync and Follow_Up.
Instrument Control Systems Seminar 2014, 20th-24th October
Cascading Boundary Clock
Ring Network
Master
BC
BC
6x Boundary Clock
 6x Jitter of clock accumluated
BC
BC
BC
BC
Instrument Control System Seminar, 20th-24th October 2014
Jitter – BC vs TC
Transparent Clock
Reference: Hirschmann
Instrument Control Systems Seminar 2014, 20th-24th October
Use of Boundary Clock
TC End-to-End
TC PEER-to-PEER
Instrument Control System Seminar, 20th-24th October 2014
Boundary Clock – use at network points to
change communication technology
Boundary clocks are required wherever there is a change of the
communication technology or other network elements block the
propagation of the PTP messages. Furthermore it is recommended
that a Boundary clock be used wherever there is a network
component that inserts significant delay fluctuation.
Boundary clocks have typically more than 2 ports, with one port
serving as a PTP slave port to an upstream master clock, and the
other ports serving as PTP clock masters to downstream PTP
clocks. So with Boundary clocks you get time distribution trees.
Instrument Control System Seminar, 20th-24th October 2014
Boundary Clock vs Transparent Clocks
The Boundary clocks (BC) defined in both versions of the
IEEE1588 Standard. Standard v1 evidenced two problems of BC
when used in (highly) cascaded networks. Namely, there is
nonlinear decreasing synchronization accuracy and rising
resynchronization time after network reconfiguration. To
eliminate these effects the concept of transparent clocks (TC) has
been introduced in the IEEE 1588 standard version 2. Transparent
clocks were added in IEEE1588 - 2008 to correct the “residence
time” of the network device like an Ethernet Switch. The
residence time is accumulated in a field (correction field) of the
SYNC (one-step) or FollowUP (two-step) message. Since
transparent clocks are stateless they have no impact on there
configuration time of e.g. ring topology networks
Instrument Control System Seminar, 20th-24th October 2014
Topology and „Best Master Clock“
Instrument Control System Seminar, 20th-24th October 2014
Limits of time synchronisation
Instrument Control System Seminar, 20th-24th October 2014
Test time Synchronisation
1 pps
1 pps
Instrument Control Systems Seminar 2014, 20th-24th October
IEEE 1588 accuracy at Slave Clock
rms, max jitter peaks can be up to several us depending on network setup
ESO TIME Bus
< 10 us absolute to UTC ( relative time synchronisation between two slaves: < 1us,
jitter < +/-200ns)
Reference: Siemens
Instrument Control Systems Seminar 2014, 20th-24th October
PTP – common message header
End-to-End
Peer-to-Peer
Instrument Control System Seminar, 20th-24th October 2014
Calculate UTC from PTP timestamp
PTP Announce message
TAI = posix algortithm (PTP timestamp)
UTC = posix algorithm (PTP timestamp – currentUtcOffset)
 ISO 8601:2004
Instrument Control Systems Seminar 2014, 20th-24th October
Relationships between timescales
Instrument Control Systems Seminar 2014, 20th-24th October
Configuration of a IEEE1588 Network
A IEEE 1588 network configures and segments itself
automatically. For this, each node uses the "best
master clock" algorithm (BMC) in order to determine
the best clock in the segment. Every PTP clock stores
its features within a specified dataset. These features
are transmitted to other nodes within its "Sync"
telegrams. Based on this, other nodes are able to
synchronize their datasets with the features of the
actual master and can adjust their clocks accordingly.
Due to the cyclic running of the BMC, nodes can also
be connected or removed during propagation time (hot
plugging).
Instrument Control Systems Seminar 2014, 20th-24th October
.
IEEE1588 Network – Hardware/Software
No distinction is made in the IEEE 1588 protocol
between a software clock and a hardware clock.
However, to be able to work with synchronism in the
nanosecond range, hardware support is required.
Generally, the synchronization errors – caused by
software jitter – cannot be eliminated. With a pure
software solution (e.g. Windows systems), the error
may actually be in the micro- or milli-second range
Instrument Control Systems Seminar 2014, 20th-24th October
Grandmaster Clock
M900
www.meinberg.de
M600
www.ni.com
NI PXI-6682 - GPS
www.endruntechnologies.com
www.spectracomcorp.com
Instrument Control Systems Seminar 2014, 20th-24th October
Slave
www.ni.com
www.meinberg.de
PTP270PEX
www.beckhoff.de
Bridge to
EtherCAT
Instrument Control Systems Seminar 2014, 20th-24th October
Software implementation
IEEE1588 v2 slave
http://ptpd.sourceforge.net/
Transparent/Boundary clock
www.hirschmann.de
www.siemens.com
CISCO Nexus 3548
www.cisco.com
Instrument Control System Seminar, 20th-24th October 2014
Application areas for IEEE1588
Instrument Control Systems Seminar 2014, 20th-24th October