On Mon, Aug 20, 2018 at 01:28:25PM +0000, FUSTE Emmanuel wrote: > I think the big jump is because the PHC was stopped and completely reset > between a down/up sequence.
Right. The driver resets the time to the system time value (which is UTC). > Is it an expected behavior ? For ptp4l? Yes. For the ifdown/ifup of the driver? I would call it a driver bug. It is completely illogical that that bringing the interface down and up again would change the stored time. I have complained about this on netdev before, but to no avail. There drivers that do all of their bringup/teardown in their .open/close callbacks and *not* in the .probe/remove methods. It may be that the HW forces implementation in some cases. But in at least one case, where *I* wrote a perfectly adequate PHC driver that sets the clock exactly once, in probe/remove, the $corp developers when ahead and moved that into open/close. Brilliant. > Could we do something on the ptp4l side to > address this case ? Yes, you can use the 'step_threshold' option. Thanks, Richard ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Linuxptp-users mailing list Linuxptp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-users
