Hi Miroslav, On Tue, Mar 29, 2022 at 09:10:59AM +0200, Miroslav Lichvar wrote: > On Fri, Mar 25, 2022 at 02:45:04AM +0200, Vladimir Oltean wrote: > > In general, we all seem to agree that the initial PTP time is largely > > irrelevant until you start looking at it for some particular reason > > (debugging). Or at least, almost everyone seems to agree. I remember > > Miroslav Lichvar argued that an initial offset of 37 seconds is somehow > > better than an initial offset from 1970 from 2022 because of the smaller > > clock jump? I admit I didn't quite get that. > > The way I see it is that an offset of 37 seconds is about 44 million > times better than an offset of 52 years. A smaller offset is easier to > comprehend for humans. It allows tighter sanity checks to be enabled. > > For example, it would work with the default panic threshold of 1000 > seconds in ntpd. The fact that ptp4l doesn't have such a sanity check > doesn't mean that nobody cares about things like that. If a TLS-based > authentication mechanism is implemented in ptp4l, it won't be able to > use the PTP clock to check validify of certificates. > > I don't see a reason why a PHC should intentionally be set to > completely bogus time. Clocks are never perfectly accurate. It's > always about minimizing the error. If the network drivers can improve > the initial error by 8 orders of magnitude simply by starting at > the current system time, then I think that is what should be done. > > The system clock is set from the RTC, even though RTC is not > synchronized to anything. If you turn off your computer for a month, > you will likely start with an offset similar to those 37 seconds. I > don't remember seeing anyone proposing that we should stop using RTC > for the initial setting because the clock will be corrected later by > NTP/PTP.
My opinion below may be wrong partly due to poor judgement and partly due to ignorance, and I don't mean to second guess you. My knowledge of the details of NTP is sub-par even as a user, yet I'm still saying what I'm about to say, hoping that Cunningham's law will do its job and make me learn something. 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. 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. You then use the purpose for which NTP exists to justify why the kernel should make a PTP timer behave exactly like it. 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. 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. 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? 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 suppose you could counter my argument by insisting more on the idea that "an offset of 37 seconds is about 44 million times better than an offset of 52 years". _______________________________________________ Linuxptp-users mailing list Linuxptp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-users
