On Wed, Mar 30, 2022 at 01:41:18AM +0300, Vladimir Oltean wrote: > I think your comparison between NTP and PTP is a bit flawed because they > serve different purposes, PTP being there for 'precise' synchronization > rather than following the time of day.
I don't think they are that different. But even if they were, I don't see why it would matter for the initialization of the PHC. PHCs are not used only for PTP. There are other protocols. It's just a confusing naming with the P in PHC standing for PTP. > This is true even to the extreme. There is a non-negligible amount of > systems that use PTP without any need whatsoever to track UTC, where > just local machine-to-machine sync is required. Whereas CLOCK_REALTIME > represents the machine's best guess of the current time of day. The same thing can be done with NTP. Isolated networks with no reference clocks are a common use case. > You then use the purpose for which NTP exists to justify why the kernel > should make a PTP timer behave exactly like it. The sanity limit is not specific to a protocol. It could be implemented in ptp4l and it would make it more resilient to some failures. > I admit I haven't studied PTP security to any extent, and I've come up > empty handed while searching for "certificate" in my copy of IEEE 1588. If NTS-KE is used in PTP, it will need to work with certifcates. Here is a draft: https://datatracker.ietf.org/doc/draft-langer-ntp-nts-for-ptp/ > But I wouldn't expect that ptp4l would use the PHC time to check > validity of certificates, for the simple reason that it has no reliable > guarantee that the PHC tracks the time of day even broadly, and that was > never a requirement it had. With how things currently are I agree that it would need to use the system clock, but it would be nice if it could follow the original idea of working with just one clock. > As for the panic threshold, again I admit deep-seated ignorance on the > topic, but my thinking is that maybe there is a reason why this threshold > is part of the actual RFC 5905 spec, while it has no direct equivalent > in IEEE 1588. In my view, this could be explained in the same note: > with PTP there is no expectation that the local clock tracks a particular > time source before it starts tracking the GM selected by BMCA. > Why do you think this is? The PTP spec doesn't say anything about clock control, so I'd not expect any suggestions about panic or other thresholds there. > To summarize, my belief is that the individual kernel drivers with good > intentions that write the current CLOCK_REALTIME value into the PHC were > written with the implicit assumption that user space would want to do > that later anyway. I think it is more important that the kernel consistently > enforces the message to users that the initial PHC time is unreliable > for the PTP protocol's purpose, rather than unreliably tries to bring > the PHC time closer to an imaginary target. I don't agree with that, but it's not a big deal for me. I'm just trying to point out that the magnitude of an acceptable clock error depends on the context. A clock being synchronized is not a boolean. An initial value coming from RTC->system clock->PHC can be perfectly fine in some use cases. -- Miroslav Lichvar _______________________________________________ Linuxptp-users mailing list Linuxptp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-users
