VIAVI TestCenter: Questions regarding 1588v2 emulation for clock synchronization.

Knowledge Base - FAQ

VIAVI TestCenter: Questions regarding 1588v2 emulation for clock synchronization.
Questions 1588v2 PTP clock synchronization • Are there any user manual for 1588 testing using STC with configuration details, including unicast? • Here is a link in our online help to get the information needed or it can be seen in the help function of the application as well. • http://kms.VIAVIcom.com/CSC/STC_WebHelp/WebHelp/Content/ce/1588v2/1588v2_oview.htm • Attached is also a "VIAVI Journal of Mobile Backhaul PASS Test Methodologies"  with some 1588v2 PTP use cases. • As for Description of each configurable field and results fields, we have the online help within the GUI itself. See snapshot below. • • Some items could have more detail to make it clearer but if there is a question to any information given, it can usually be answered by the 1588v2 specifications which is what we follow. • A demo of how to use 1588 emulation on STC for testing a DUT? • For this subject, configuring and starting the emulation is fairly simple, I believe the issue is about the results. • The results are taken from the messages received and calculated according to the specs. • If the question is about understanding what should be tested on the DUT, I can only point to the attached mobile backhaul document that may give you some ideas on what you wish to test. • Summary of current open issues regarding 1588v2 emulation. • 1588v2 over LAG • One-step mode large offset and delays • Slave Only mode stays in listening state if its configured priority is higher value than what is received from the master. • Support for PTP profiles and IEEE802.1AS (AES67 and SMTPE). • ​​Currently this is not supported.  • ​Are there any scale numbers for 1588v2 PTP? • ​​We have different scale number for different module type, please check with your Sales Team or Support person. • Example for DX and CV modules • DX-10G-S32 • Multicast @ 1pps - (Max  Slave @ msg rate=1pps) • Max 10 devices per port • Unicast – not supported (although it says here not supported, it does work on DX module but we have not test data for any scale) • Single Master (Max Msg Rate) • 1pps (log interval = 0) • CV-10G-S8 • Multicast @ 1pps - (Max  Slave @ msg rate=1pps) • Max 100 devices per port • Multicast @ 16pps - (Max  Slave @ msg rate=16pps) • Max 20 devices per port • Unicast @ 16pps - (Max  Slave @ msg rate=16pps) • Max 10 devices per port • Single Master (Max Msg Rate) • 16pps (log interval = -4) • Concerning the Time of Day displayed in the Clock Sync Results view • VIAVI as Master - ToD is updated after Sync is sent out (or before sending out FollowUp). • Reason being, the protocol needs to get the timing info of when Sync was sent out from the lower layers. • So it is updated after receiving the info from the lower layers, which is immediately after sending out the Sync message. • VIAVI as Slave - ToD is updated after receipt of a Delay_Response message from the Master. • Each slave calculates/receives its own copy of path delays, corrections and timestamp in FollowUp messages, this means each slave will display its own results unrelated to the other slaves. • ToD is not updated on each device at the same instance. • ToD on all the slave to be same is not practically possible. Since the nodes can’t be absolutely synchronized in reality • Why do I see large offset at start of the 1588v2 devices? • Since clocks are not sync'd yet, the start should show a large offset but once we see Master/Slave synchronization the results can be cleared to get the proper values. • Large offsets from master - The larger mean path delay when connected to the switch is causing larger offsets. • The mean path delays and offsets keep changing with the receipt of each FollowUp or DelayResponse message. • How to view results over time or exported to excel? • A graph that is updated about once a second can be created to show these values over time. Example below. • This graph can be saved in the Results Reporter then exported into a excel if needed. Attached is a sample db file that was saved as well as the exported excel file.  • To save the results, go to File->Save results which should also bring up the results in Results Reporter. • To export the graph to excel, just highlight the graph in the Results Reporter and select the spreadsheet icon near the top menu bar. • Graphical representation of the results for a period of time.  • • End to End data: at any given instance what is the time on all VIAVI PTP devices.  • We do not have this at the moment and will discuss with the VIAVI team for possible enhancement.​ 1588v2 PTP common questions ​​Q1: Why do I see year ‘1970’ in 1588 as ToD? A1: The date 1588 advertises is 1970 because the internal clock on a chassis starts at January 1, 1970 12:00:00 Midnight when it boots. This is the default unless the chassis is synchronized to some external source. The chassis’ time is passed to the cards when they boot. At present, there is no ability for the user to set the internal clock’s date/time unless an external synchronization source is used. This would have to be an enhancement to the TestCenter infrastructure.   Q2: How do we calculate ’Offset Value’ and Mean Path Delay? A2: The value in the Offset Value column is calculated according to section 11.2, page 109 of the IEEE 1588v2 specification. Basically, the calculation relies on the time the Sync packet arrived, the preciseOriginTimestamp field from the Follow_Up packet, the current meanPathDelay value, and the correctionFields from the Sync and Follow_Up packets. The value in the Mean Path Delay column is calculated according to section 11.3, pages 110-112 of the IEEE 1588v2 specification. That algorithm relies on the timing information from the Sync/Follow_Up packets and from the Delay_Req/Delay_Resp packets. Since the two values are calculated at different times, it is not surprising that they evince values in this fashion.   For example, offset is calculated as below for 1-step and 2-step clocks   Offset From Master Calculation formula (section 11.2, p. 109) a.If the clock is configured as a One Step Clock = ─ ─ ─ correctionField of Sync message. b.If the clock is configured as a Two Step Clock = ─ ─ ─ correctionField of Sync message ─ correctionField of Follow_Up message.   Q3: I see negative number in 1588 calculations for example the offset and mean path delay. A3: Negative numbers in 1588 calculations are not a bug. a.First, the TimeInterval data type (5.3.2, p. 12) is a signed value. This is the type mandated for offsetFromMaster (8.2.2.3, p. 68) and meanPathDelay (8.2.2.4, p. 68). b.Second, all clocks run at different speeds. Even two clocks, both running with a 1 Ghz oscillator, can run at different speeds. For instance, device #1’s and device #2’s 1 Ghz clocks are running with 1,000,000,000 ticks per second plus or minus 10 ticks. Calculated values between the clocks can result in negative values since each clock may tick between 999,999,990 – 1,000,000,010 each second. That’s why the standard allows for negative values. A negative value is not a problem. A large value, negative or positive, could indicate a problem. c.We plan to add time values t1, t2, t3 and t4 to the result so the customer can see the values that we use in our calculations. The timeframe for this feature is unknown at this point.    Q4:What units are the values in result table? A4: The numbers in the results are in nanoseconds.   Q5: How is the average mean path delay calculated? A5:  The average mean path delay is, of course, the sum of all calculated mean path delay values divided by the number of calculated values. Since all time values in 1588 are signed, it is possible for positive and negative values to cancel each other out to some extent. This will affect the resulting average. Perhaps this calculation should be done with absolute values instead.   Q6: Do I need to have the 1588 STC port and the DUT on the same subnet for the master and slave port to sync? A6: The DUTs I have used act like a switch – that is it will accept ANY 1588 packet that comes in to ports 319 or 320 as long as  it is on top of IPv4/UDP or IPv6/UDP. TestCenter accepts packets ONLY if they are on the same subnet as the interface – i.e., it acts like a router port.   Q7: Can 1588 run on 1000 series test modules? A7: Yes it will work on all modules BUT…There is an issue on ALL cards with gigabit interfaces. The default point where sent/received packets are time stamped is different. One is at the beginning of the packet and the other is at the end. This can be overcome by configuring traffic and selecting a common timestamp point (beginning or end) in the traffic configuration. When the configuration is applied, the new setting will override the default and the time stamp operation will be consistent.   Q8: During Master-Slave negotiation, we notice some inconsistencies with how the DUT and STC set the Two_STEP flag? Can you explain? A8: STC sets the twoStepFlag of the flagField according to section 13.3.2.6, Table 20 on page 126 of the IEEE 1588v2 specification. According to the table, for clocks configured for TWO_STEP operation, the twoStepFlag is set to TRUE in Sync and Pdelay_Resp packets only. otherwise the value is false. The Master/Slave election is performed using information from Announce packets. The ONE_STEP/TWO_STEP setting is not part of the Best Master Clock algorithm.   Q9: How to interpret ‘Log Announce Interval, Log Sync Interval and Log Minimum Delay Request’ values? A9: The Log Announce Interval, Log Sync Interval, and Log Minimum Delay Request Interval values are logarithmic values, base 2. They are NOT scalar values. Also, while the possible values are -127 to 128, the TestCenter protocol stack limits the computed time values between -8 and 12 inclusive. This provides a time range of 4ms to 4096 seconds. Examples: Log Value Scalar Value -3 128ms -2 256ms -1 512ms 0 1000ms 1 2000ms 2 4000ms 3 8000ms