Le 21/08/2018 à 14:32, Richard Cochran a écrit : > 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 > Thank you for the detailed explanation.
Emmanuel. ------------------------------------------------------------------------------ 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
