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
_______________________________________________
Linuxptp-users mailing list
Linuxptp-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-users
