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. -- Miroslav Lichvar _______________________________________________ Linuxptp-users mailing list Linuxptp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-users
