On Wed, Jun 21, 2017 at 07:57:21PM +0200, Boris Boucher wrote: > The problem is, if the grand master is lost (power failure, network > issue....), my boundary > clock promotes itself as grand master, and uses its own knowledge of the > UTC offset instead > of the last known offset from the secure sync, and this cause a 1s step on > the UTC time !
Your are correct. After the GM goes away, the ptp4l program does not remember the UTC offset learned as a slave. It makes sense that we should store the learned value in this case. > Looking at the documentation, I can't find any way of updating the UTC > offset of the SERVER in a simple > manner. You can set the UTC offset at run time using the GRANDMASTER_SETTINGS_NP management message. > What are my options ? The best solution is to patch the program to store the UTC offset from the GM, provided that the currentUtcOffsetValid is set. One work around that you could use without patching is to monitor the status (by scripting the pmc program, for example) using GET GRANDMASTER_SETTINGS_NP. Then, when currentUtcOffsetValid = 1, write the value of currentUtcOffset back into ptp4l using SET GRANDMASTER_SETTINGS_NP. 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
