Re: [Linuxptp-users] gmPresent in pmc output

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

On Thu, Apr 30, 2020 at 12:42:55PM +0000, RAVEENDRA M via Linuxptp-users wrote:
> We are running ptp slave sync with PTP master running on another VM in Boundary clock which is getting sync with GM directly.
> 
> Is "gmPresent    : false"  expected or "gmPresent  : true"  as it is getting sync with Boundary clock master.
> 
> root@/mnt/data/apps# pmc -2 -f /mnt/data/apps/ptp4l_new.conf -b 0 -i eth1 'get TIME_STATUS_NP'
> sending: GET TIME_STATUS_NP
>         00a0a5.fffe.d44480-1 seq 0 RESPONSE MANAGEMENT TIME_STATUS_NP
>                 master_offset              0
>                 ingress_time               0
>                 cumulativeScaledRateOffset +0.000000000
>                 scaledLastGmPhaseChange    0
>                 gmTimeBaseIndicator        0
>                 lastGmPhaseChange          0x0000'0000000000000000.0000
>                 gmPresent                  false
>                 gmIdentity                 00a0a5.fffe.d44480

The gmPresent flag is set like this,

	if (cid_eq(&c->dad.pds.grandmasterIdentity, &c->dds.clockIdentity))
		tsn->gmPresent = 0;
	else
		tsn->gmPresent = 1;

where

   dds = defaultDS
   dad = parent_ds, pds = parentDS

IOW, it checks whether the local clock is the GM.

The reason for this (IIRC) is that the TIME_STATUS_NP is ptp4l's way
of implementing,

   9.2 ClockSourceTime interface
   9.3 ClockTargetEventCapture interface
   9.6 ClockTargetPhaseDiscontinuity interface

from 802.1AS.

In that standard, the local clock is supposed to always be free
running, and so the TIME_STATUS_NP.ingress_time will always be WRT the
local clock.  So I guess this could be changed to depend on the value
of the free_running attribute, but it would require some thought.

If you are not using 802.1AS, then I recommend sticking to the
management messages from 1588, specifically:

   CURRENT_DATA_SET.stepsRemoved

   PARENT_DATA_SET.parentPortIdentity
   PARENT_DATA_SET.grandmasterIdentity

Does that make any sense?

Thanks,
Richard