A transit operations center evaluates timing for signaling gear that needs sub-microsecond synchronization. Which IP services comparison is appropriate?
Select an answer to reveal the explanation.
Short Explanation
NTP is fine for lining up syslog; signaling gear that needs sub-microsecond accuracy wants PTP — different stopwatches for different jobs. HSRP hellos will not buy you precision time.
Full Explanation
A transit operations center timing signaling gear that needs sub-microsecond synchronization should compare services correctly: PTP (Precision Time Protocol) is designed for high-precision synchronization use cases, whereas NTP typically targets coarser alignment sufficient for logs and general infrastructure. Signaling that truly needs sub-microsecond accuracy is a PTP-class requirement, not an NTP-only design for municipal transit control.
Claiming NTP alone always guarantees sub-microsecond accuracy for all industrial signaling fails by concept—NTP’s typical accuracy is orders of magnitude coarser than sub-microsecond under normal IP networks. Saying PTP replaces Ethernet and cannot coexist with IP networks fails because PTP commonly runs over Ethernet/IP fabrics with boundary and transparent clocks. Meeting sub-microsecond needs only by increasing HSRP hello timers fails because HSRP hellos are FHRP keepalive timing, not precision time distribution for signaling gear.
Exam caveat: PTP still needs a proper clock topology, capable switches, and careful design; simply enabling PTP without boundary clocks and QoS may miss the accuracy target. ENCOR wants the NTP versus PTP use-case distinction clear.
Operational check: Identify which systems need only NTP (logs, general infra) versus PTP (signaling); deploy PTP where sub-microsecond is required; verify measured offset and path delay against the signaling SLA; keep NTP for broader device log alignment across the transit center.