Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

NTP fundamentally cannot reach the same accuracy as PTP because Ethernet switches introduce jitter due to queueing delays and can report that in PTP but not NTP.


Chrony can do NTP encapsulated inside PTP packets so as to combine the best parts of both protocols


That's not exactly NTP though ;)

I'll also say PTP is superior since it syncs TAI rather than NTP's UTC. Which probably isn't going to change even with NTPv5.


chrony can be configured to encapsulate NTP messages in PTP messages (NTP over PTP) in order to get the delay corrections from switches working as one-step PTP transparent clocks. The current NTPv5 draft specifies an NTP-specific correction field, which switches could support in future if there was a demand for it.

The switches could also implement a proper HW-timestamping NTP server and client to provide an equivalent to a PTP boundary clock.

PTP was based on a broadcast/multicast model to reduce the message rate in order to simplify and reduce the cost of HW support. But that is no longer a concern with modern HW that can timestamp packets at very high rates, so the simpler unicast protocols like NTP and client-server PTP (CSPTP) currently developed by IEEE might be preferable to classic PTP for better security and other advantages.


With retail hardware, definitely, but there is boundary PTP support with enterprise gear.

For telco gear, there is PTP + SyncE.


Some NICs support hardware timestamping (though some only for PTP packets, looking at you, XL710).




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: