Re: [Linuxptp-users] [Linuxptp-devel] Observing below issue with ptp4l running in BC mode

[ramesh t <ram...@ya...>]

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 <mli...@re...> 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