hi Miroslav Lichvar, You are correct, "the timestamp checked in the clockcheck code should always be a timestamp of the clock synchronized by phc2sys"
In this case, we have connected testUnit to interface A. Interface A is providing clock to testUnit (with ptp4l in BC mode) and time is synchronized on PHC of interface A using phc2sys. Resetting of testUnit is triggering interface A to go down. This in turns is triggering PHC run at different frequency for small duration till interface is up. Though this is a driver issue on interface A, my question why is the below code required? > interval = (int64_t)ts - cc->last_ts; > if (interval >= 0 && interval < CHECK_MIN_INTERVAL) > return ret; Can't we just depend on CLOCK_MONOTONIC clock check? regards, Ramesh On Monday, January 24, 2022, 01:34:26 PM GMT+5:30, Miroslav Lichvar <mlich...@redhat.com> wrote: On Thu, Jan 20, 2022 at 06:11:57PM +0000, ramesh t via Linuxptp-users wrote: > In clockcheck_sample function, we should depend on CLOCK_MONOTONIC to decide > if its getting called more frequency than a second. But we also check on > remote time: > > interval = (int64_t)ts - cc->last_ts; > if (interval >= 0 && interval < CHECK_MIN_INTERVAL) > return ret; > > This may not be correct as remote phc time could have drifted. Hence when we > call clockcheck_sample again mono_interval may be a higher value, resulting > in variation of min and max freq_offset calculation. The timestamp checked in the clockcheck code should always be a timestamp of the clock synchronized by phc2sys, not the clock to which it is synchronized (what I assume you mean by "remote"). Can you point to the code path where this is not the case? -- Miroslav Lichvar _______________________________________________ Linuxptp-users mailing list Linuxptp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-users
