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.
>
> > In general, no Linux distro provides a sure way to determine the
> > correct UTC offset. In fact, this is not possible without consulting
> > the bulletin! So the responsibility of claiming correctness falls to
> > the designer of the GM.
> >
> > > 2. In the case of a slave clock, phc2sys detects that the UTC offset of
> > > the GM is traceable, and updates the CLOCK_TAI offset in the kernel.
> >
> > Are you asking about the slave ...
> >
> > > But for the GM system, who is supposed to update the CLOCK_TAI offset?
> >
> > or the GM ???
>
> 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.
>
> > > There is some logic in clock.c, namely clock_utc_correct() called
> > > from clock_synchronize():
> > >
> > > /* Update TAI-UTC offset of the system clock if valid and traceable. */
> > > if (c->tds.flags & UTC_OFF_VALID && c->tds.flags & TIME_TRACEABLE &&
> > > c->utc_offset_set != utc_offset && c->clkid == CLOCK_REALTIME) {
> > > sysclk_set_tai_offset(utc_offset);
> > > c->utc_offset_set = utc_offset;
> > > }
> > >
> > > but mind you, c->clkid is only set to CLOCK_REALTIME if we are
> > > performing software timestamping.
> >
> > Right, because with SW time stamping ptp4l is responsible for the
> > Linux system time.
> >
> > > So in the general case, ptp4l as GM
> > > does not update the CLOCK_TAI offset, and phc2sys does not, either.
> >
> > phc2sys does indeed set the offset.
> >
> > update_clock()
> > clock_handle_leap()
> > sysclk_set_tai_offset()
> >
> > > 3. Finally, why update the kernel's CLOCK_TAI offset only if the UTC
> > > offset is traceable?
> >
> > Because the GM tells us whether the offset is valid or not.
> >
> > > I mean, phc2sys in automatic mode sets up the
> > > CLOCK_REALTIME apart by 37 seconds from the PHC anyway, regardless of
> > > whether the UTC offset is traceable or not. Would it not make sense
> > > to set the kernel's TAI offset regardless?
> >
> > If that makes sense to you, then by all means, do it. You need only
> > use the pmc to read the "not-valid" UTC offset from ptp4l.
>
> Do what, patch phc2sys to set the CLOCK_TAI offset regardless of
> traceability of UTC? Would you accept that change?
>
> >
> > Thanks,
> > Richard
_______________________________________________
Linuxptp-users mailing list
Linuxptp-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-users
