Re: [Ntp] An NTPv5 design sketch

[Miroslav Lichvar <[e-mail]>]

On Thu, Apr 16, 2020 at 01:34:03PM -0400, Daniel Franke wrote:
> At any rate, I second Doug Arnold that if a use case is
> already well-served by PTP, then complicating NTPv5 on their behalf is
> not solving anyone's problem.

I think PTP and NTP have different goals, but overlapping use cases.

PTP is basically NTP in broadcast mode, where the protocol is designed
for hardware support to be as easy as possible. NTP may be more
difficult to support in hardware, but if it could be supported, I
think in many cases it would be preferred over PTP.

A use case where the broadcast design of PTP is an issue (and where
NTP would be preferred) is synchronization in large networks where both
multicast and boundary clocks need to be avoided (e.g. to avoid long
chains of servos). The unicast mode of PTP requires a client-specific
state, which is an issue with larger numbers of clients (it's not
unusual for GM clocks to support only 2048 clients or less), and there
is also an issue that it has practically an infinite amplification
factor, so the access needs to be carefully controlled.

-- 
Miroslav Lichvar