In our latest webinar, featuring Arista’s Gerard Phillips and Leader’s Steve Holmes and Kevin Salvidge we answered your questions on PTP and simple SMPTE ST 2110 deployments. Based on their real-world experience, Gerard, Steve and Kevin shared their thoughts on best design configuration and how to avoid the most common pitfalls.
Here’s some of the questions the team was asked prior to, and during the webinar, and their helpful responses.
- How do I integrate an IP infrastructure into an existing SDI infrastructure and ensure both systems are synchronized?
Having both your BB/TLS and PTP coming from the same SPG is essential. That way, they are both synchronized to GPS reference. If GPS reference is lost, both revert to ‘stay-in-sync’ using the internal oscillator. When GPS returns, both will also deploy a ‘slow-sync’ to revert back to GPS synchronization without causing severe shock to both BB/TLS and PTP reference signals.
Key points to consider:
- Single Oscillator: All reference signals, including black and burst, PTP, test signals, and AES, should be derived from a single oscillator, preferably oven-controlled for enhanced stability.
- Redundancy: Employ redundant grandmasters and a robust PTP architecture to ensure continued operation in case of equipment failures.
- Monitoring: Continuously monitor both SDI and PTP signals to detect any discrepancies or drift, allowing for timely corrective actions.
- How do I ensure that both PTP and BB/TLS are coming from the same SPG?
As the PTP reference sources do not pass through the Emergency Changeover units, if the system isn’t designed correctly, it is possible to end up with BB/TLS references coming from one SPG and PTP coming from another.
We discuss this in detail in the attached video.
- Why’s it important to design my system with more than one SPG?
As broadcast engineers we design systems to handle the most unexpected failure at the most inopportune moment. It’s recommended to have a minimum of two SPG’s to cater for a significant system failure.
- Can the Best Master Clock Algorithm (BMCA) work with multiple manufacturers’ SPGs?
Yes, the BMCA is SPG manufacturer agnostic, so this means you can have a mixed manufacturer environment. This can prove beneficial if one manufacturer issues a ‘severe’ service upgrade, that requires the SPG’s to be power-cycled or taken down for maintenance updates. Having a mixed-manufacturer environment will mean that your BB/TLS and PTP references are still available.
- What’s the most common system design error when it comes to PTP?
One of the most common errors is forgetting to change the default PTP domain from 127. Almost all PTP devices are shipped with this domain, and if you add a new device with the same domain, it can become the grandmaster and disrupt your entire network. Additionally, avoid using domain 0 as it is reserved for AES67 and Dante audio domains.
Other common errors include:
- Not following best practices: Leverage industry-standard PTP architectures to avoid reinventing the wheel and encountering known issues.
- Mismatched announce message intervals: Ensure these intervals match between the follower and leader devices for proper PTP operation. If not correctly setup, this can result in the BMCA selecting a new Grandmaster, not because the original Grandmaster has gone off-line, but simply because it has not responded in the Announce time-out’ window. This can cause the Grandmaster to ‘toggle’ between devices and cause ‘Quality of service’ issue with PTP reference across the entire IP broadcast system.
- Improper understanding of PTP priorities: Configure priorities correctly, especially priority 1, to guarantee the desired devices take over as grandmaster in case of failures.
- What is best practice for implementing BMCA within a multi-layered environment?
It is recommended within PTP best practice that the BMCA is operating at the Distribution Layer and not the Media-Spine or Media-Leaf layer.
You can also use ‘ptp role master’ to prevent unwanted hosts from being selected as the Grandmaster by the BMCA.
- Should I use a boundary clock or a transparent clock for my PTP network?
In most cases, boundary clocks are preferable over transparent clocks. Both minimize jitter, but boundary clocks offer several advantages:
- Scalability: They divide a large network into smaller, manageable segments, preventing grandmasters from being overwhelmed by numerous endpoints.
- Security: Features like PTP Roll Master enhance security by allowing only authorized grandmasters to become leaders.
- Visibility: Boundary clocks offer better telemetry and visibility into network performance, making it easier to monitor PTP health.
However, keep in mind that many endpoints support end-to-end delay measurement, not peer-to-peer, as used with transparent clocks. Therefore, you’ll likely end up with an end-to-end architecture at the access layer regardless of your choice.
- Should I use the same PTP clock for both my primary and backup 2110 networks?
Yes, it’s highly recommended to use the same PTP clock for both your primary and backup networks. Using different clocks can lead to synchronization issues due to the packet picker mechanism in receivers.
Receivers typically lock to a single domain and MAC address. If your networks have different PTP domains, the receiver constantly switches between domains and MAC addresses, potentially causing it to re-lock repeatedly, disrupting signal flow.
Even if the domains are the same but the clocks are different, there’s no guarantee endpoints will lock to the best clock, leading to potential timing discrepancies and network instability.
- How can I monitor PTP on every boundary clock in my network?
There are several ways to monitor PTP on boundary clocks:
- Switch Telemetry: Modern PTP-aware switches like those from Arista offer extensive telemetry data that can be used to monitor boundary clock performance. This data can include offset from master, network latency, packet counts, and drop rates.
- Dedicated Monitoring Tools: Tools like Leader ZEN series, PHABRIX QX series, and software solutions like DataMiner can collect, analyze, and visualize PTP data from switches and endpoints, providing a comprehensive view of network health.
- Open Source Tools: Tools like Grafana can be used to create custom dashboards for visualizing PTP telemetry data, providing a cost-effective monitoring solution.
- Is GPS always necessary for temporary SMPTE ST 2110 deployments?
No, GPS is not always necessary for temporary deployments. While GPS provides the most accurate time reference (clock class 6), grandmasters can also operate reliably using their internal oscillators (clock class 248). This might be necessary in locations where obtaining a GPS lock is challenging.
The internal oscillator in a grandmaster is typically an oven-controlled crystal oscillator, providing sufficient accuracy for short-term deployments. While not as accurate as GPS, it offers a stable and reliable timing reference without relying on external signals.