Texas Instruments | IEEE 1588 Synchronization Over Standard Networks Using the DP83640 (Rev. A) | Application notes | Texas Instruments IEEE 1588 Synchronization Over Standard Networks Using the DP83640 (Rev. A) Application notes

Texas Instruments IEEE 1588 Synchronization Over Standard Networks Using the DP83640 (Rev. A) Application notes
Application Report
SNLA116A – May 2009 – Revised April 2013
AN-1963 IEEE 1588 Synchronization Over Standard
Networks Using the DP83640
.....................................................................................................................................................
ABSTRACT
This application report describes a method of synchronization that provides much more accurate
synchronization in systems with larger PDV. The method described attempts to detect minimum delays, or
'lucky packets'. The method also takes advantage of the DP83640 clock control mechanism to separately
control clock rate and time corrections, minimizing overshoot or wild swings in the accuracy of the clock
time.
1
2
3
4
5
6
7
Contents
Introduction ..................................................................................................................
Background ..................................................................................................................
2.1
Proposed Algorithm ................................................................................................
Test Platform ................................................................................................................
Test Results .................................................................................................................
4.1
Single Switch Results .............................................................................................
4.2
Multiple Switch Testing ............................................................................................
4.3
Other Testing Results .............................................................................................
Additional Opportunities ....................................................................................................
Conclusions ..................................................................................................................
References ...................................................................................................................
2
2
3
5
6
6
7
8
8
9
9
List of Figures
1
Basic PTP Timing Diagram ................................................................................................ 2
2
MTIE Plot For Basic Algorithm, 80% Traffic Utilization
3
4
5
6
7
8
................................................................
Rate Correction Diagram...................................................................................................
Test Platform ................................................................................................................
MTIE Plot for One Switch Tests...........................................................................................
TDEV Plot for One Switch Tests ..........................................................................................
MTIE Plot for Three Switch Tests.........................................................................................
TDEV Plot for Three Switch Tests ........................................................................................
3
4
6
7
7
8
8
List of Tables
1
PPS Results For Single Switch Tests .................................................................................... 6
2
PPS Results for Three Switch Tests ..................................................................................... 7
PHYTER is a trademark of Texas Instruments.
All other trademarks are the property of their respective owners.
SNLA116A – May 2009 – Revised April 2013
Submit Documentation Feedback
AN-1963 IEEE 1588 Synchronization Over Standard Networks Using the
DP83640
Copyright © 2009–2013, Texas Instruments Incorporated
1
Introduction
1
www.ti.com
Introduction
Texas Instruments DP83640 precision PHYTER™ implements time-critical portions of the IEEE 1588
Precision Time Protocol (PTP), allowing high precision IEEE 1588 node implementations. When used with
a network consisting of IEEE 1588 capable devices, boundary clocks or transparent clocks, very high
precision can be obtained with very simple clock servo algorithms to determine rate adjustments and time
corrections. Sophisticated processing is not necessary as only simple averaging or filtering of the protocol
measurements is required. When a network consists of devices that are not IEEE 1588 capable, packet
delay variation (PDV) is significant. A simple clock servo will not provide a very accurate level of
synchronization.
2
Background
The IEEE 1588 PTP provides the basic information for the slave to determine both frequency and time
offsets relative to the grandmaster clock. The basic algorithm involves measuring the Master-to-Slave and
Slave-to-Master path delays using the sync and Delay_Req messages, respectively.
Figure 1 shows the most basic IEEE 1588 timing diagram.
Master clock time
t1
Slave clock time
Sync
t2
t3
t4
Delay_Req
Figure 1. Basic PTP Timing Diagram
The Master-to-Slave and Slave-to-Master delays are:
MSdelay = t2 - t1
SMdelay = t4 - t3
The one-way-delay or meanPathDelay is just the average of these delays:
meanPathDelay = (MSdelay + SMdelay)/2
In the ideal case, the time offset is just:
offset_from_master = MSdelay - meanPathDelay
In a network with network elements (bridges, switches, routers) that include support for IEEE-1588, packet
delay variation is essentially negligible. In boundary clock devices, a synchronized clock is maintained on
the network element that synchronizes its time and rate to an upstream master, and acts as a master to
downstream devices. In transparent clock devices, the packet delay variation is corrected by measuring
the residence time for the PTP message as it traverses the device.
In a network with non-1588 capable elements, no compensation is made, resulting in packet delay
variation on the order of tens or hundreds of microseconds. These delays become significant and can
make any single measurement extremely inaccurate.
Figure 2 shows an maximum time interval error (MTIE) plot of tests with an 80% traffic condition over a
single switch using a basic algorithm with only simple averaging and filtering. As can easily be seen, this
provides relatively poor synchronization, with errors as large as 100 ms.
2
AN-1963 IEEE 1588 Synchronization Over Standard Networks Using the
DP83640
Copyright © 2009–2013, Texas Instruments Incorporated
SNLA116A – May 2009 – Revised April 2013
Submit Documentation Feedback
Background
www.ti.com
1000000
measured
100000
MTIE (ns)
10000
G.823 PDH
1000
100
G.811 PRC
10
1
1
10
100
1000
10000 100000
OBSERVATION INTERVAL (ns)
Figure 2. MTIE Plot For Basic Algorithm, 80% Traffic Utilization
2.1
Proposed Algorithm
In a network with non-1588 capable components, the packet delay may range from the minimum physical
delay up to the sum of the maximum delays through each device. In practice, there is usually a minimum
transmission delay for each device, and therefore a minimum total packet delay from the master to the
slave. The basic operation is to attempt to detect the minimum delays, or 'lucky packets', and use the
results from these packets to make rate and time corrections. The algorithm is essentially broken down
into three stages: meanPathDelay measurement, rate correction, and time correction.
2.1.1
meanPathDelay Measurement
In most networks, the minimum path delay is a relatively constant value. Reconfiguration of the network
can cause step changes, but these are usually not very frequent. Thus it is possible to detect the minimum
meanPathDelay using a long-term tracking of minimum roundtrip delays (the full Sync-Delay_Req
computation). The implementation keeps a history of the last N meanPathDelay measurements and finds
the minimum value over those measurements:
Min_meanPathDelay(n) = min(meanPathDelay[n+1-N:n]).
Determining the minimum meanPathDelay is critical to doing both the rate correction and time correction.
2.1.2
Rate Correction
Rate correction would typically be done by measuring subsequent sync cycles, and determining the
difference between the master measurement of the start of each message versus the slaves
measurement of the arrival of each message. This gives a basic ratio of the slave frequency versus the
master and can be used to correct for that frequency difference. Since packet delay variation can be
significant, this can make any individual rate measurement inaccurate by a significant amount. For
example if the sync period is 8 syncs per second, the error might be l00 µs in 125 ms, or close to 1000
ppm. lf the algorithm were to average all rate measurements, it might require hundreds or thousands of
seconds for the rate measurement to converge to a reasonable estimate. Because of the long averaging
time, it would also result in a frequency control that could not adapt to short term frequency changes that
might occur when using an inexpensive oscillator.
SNLA116A – May 2009 – Revised April 2013
Submit Documentation Feedback
AN-1963 IEEE 1588 Synchronization Over Standard Networks Using the
DP83640
Copyright © 2009–2013, Texas Instruments Incorporated
3
Background
www.ti.com
Instead, the proposed algorithm takes advantage of the meanPathDelay measurements to detect lowlatency packets and uses only those packets for detecting the rate of frequency offset to the master. lf a
packet meets the requirements for a good minimum roundtrip delay, the rate is measured by comparing
the times since the previous 'good' packet. By using only the low-latency measurements, the convergence
time for determining the frequency offset to the master can be reduced significantly. In qualifying 'good'
packets, there is a trade-off between quality and quantity. lf the qualification is too restrictive, not enough
information will be obtained to track frequency changes. If not restrictive enough, the rate calculations may
include excessive variation.
Master clock time
T1
Slave clock time
µJRRG¶ 6\QF
T2
T1(n)
...
µJRRG¶ 6\QF
T2(n)
Figure 3. Rate Correction Diagram
Figure 3 shows the basic relationship between sync messages used to determine the rate. From the
diagram, the rate ratio would be:
rate_ratio(n) = (T2(n)- T2) / (T1(n)- T1)
In addition, to prepare for the next measurement:
T1 = T1(n), and T2 = T2(n)
Since there still could be some error in measurements, some averaging or filtering of measurements is still
required. For simplicity, an exponential moving average, or smoothing function, is used to track the rate.
The equation is of the form:
rate_avg(n) = rate_avg(n-1)
+ α(rate_ratio(n) - rate_avg(n-1))
The value of α is typically set to 0.1, but may be increased under certain conditions such as extended
periods of increasing or decreasing rate. This allows faster adjustment of the rate under those conditions.
2.1.3
Time Correction
The typical implementation of the time offset determination uses a sync message to determine an offset
versus the master. Some level of averaging or filtering would normally be used to smooth out connections
and avoid over correcting for each measurement. For time correction, two different mechanisms were
tested to detect and correct time offset.
In the first mechanism, the basic idea is to search for minimum delays. The basic algorithm looks at the
minimum Master-to-slave delay over a number of the most recent delays. The time correction may also be
limited to prevent over-correction. This algorithm does rely on a larger number of sync messages than
would be required for a IEEE-1588 capable network. Additionally, following a Delay_Req measurement,
the algorithm may use either the Master-to-Slave delay or the Slave-to-master delay, whichever yields the
smaller offset. In cases where one direction of traffic may become congested, the other direction may
provide a more accurate measure of the time offset. This method will make a correction each cycle based
on the best information it has. This can result in improper corrections if there are no true minimum delay
messages received. The cause for this is that the algorithm cannot determine if the measurement error is
due to a time offset or to packet delay variation.
4
AN-1963 IEEE 1588 Synchronization Over Standard Networks Using the
DP83640
Copyright © 2009–2013, Texas Instruments Incorporated
SNLA116A – May 2009 – Revised April 2013
Submit Documentation Feedback
Test Platform
www.ti.com
The second mechanism for time correction attempts to only use delays to make corrections if they are
determined to be actual minimum delay packets. This helps to prevent invalid corrections to the time
value. The basic idea is to use both sync and Delay-Req messages to make time corrections. For sync
messages, if the MSdelay is less than the Min-meanPathDelay, then the measurement indicates there is
time offset of at least MSdelay Min-meanPathDelay. In this case, a time correction would be made based
on the offset measurement. If the MSdelay is greater than the Min-meanPathDelay, there is no way to tell
if the error is due to a time offset or due to PDV, so no correction is made. Similarly for Delay-Req
messages, if the SMdelay is less than the Min-meanPathDelay, then the measurement indicates there is a
time offset of at least Min-meanPathDelay - SMdelay. Note that this will result in a positive offset detected
rather than a negative offset as seen with the MSdelay measurement.
Both implementations makes time corrections by adjusting the PTP clock rate for a period of time. To
prevent large fluctuations in rate, each connection is limited in magnitude. This also helps to reduce time
interval errors due to rapid corrections of time offsets. In the second mechanism, this is handled by
keeping a TimeError value. When a new error is computed due to sync received or Delay-Resp received,
if it indicates a greater offset, TimeError takes the new value. Otherwise TimeError remains unchanged.
Based on the TimeError, a limited correction is made and subtracted from TimeError. Thus, a
measurement of the offset may take multiple corrections before it is completely corrected.
The second mechanism is less likely to make invalid corrections, but may exhibit longer periods without
corrections and be more likely to drift based on the error in the rate correction. Overall results are similar,
although the second mechanism appears to do better under heavy traffic conditions and multiple switches.
Since the second mechanism produced better results, the results section details those results.
3
Test Platform
The evaluation platform used for testing the clock servo algorithms is a custom FPGA-based evaluation
platform, Analog Launch Pad (ALP). The ALP platform includes a small FPGA that implements a MAC
interface, packet buffering, and MDIO management interface for communication with the DP83640
Ethernet physical layer device. The ALP board also includes a USB interface for communication with a
host PC. On the host PC, the ALP software runs the PTP protocol, handling building and parsing packets
and controlling operation of the PTP hardware in the PHY. The ALP platform incorporates logic and
connections to support two independent PHY devices.
The test platform does have limitations in packet and control throughput that limit the number of sync
cycles that may be handled. Synchronization works well up to eight per second, but cannot sustain a rate
beyond that. Since telecom and other applications require rates on the order of l00 sync messages per
second, this platform cannot provide synchronization on the same level that an embedded platform could
provide. Nothing in the DP83640 hardware should limit the device from working in the higher sync rate
environments. The limitations are specific to the evaluation platform.
The ALP platform provides a graphical user interface (GUI) and a scripting mechanism that supports the
Python scripting language. The testing was all done with the PTPv2 protocol and clock servo algorithms
running in Python through the ALP GUl.
For the simplest testing, the network consisted of a single HP Procurve switch. Additional traffic was
generated using a separate ALP platform set up to send broadcast traffic to the switch to provide a
specified percent utilization of the network. Testing was also done against a network consisting of three
switches between the Master and Slave.
The PTP Master used an OCXO as its reference clock source. The PTP Slave used an inexpensive TCXO
reference.
SNLA116A – May 2009 – Revised April 2013
Submit Documentation Feedback
AN-1963 IEEE 1588 Synchronization Over Standard Networks Using the
DP83640
Copyright © 2009–2013, Texas Instruments Incorporated
5
Test Results
www.ti.com
MASTER
DP83640
PC
Running USB ALP Platform
ALP
Software
Network
SLAVE PPS
DP83640
Traffic
Generator
Figure 4. Test Platform
4
Test Results
The proposed algorithm was used to test performance through a single switch or multiple switches with
traffic loads of up to 80%. The Master was set to send eight sync messages per second, while the Slave
would send a Delay-Resp message for every sync message. Traffic loading was generated using random
size broadcast packets and varying inter-packet gap to generate the specified amount of traffic. The traffic
was inserted at an available port on a switch in the test network. Time error data was captured using the
Event Timestamp capability of the DPB3640 PTP Master and saved for evaluation. In addition to
computing standard deviation, MTIE and time deviation (TDEV) plots were generated for each traffic
condition. Test durations were a minimum of 4 hours and a maximum of 8 hours.
4.1
Single Switch Results
Figure 5 and Figure 6 show the MTIE and TDEV results for a single switch at 20%, 50%, and 80% traffic
loading. In addition to the measured results, the plots also show two masks from telecom specifications.
The results easily meet the G.823 requirements for the PDH interface, but do not quite meet the G.811
PRC requirements. Further optimization, especially higher sync rates, would be required to meet the PRC
requirements.
Table 1. PPS Results For Single Switch Tests
6
Traffic (% utilization)
Std Dev
20%
13.9 ns
50%
15.7 ns
80%
28.0 ns
AN-1963 IEEE 1588 Synchronization Over Standard Networks Using the
DP83640
Copyright © 2009–2013, Texas Instruments Incorporated
SNLA116A – May 2009 – Revised April 2013
Submit Documentation Feedback
Test Results
www.ti.com
10000
G.823 PDH
MTIE (ns)
1000
80%
50%
100
10
20%
G.811 PRC
1
1
10
100
1000
10000 100000
OBSERVATION INTERVAL (ns)
Figure 5. MTIE Plot for One Switch Tests
1000
TDEV (ns)
100
G.823 PDH
G.811 PRC
10
80%
50%
20%
1
1
10
100
1000
10000
OBSERVATION INTERVAL (ns)
Figure 6. TDEV Plot for One Switch Tests
4.2
Multiple Switch Testing
Testing was also done with a three switch network consisting of a DLink DES1105 5-port switch, a Linksys
SD205 5-port switch, and an HP Procurve 8000M switch. Tests were made at 20% and 50% utilization
across all three switches, with the traffic injected at the third switch. As expected, the results were not as
good as for a single switch, but still show potential to meet the specifications shown. Figure 7 and Figure 8
show the MTIE and TDEV results for the different traffic conditions.
Table 2. PPS Results for Three Switch Tests
Traffic (% utilization)
Std Dev
20%
40.2 ns
50%
86.8 ns
SNLA116A – May 2009 – Revised April 2013
Submit Documentation Feedback
AN-1963 IEEE 1588 Synchronization Over Standard Networks Using the
DP83640
Copyright © 2009–2013, Texas Instruments Incorporated
7
Additional Opportunities
www.ti.com
10000
G.823 PDH
50%
1000
MTIE (ns)
20%
100
10
1
1
G.811 PRC
10
100
1000
10000 100000
OBSERVATION INTERVAL (ns)
Figure 7. MTIE Plot for Three Switch Tests
1000
G.823 PDH
TDEV (ns)
100
50%
10
20%
G.811 PRC
1
1
10
100
1000
10000
OBSERVATION INTERVAL (ns)
Figure 8. TDEV Plot for Three Switch Tests
4.3
Other Testing Results
Although no specific results have been captured, the algorithm appears to respond well to changes in
traffic volume within the 0% to 80% range. Beyond 80%, the algorithm still requires some refinement to
cope with significantly fewer minimum delay packets.
5
Additional Opportunities
While this document describes a working algorithm, there are many possibilities for future development to
improve and test the algorithms. The following lists some of the possibilities.
8
AN-1963 IEEE 1588 Synchronization Over Standard Networks Using the
DP83640
Copyright © 2009–2013, Texas Instruments Incorporated
SNLA116A – May 2009 – Revised April 2013
Submit Documentation Feedback
Conclusions
www.ti.com
Increase Synchronization Rate. Increasing the synchronization rate requires moving to a platform that
can support a higher packet rate, possibly up to 100 syncs/second or more. This would probably require
moving to an embedded platform such as the Freescale MCF5234BCCKIT Coldfire platform. Doing this
also allows many improvements to the algorithm such as making many delay measurements for each rate
or time correction.
Improved Rate Adaption. Some of the largest errors are due to slow response of the algorithm to track
changes in frequency of the local oscillator. An improved algorithm to track the rate and make adjustments
should improve the overall results.
Testing with Larger Networks. Extend testing to larger networks with more realistic traffic conditions.
Test with VLAN tags. Enabling VLAN tags and allowing for IEEE 802.1Q priority handling of PTP packets
based on the VLAN priority field could yield improvements in the results.
6
Conclusions
This document describes an algorithm for using the DP83640 Ethernet physical layer device to
synchronize clocks across a network with non-IEEE1588 capable devices. The algorithm was not
designed as a complete solution across all conditions, but is intended to show the feasibility of such a
solution. With only 8 sync messages per second, the system was able to accurately synchronize across a
single heavily loaded switch. With a greater sync message rate, it is expected that the algorithm will work
to a much higher degree of accuracy across larger networks.
7
References
•
•
•
•
IEEE Standard for a Precision Clock Synchronization Protocol for Networked Measurement and
Control Systems (2008), Institute of Electrical and Electronics Engineers, Inc.
DP83640 Precision PHYTER - IEEE® 1588 Precision Time Protocol Transceiver (SNOSAY8)
Texas Instruments Ethernet PHYTER Software Development Guide
MCF3254BCCKIT: MCF5234 Business Card Controller With lEEE1588 precision Time Protocol Freescale Semiconductor
http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=M5234BCCKIT
SNLA116A – May 2009 – Revised April 2013
Submit Documentation Feedback
AN-1963 IEEE 1588 Synchronization Over Standard Networks Using the
DP83640
Copyright © 2009–2013, Texas Instruments Incorporated
9
IMPORTANT NOTICE
Texas Instruments Incorporated and its subsidiaries (TI) reserve the right to make corrections, enhancements, improvements and other
changes to its semiconductor products and services per JESD46, latest issue, and to discontinue any product or service per JESD48, latest
issue. Buyers should obtain the latest relevant information before placing orders and should verify that such information is current and
complete. All semiconductor products (also referred to herein as “components”) are sold subject to TI’s terms and conditions of sale
supplied at the time of order acknowledgment.
TI warrants performance of its components to the specifications applicable at the time of sale, in accordance with the warranty in TI’s terms
and conditions of sale of semiconductor products. Testing and other quality control techniques are used to the extent TI deems necessary
to support this warranty. Except where mandated by applicable law, testing of all parameters of each component is not necessarily
performed.
TI assumes no liability for applications assistance or the design of Buyers’ products. Buyers are responsible for their products and
applications using TI components. To minimize the risks associated with Buyers’ products and applications, Buyers should provide
adequate design and operating safeguards.
TI does not warrant or represent that any license, either express or implied, is granted under any patent right, copyright, mask work right, or
other intellectual property right relating to any combination, machine, or process in which TI components or services are used. Information
published by TI regarding third-party products or services does not constitute a license to use such products or services or a warranty or
endorsement thereof. Use of such information may require a license from a third party under the patents or other intellectual property of the
third party, or a license from TI under the patents or other intellectual property of TI.
Reproduction of significant portions of TI information in TI data books or data sheets is permissible only if reproduction is without alteration
and is accompanied by all associated warranties, conditions, limitations, and notices. TI is not responsible or liable for such altered
documentation. Information of third parties may be subject to additional restrictions.
Resale of TI components or services with statements different from or beyond the parameters stated by TI for that component or service
voids all express and any implied warranties for the associated TI component or service and is an unfair and deceptive business practice.
TI is not responsible or liable for any such statements.
Buyer acknowledges and agrees that it is solely responsible for compliance with all legal, regulatory and safety-related requirements
concerning its products, and any use of TI components in its applications, notwithstanding any applications-related information or support
that may be provided by TI. Buyer represents and agrees that it has all the necessary expertise to create and implement safeguards which
anticipate dangerous consequences of failures, monitor failures and their consequences, lessen the likelihood of failures that might cause
harm and take appropriate remedial actions. Buyer will fully indemnify TI and its representatives against any damages arising out of the use
of any TI components in safety-critical applications.
In some cases, TI components may be promoted specifically to facilitate safety-related applications. With such components, TI’s goal is to
help enable customers to design and create their own end-product solutions that meet applicable functional safety standards and
requirements. Nonetheless, such components are subject to these terms.
No TI components are authorized for use in FDA Class III (or similar life-critical medical equipment) unless authorized officers of the parties
have executed a special agreement specifically governing such use.
Only those TI components which TI has specifically designated as military grade or “enhanced plastic” are designed and intended for use in
military/aerospace applications or environments. Buyer acknowledges and agrees that any military or aerospace use of TI components
which have not been so designated is solely at the Buyer's risk, and that Buyer is solely responsible for compliance with all legal and
regulatory requirements in connection with such use.
TI has specifically designated certain components as meeting ISO/TS16949 requirements, mainly for automotive use. In any case of use of
non-designated products, TI will not be responsible for any failure to meet ISO/TS16949.
Products
Applications
Audio
www.ti.com/audio
Automotive and Transportation
www.ti.com/automotive
Amplifiers
amplifier.ti.com
Communications and Telecom
www.ti.com/communications
Data Converters
dataconverter.ti.com
Computers and Peripherals
www.ti.com/computers
DLP® Products
www.dlp.com
Consumer Electronics
www.ti.com/consumer-apps
DSP
dsp.ti.com
Energy and Lighting
www.ti.com/energy
Clocks and Timers
www.ti.com/clocks
Industrial
www.ti.com/industrial
Interface
interface.ti.com
Medical
www.ti.com/medical
Logic
logic.ti.com
Security
www.ti.com/security
Power Mgmt
power.ti.com
Space, Avionics and Defense
www.ti.com/space-avionics-defense
Microcontrollers
microcontroller.ti.com
Video and Imaging
www.ti.com/video
RFID
www.ti-rfid.com
OMAP Applications Processors
www.ti.com/omap
TI E2E Community
e2e.ti.com
Wireless Connectivity
www.ti.com/wirelessconnectivity
Mailing Address: Texas Instruments, Post Office Box 655303, Dallas, Texas 75265
Copyright © 2013, Texas Instruments Incorporated
Was this manual useful for you? yes no
Thank you for your participation!

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project

Download PDF

advertising