>
> This is so wrong.
>
> 1. When (p->state != PS_MASTER), then the port has no business
> transmitting Announce messages.
>
> 2. The ALT_MASTER flag has nothing to do with "clock_telecom_profile()".
> Rather it is an optional part of 1588, independent of any profile.
>
Please refer to ITU-T G.8275.2 Section 6.9 which clearly mentions that the
alternate Master flag used in this specification does not use clause 17.3
of IEEE 1588-2019. And moreover, Appendix III clearly mentions:
"The PTP connections between the T-BC-Ps allow the T-BC-Ps to support
specific monitoring types. For example, T-BC-P #D may monitor and learn the
PDV characteristics of the PTP service from T-BC-P #C. This may be used to
help the T-BC-P #D to synchronize more quickly to the T-BC-P #C backup PTP
flow should the connection to the T-GM #A fail.
[image: image.png]
So this is not wrong at all, yes it is not in line with IEEE-1588, which we
agree on, but it is explicitly mentioned in ITU-T G.8275.2 that it does not
use the IEEE-1588 specifications in this case and so we have added the code
under Telcom conditions. This feature has advantages and helps in fast
synchronization to the master in case of any network failure as the
instances are keeping track of possible best masters.
Thanks,
Devasish Dey
Vice President
Engineering Product Development | SyncMonk Technologies Pvt Limited
+91-783-8079202
devasish....@syncmonk.net
www.syncmonk.net
367, KPC Layout, Bangalore-560035
On Sat, 15 Oct 2022 at 11:26, Richard Cochran <richardcoch...@gmail.com>
wrote:
> On Wed, Aug 24, 2022 at 03:57:12PM +0530, SyncMonk Technologies wrote:
>
> > @@ -1595,6 +1611,10 @@ int port_tx_announce(struct port *p, struct
> address *dst, uint16_t sequence_id)
> >
> > msg->header.flagField[1] = tp.flags;
> >
> > + if (p->state != PS_MASTER && clock_telecom_profile(p->clock)) {
> > + msg->header.flagField[0] |= ALT_MASTER;
> > + }
> > +
>
> This is so wrong.
>
> 1. When (p->state != PS_MASTER), then the port has no business
> transmitting Announce messages.
>
> 2. The ALT_MASTER flag has nothing to do with "clock_telecom_profile()".
> Rather it is an optional part of 1588, independent of any profile.
>
> > @@ -1674,6 +1694,10 @@ int port_tx_sync(struct port *p, struct address
> *dst, uint16_t sequence_id)
> > msg->header.flagField[0] |= TWO_STEP;
> > }
> >
> > + if (p->state != PS_MASTER && clock_telecom_profile(p->clock)) {
> > + msg->header.flagField[0] |= ALT_MASTER;
> > + }
>
> ditto
>
> > @@ -2455,19 +2513,22 @@ void process_sync(struct port *p, struct
> ptp_message *m)
> > case PS_DISABLED:
> > case PS_LISTENING:
> > case PS_PRE_MASTER:
> > - case PS_MASTER:
> > case PS_GRAND_MASTER:
> > case PS_PASSIVE:
> > return;
> > + case PS_MASTER:
> > + if (!p->altMaster) {
> > + return;
> > + }
> > + break;
>
> Seriously. If port state is PS_MASTER, then it shouldn't process Sync
> messages!
>
> Thanks,
> Richard
>
>
>
> _______________________________________________
> Linuxptp-devel mailing list
> Linuxptp-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
>
--
_______________________________________________
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
