On Sun, Nov 07, 2021 at 04:22:52PM +0200, Vladimir Oltean wrote: > On Sun, Nov 07, 2021 at 04:19:55PM +0200, Vladimir Oltean wrote: > > On Sun, Nov 07, 2021 at 05:55:43AM -0800, Richard Cochran wrote: > > > On Sun, Nov 07, 2021 at 01:32:59PM +0200, Vladimir Oltean wrote: > > > > 1. ptp4l in the role of a GM appears to listen for > > > > GRANDMASTER_SETTINGS_NP > > > > PTP management messages on the local r/w UDS socket and that's how it > > > > updates its ANNOUNCE message contents. Who is supposed to construct > > > > and > > > > send these PTP management messages to the ptp4l GM in a "normal" > > > > system? > > > > > > This role must be taken by an outside program. For example, I wrote a > > > shell script to do this for a GM that always has the correct UTC offset. > > > > What is the role that this outside program supposed to have, apart from > > establishing that the UTC time is traceable? Trying to figure out > > Sorry, unfinished phrase. Trying to figure out what it would take for > that program to be written and be usable in a more general sense. > I've no problem in setting up my application to set the CLOCK_TAI offset > by itself when it detects that phc2sys and ptp4l didn't commit what > they're working with to the kernel. But I'm not sure whether that may > clash with what other parts of the system may have in mind.
The only role of this program would be to configure ptp4l with the correct values found in: * GRANDMASTER_SETTINGS_NP # values used when nodes becomes the GM # SET action useful for GPS time server clockClass 248 clockAccuracy 0xfe offsetScaledLogVariance 0xffff currentUtcOffset 35 leap61 0 leap59 0 currentUtcOffsetValid 0 ptpTimescale 0 timeTraceable 0 frequencyTraceable 0 timeSource 0xa0 These are used by ptp4l when becoming the GM. If the values are static and never change, then the task is simple and can be done with a shell script that invokes pmc. - You can set currentUtcOffsetValid, ptpTimescale, timeTraceable, and frequencyTraceable all to "true". - If you don't care about a globally correct currentUtcOffset, then you can simply set it to the latest value from the leapseconds file (or anything at all, really). Use the same value to set the local kernel UTC offset on boot. Unfortunately no standard utility does this, but I have adapted one to allow this: https://github.com/richardcochran/ntpclient-2015 FWIW, the only other program I know of that sets the kernel TAI offset is ntpd (not sure about chrony and systemd). ntpd takes a long, LONG time to actually set the offset after cold boot. > > I'm asking about linuxptp being used to synchronize the CLOCK_TAI on two > > back-to-back systems. I couldn't care less about traceability to UTC, or > > about who is GM for that matter. I just want that when I read CLOCK_TAI > > on a system where phc2sys synchronizes CLOCK_REALTIME to a PHC, or the > > other way around, the offset between CLOCK_TAI and the PHC to converge > > to zero. In this use case, you need only set GRANDMASTER_SETTINGS_NP once after ptp4l start up. HTH, Richard _______________________________________________ Linuxptp-users mailing list Linuxptp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-users
