linuxptp-users

[Linuxptp-users] phc2sys: why set CLOCK_TAI offset only when UTC offset is traceable?

[Vladimir O. <ol...@gm...>]

phc2sys sets the CLOCK_TAI offset of the kernel since commit

commit fefd5b4b05039ea0a0770291b12b0eb931079970
Author: Miroslav Lichvar <mli...@re...>
Date:   Wed Jun 18 15:44:49 2014 +0200

    Set TAI offset of system clock.

    When synchronizing the system clock and the PTP UTC offset is valid and
    traceable, set the TAI offset of the clock to have correct CLOCK_TAI
    (which is implemented in the kernel as CLOCK_REALTIME + TAI offset).

    Signed-off-by: Miroslav Lichvar <mli...@re...>

What I'm missing is:

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?

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.
   But for the GM system, who is supposed to update the CLOCK_TAI offset?
   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. So in the general case, ptp4l as GM
   does not update the CLOCK_TAI offset, and phc2sys does not, either.

3. Finally, why update the kernel's CLOCK_TAI offset only if the UTC
   offset is traceable? 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? As things stand, I think
   this behavior is just highly inconsistent. CLOCK_REALTIME certainly
   has an offset from the TAI timescale, as set by phc2sys, but
   applications cannot detect this.

Re: [Linuxptp-users] phc2sys: why set CLOCK_TAI offset only when UTC offset is traceable?

[Richard C. <ric...@gm...>]

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.

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

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

Thanks,
Richard

Re: [Linuxptp-users] phc2sys: why set CLOCK_TAI offset only when UTC offset is traceable?

[Vladimir O. <ol...@gm...>]

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

Re: [Linuxptp-users] phc2sys: why set CLOCK_TAI offset only when UTC offset is traceable?

[Vladimir O. <ol...@gm...>]

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

Re: [Linuxptp-users] phc2sys: why set CLOCK_TAI offset only when UTC offset is traceable?

[Richard C. <ric...@gm...>]

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

Re: [Linuxptp-users] phc2sys: why set CLOCK_TAI offset only when UTC offset is traceable?

[Vladimir O. <ol...@gm...>]

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.