32NF-80 DG Report. ST 2059 PTP Interoperability Testing and Demonstrations. Jack Douglass, Packetstorm Communications Chair 32NF-80 DG June 2018

Transcription

1 32NF-80 DG Report ST 2059 PTP Interoperability Testing and Demonstrations Jack Douglass, Packetstorm Communications Chair 32NF-80 DG June 2018

2 Topics Coved by Report Results from the SMPTE 32NF80-DG Dirty Hands Interop February 5 to 9, 2018

3 March SMPTE Interop Location: Fox NE&O Houston, TX Dates: February 5 to 9, 2018 Participating Companies: Arista, Bridge, Cisco, EEG, Evertz, Grass Valley, Imagine, IRT, Meinberg, Mellanox, Nevion, Oregano, PacketStorm, Ross, Seiko, Sony, Tektronix

4 February SMPTE PTP Interop Fox NE&O

5 February SMPTE PTP Interop Fox NE&O

6 February SMPTE PTP Interop Fox NE&O

7 Objectives of February Interop Event Allow new participants to test compatibility including mixed mode and unicast Re-test lock-up time and stability Verify ability of a slave to generate time code using TLV Investigate limits to scalability and develop recommendations for large systems Investigate PTP operation in ST networks

8 Summary Tests from February SMPTE Interop Transport Mechanism Multicast Mixed Mode Unicast Delay messaging Lock up Time and Phase AES-R16 message rates and ST 2059 defaults Start test by changing domain / grandmaster Start test by connecting to the network ST System Developed recommendations for end device and system behaviour of ST 2059/2110 over a ST network Network failure testing and analysis Time Code Generation from TLV Slave uses management message to create timecode Compared timecode between master and slave Tested a variety of Jam conditions Large System Test Non-PTP Aware network Leaf / Spine topology Load test with slave simulator Varied communication mode

9 Basic Compatibility and Transport Mechanisms Test Verified ability of slaves to lock to master at AES-R16 rates Seven masters and eleven slaves participated one master and five slaves were new so explicitly testing compatibility In multicast mode: All the slaves were able to lock to the new master All the new slaves were able to lock to all the masters except for one combination of master/slave. One master/slave combination had a 3us offset In mixed mode (unicast delay messaging): Three new slaves were able to lock to all the masters, with two master/slave pair exceptions. Five of the eight remaining slaves also supported mixed mode and locked to most masters One master sent multicast responses instead of unicast One master/slave combination had a 3.8us offset Most masters can simultaneously support both of these modes

10 Lock Time Test Setup (1) Test performed using AES-16 message rates Sync 8/s, Announce 1/s Some tests were repeated with higher Announce rates (4/s) Two PTP Grandmasters (GM1, GM2) set to different Time of Day (ToD) and clock rates Offset more than 1 second, frequency offset 10ppm GM1 active, GM2 passive using different clock classes Procedure All Slaves synchronized to GM1, with a settling time of several minutes GM1 disconnected => start time of the measurement. GM2 will take over after the Announce timeout. (i.e. either after 3 seconds or 750ms) The devices under test will to lock to GM2. Device is considered locked, if offset reported by the device remains within +/- 1µs Didn t have 1pps signal available on some devices

11 Alternate Lock time measurement was tested Lock Time Test Setup (2) Two Grandmasters operating on different PTP Domains Set to a different time more than 1s Frequency offset 10ppm Procedure Device locked to GM1 Device was unplugged and the domain was changed Device was re-plugged => Start time of measurement Device is considered locked, if offset reported by the device remains within +/- 1µs Test repeated using different Switch devices (3 vendors) Switch Set-up Spanning Tree in port fast mode, pure Layer 2 forwarding, IGMP query interval 1s Switch architecture / configuration may have immense impact on lock time Spanning tree protocol causes 30s delay for every node (listening and learning state) Disabled via port fast mode

12 Seconds Lock Time Master Switching (1) Lock Time with 1 Announce Msg per Second and 8 Sync Msgs per Second, Test repeated three times Test1 Test2 Test Device 1 Device 2 Device 3 Device 4 Device 5 Device 6 Device 7 Device 8 Device 9 Device 10

13 Seconds Lock Time Master Switching (2) Lock Time with 4 Announce Msgs per Second and 8 Sync Msgs per Second, Test repeated three times Test1 Test2 Test Device 1 Device 2 Device 3 Device 4 Device 5 Device 6 Device 7 Device 8 Device 9 Device 10

14 Lock Time Master Switching (3) Lock Time Comparison with Respect to Announce Message Rate (Average Lock Time) 80 Announce Rate 1/s Announce Rate 4/s Device 1 Device 2 Device 3 Device 4 Device 5 Device 6 Device 7 Device 8 Device 9 Device 10

15 Lock time with unplug/re-plug of Slave Lock time with unplug/plug switch vendor 1 (Announce Rate of 1/s), Test repeated three times 90 Test 1 Test 2 Test Device 1 Device 2 Device 3 Device 4 Device 5 Device 6 Device 7 Device 8 Device 9

16 Lock time with unplug/plug of Slave Lock time with unplug/plug switch vendor 2 (Announce Rate 1/s), Test repeated three times Device 3 Device 4 Device 6 Device 8

17 Lock time with unplug/plug of Slave Lock time with unplug/plug switch vendor 3 (Using Announce Rate of 4/s), Test repeated three times Test 1 Test 2 Test Device 4 Device 5 Device 6 Device 7 Device 8 Device 9

18 Lock time with unplug/plug of Slave Lock Time Comparison with Respect to Switch Vendor (Average Lock time per Switch Vendor) 90 Vendor 1 Vendor 2 Vendor Device 1 Device 2 Device 3 Device 4 Device 5 Device 6 Device 7 Device 8 Device 9

19 Lock Time Conclusions Short lock times are feasible using AES-R16 event message rates, in some cases decreasing the Announce rate increased the lock time as expected, in other cases the effect was unclear Lock time measurement is problematic A single lock time measure method has not been identified Precise timing signals (e.g. 1PPS) are not accessible from all devices Different methods (Master switch vs. plugging) produced significantly different results It is not clear which portion of PTP process is included in the lock time Network may have a major impact on lock time (e.g. spanning tree portfast)

20 Lock Time Recommendations (1) Current wording in ST too unspecific and ambiguous A proper procedure requires a lengthy and detailed explanation Proposal Remove description in ST and move to a separate document New document needs to include: Precise definition of Start and End events E.g. Start event is hot plugging to switch E.g. End is based on internal time counter? Device output? Network and switch configurations options Impact the network and switch configurations has on lock time E.g. spanning tree portfast mode

21 Lock Time Recommendations (2) New document needs to include (continued): Measurements methods for essence Tx and Rx devices Internal information a device needs to expose in order to allow Basic lock measurements Independent objective lock measurements Impact that PTP parameters have on lock time E.g. Sync of -7 vs -3. Announce of -2 vs 0 Default values Impact that network load and PDV/jitter have on lock time Impact that initial conditions have on lock time E.g. Device in holdover mode vs cold start How to optimize lock time

22 ST Testing and Conclusions We discussed end device and system requirements and behaviour of ST 2059/2110 over a ST network We tested a simple ST network configuration The tests created a single link failure at each point throughout the topology The results matched the expected behavior The expected behavior defined which master is the Grandmaster and the correct path from the slave to the Grandmaster Recommendations A new 2059 document needs to be created to document the behaviour of end devices and the system No standard changes were identified for ST and ST

23 ST 2059 Timecode Setup Master generates PTP plus TLV and SDI with Timecode burn-in Slave generates SDI with Timecode burn-in from PTP and TLV SDI monitors were compared photographically SDI latency may not be consistent Various test scenarios were evaluated

24 ST 2059 Timecode Test Parameters Frame Rate Color Frame Drop Frame Jam DST Off->On DST On->Off Leap Second Each Row is a test of a Jam Transition, master and slave timecodes were compared before and after the transition. Timecodes were also compared to an spreadsheet which predicted the values. This was vital to the process.

25 Required Data for Timecode Validation Item Comment Generated TC PTP Time Shooting video (or Taking picture) PTP Slave displays PTP Time in addition to TC value currentlocaloffset jumpseconds timeofnextjump Required to capture both BEFORE Jam event and AFTER Jam event. timeofpreviousjam previousjamlocaloffset

26 JAM Only 25fps Timecode from Master (Left) and Slave (Right) DST Off -> On DST On -> Off

27 JAM Only 30/1.001fps Timecode from Master (Left) and Slave (Right) DST Off -> On DST On -> Off

28 Example Timecode Results Frame Rate DF CF PTP Time Master Slave Predicted :50: :50: :50: / :00: :00: :00: :10: :10: :10: :30: :30: :30: / :40: :40: : :50: :50: :50:00.09

29 ST 2059 Timecode Conclusions Testing of the timecode before and after the jam transitions yielded good correlation between the master, the slave and the predicted result This test could benefit from some improvements in the testing methodology Direct measurement of the timecode is difficult Many timecode displays have uncertain and variable latency A tool to predict the timecode from the TLV and PTP time is invaluable It is necessary to perform additional testing of the transition cases with more vendor s products at future interops. This test was with one master and one slave. A reference PTP slave Timecode Generator would enable more widespread testing

30 ST 2059 Large Scale Systems Testing Objectives Goals: Test clocks with ~256 concurrent slaves (master, slave, boundary, transparent) Test multicast versus unicast delay messaging Observe impact on slave performance and lock times Expected Behavior: Some slaves may be overwhelmed with multicast delay messaging and unicast delay messages should eliminate this Boundary clock mode should eliminate churn if a link or GM fails with a large amount of slaves Boundary clock mode should eliminate slave and master messaging delay load with multicast mode Note: All tests run at default rates, E2E only, two tier network

31 ST 2059 Large Scale Systems Testing Tools Meinberg Protocol Simulator InMon sflow InMon sflow Endpoint Flow Matrix Meinberg (PTP) Protocol Simulator

32 ST 2059 Large Scale Systems Testing Results Exceeded the 250 Slave Goal Tested upwards of 500 simulated Slaves across multiple network interfaces (Spine / Leaf) 10 Grand Masters and 19 Slaves participated in the Large Scale System Testing Reached the limits of simulation test bed (1000 Slaves) Not all Grand Masters could handle greater than 256 Slaves at SMPTE default profile rate Whilst a majority of Slaves handled the load at 250, some failed at low counts Some slaves were able to operate with 1000 slaves active Tested both Unicast and Multicast Delay Messaging Network Load and Slave Distribution was sufficient not to impair Slave testing results

33 ST 2059 Large Scale Systems Conclusions Devices Under Test scaling capability varied significantly Unicast Delay Messaging Mode reduced overall load on the Slaves allowing all the Slaves to operate under normal conditions when running with 1000 slaves with unicast delay messaging.

34 Items Retained from the Previous State Of The Industry PTP is a suitable foundation for network synchronization Network considerations (BC, TC, QoS) are necessary to meet performance requirements in presence of traffic (such as a ST 2110 environment) Target stability of 1 us can be readily reached Legacy signals generated from ST meet alignment requirements Limited testing of full unicast communication mode

35 State Of The Industry Based on This Interop Depending on message rates the lock time target of 5 seconds is difficult (but possible) to achieve and measure With the current lock time definitions and measurement methodologies, slaves lock within 5s to 70s, but most below 30s Time Code from TLV still not broadly implemented, testing so far is encouraging Device support for mixed communication mode is becoming more common

36 Future Interop Opportunities Time Code with wider vendor participation and with additional test cases Interop in Europe Additional testing on Lock time for EG Test behavior of management messages passing through complex networks that use boundary clocks

37 Future Demonstration and Interop Schedule IBC Prestaging Event Tentatively week of August 20 th at Riedel in Wuppertal, Germany IBC Demonstration SMPTE ATC 2018