On Thu, Oct 14, 2021 at 09:44:21AM +0200, Miroslav Lichvar wrote: > On Wed, Oct 13, 2021 at 08:37:27PM +0300, Vladimir Oltean wrote: > > The other topic is how to actually wait for phc2sys to synchronize, > > since the program presented here only works with ptp4l (or at least > > that's all I tested). > > If it is the system clock, phc2sys clears the STA_UNSYNC flag > (which is reported by ntp_gettime()/ntp_adjtime()) when the servo is > in the locked state. There is the esterror (and potentially also > maxerror) field, which could be set by ptp4l/phc2sys to some estimate > of the error. Any application could easily check the value to decide > if the clock is good enough for its purposes. No need to implement PTP > or have access to the ptp4l/phc2sys socket. > > I think it would be great if all PTP clocks had this status and > esterror/maxerror fields. For example, with the ptp_kvm driver guests > have access to the system clock of the host as a PHC, but there is no > way to check if/how well the clock is actually synchronized. > > I had this on my todo list for a long time, but wasn't able to look > into it yet.
If I look at the struct timex definition from "man adjtimex", I see that both maxerror and esterror are expressed in microseconds (i.e. STA_NANO does not affect them), is that right? If so, I would need nanosecond resolution to determine whether phc2sys is synchronized well enough. If I'm wrong, could you please consider sending a patch to make phc2sys report the esterror and maxerror values to the kernel? _______________________________________________ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
