[Ntp] Antwort: Re: An NTPv5 design sketch<

[[e-mail]]

From my recent experience in evaluating and comparing different time transfer technologies for different use cases, I carefully agree with Miroslav.

Several differences between NTP and PTP are inherently polar opposites on parameters (such as the presumed level of support by involved hardware) that seem like they should be viewed as more of a spectrum.

Also, the fact that both protocols already come as pre-determined bundles of parameters (often offering the mentioned polar opposites) artificially creates a separation of use-cases.

Overall, I think three use cases are already well-served:

1) You absolutely need sub-millisecond performance AND you physically control the whole network AND have the resources to install massive amounts of expensive hardware (AND, if you need an absloute reference such as UTC, you have high-accuracy access to it at at least one point in your network),

2) You want to do your synchronization via the internet AND want to use non-specialized hardware AND you really only need tens-hundreds of milliseconds of accuracy guaranteed but are happy if you statistically mostly get three or four orders of magnitude better than that,

3) You need sub-millisecond (possibly sub-microsecond) accuracy AND you have access to an antenna with good reception AND you don't really worry about anyone jamming or spoofing your signal.

Everything else currently seems to require significant compromise and/or research and development.

While I think the points of avoiding featurism and re-inventing solutions for solved use-cases are perfectly valid, I also think it is worth to think about possible (new or unusual or just previously neglected) use-cases that slight variations of NTP could help solving.

Best regards,

Kristof

ntp" <[e-mail]> schrieb: -----

An: "Daniel Franke" <[e-mail]>
Von: "Miroslav Lichvar"
Gesendet von: "ntp"
Datum: 20.04.2020 14:45
Kopie: "NTP WG" <[e-mail]>
Betreff: Re: [Ntp] An NTPv5 design sketch

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

_______________________________________________
ntp mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ntp" rel="nofollow">https://www.ietf.org/mailman/listinfo/ntp