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
> 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
