On Wed, Jun 28, 2017 at 11:08:04PM +0200, Boris Boucher wrote: > No, the CLIENTS are running ptpd.
Ok, then ptpd has a bug. It ignores the currentUtcOffsetValid member of the TIME_PROPERTIES data set. You will need to fix that in order to solve your start up problem, or you could instead work around it by setting the offset in the ptp4l configuration or in its command line. Looking at ptp4l, sending an incorrect currentUtcOffset with currentUtcOffsetValid=0 is technically not wrong, but I agree that we should retain the correct offset when provided by a GM, even after that GM disappears. I will review the ptp4l client behavior when using SW time stamps. Maybe there is a bug there as well. Thinking out loud, the rational for the current behavior is the common use case of an isolated LAN without any global time source. In this case, users don't care what the offset is. They simply want the nodes in the system to be synchronized to each other. 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
