On Mon, Nov 08, 2021 at 06:44:28AM -0800, Richard Cochran wrote:
> 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.
Thanks, I have some logic in my application too (this is a consumer of
CLOCK_TAI timers), that queries ptp4l's TIME_PROPERTIES_DATA_SET member
currentUtcOffset, and reads the kernel's CLOCK_TAI offset, and in case
they are different, it fixes up the kernel's offset. This logic can't be
too wrong, I figure.
> > > 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.
Actually no. As mentioned, if I set GRANDMASTER_SETTINGS_NP member
currentUtcOffsetValid=1 via management:
(a) I take the responsibility for claiming it is valid, which is
neither something that I need nor want
(b) I only solve the CLOCK_TAI offset problem for the slaves, not for
the GM system itself, since phc2sys updates the CLOCK_TAI offset
only if CLOCK_REALTIME is a slave clock.
So the only realistic option I see is to do what I ended up doing, as
long as there is no standard program that sets and forgets this value.
I am not actually sure whether phc2sys can/should set the CLOCK_TAI
offset on a system where ptp4l is a GM. That should perhaps be ptp4l
itself, but then again, if ptp4l doesn't want to claim responsibility
either, and expect somebody else to set it up, then it is what it is.
_______________________________________________
Linuxptp-users mailing list
Linuxptp-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-users
