NTP vs PTP: Choosing Time Synchronisation for Networks

Milliseconds are enough for logs and certificates; microseconds are required for financial matching engines, 5G fronthaul and industrial control. Two protocols cover those needs - NTP and PTP - and choosing between them is about hardware more than software. This is the decision framework and the deployment details that matter.

Accuracy Reality Check

The headline mistake is deploying PTP in software mode and expecting it to beat NTP. Without timestamping in hardware, the accuracy difference collapses, and you have added complexity for nothing.

NTP: The Default That Everyone Still Needs

# Cisco IOS
ntp server 10.10.10.5 prefer
ntp server 10.10.10.6
ntp authenticate
ntp authentication-key 10 md5 <key>
ntp trusted-key 10
clock timezone UTC 0

# Linux server (chrony)
server 10.10.10.5 iburst
server 10.10.10.6 iburst
makestep 1.0 3
rtcsync

Practical points that prevent 90% of NTP problems:

• Configure at least two sources, and monitor show ntp status / chronyc sources rather than assuming.
• If the device has a management VRF, the NTP source must be reachable in the VRF where NTP runs. Half of all 'NTP is not syncing' tickets end here.
• Use an ACL restricting who may query or sync from your servers, and prefer authenticated NTP internally.
• Set the timezone to UTC on infrastructure and convert for display. Local-time devices produce logs that are ambiguous twice a year.

PTP: The Setup That Actually Delivers

# Juniper EX/QFX as boundary clock on an interface set
set protocols ptp clock-mode boundary
set protocols ptp slave interface ge-0/0/1.0
set protocols ptp master interface xe-0/0/2.0
set protocols ptp slave-to-master-delay
set protocols ptp priority1 128

# Linux (linuxptp) as a slave with hardware timestamping
ptp4l -i eth0 -f /etc/ptp4l.conf -m -s
phc2sys -s eth0 -c CLOCK_REALTIME -w -m

For PTP to be useful, three layers must cooperate:

1. The NIC. Hardware timestamping on the interface that receives PTP (ethtool -T eth0 shows whether it is available).
2. The switch path. PTP-aware switching: a boundary clock (switch terminates and re-generates PTP) or a transparent clock (switch measures and compensates residence time). A plain switch introduces variable queuing delay that destroys microsecond accuracy.
3. The architecture. One or two grandmasters with GNSS, a chain of boundary clocks, and monitoring for the servo state - an unlocked PTP slave should alert, not quietly drift.

Coexistence

Most networks run both: NTP everywhere as the baseline, PTP on the specific fabric, links or hosts that need it. Two practical interactions to plan for:

• Independent paths. Do not carry PTP over the same congested uplink you use for bulk data; PTP accuracy depends on consistent latency.
• Independent monitoring. Track offset and jitter for both. For NTP: ntpq -p, show ntp associations. For PTP: pmc -u -b 0 'GET TIME_STATUS_NP', and the switch's own PTP status commands.

When You Do Not Need PTP

If the requirement is log correlation, TLS, Kerberos or general audit - NTP with a couple of reliable servers and monitoring is the correct answer, and PTP would add cost and failure modes for no benefit. If the requirement is a legally-mandated timestamp resolution, or a system that measures latency in microseconds, PTP is not optional. Decide by requirement, not by enthusiasm.

Related reading: boundary clock vs transparent clock, TSN 802.1Qbv scheduling for the control-plane use case, and 华为交换机 NTP 时间同步配置.

原文链接：https://datatracker.ietf.org/doc/html/rfc5905