Adding the image for reference.
[image: image.png]
Thanks,
Devasish Dey
SyncMonk Technologies.
On Mon, 17 Oct 2022 at 18:27, Devasish Dey <devasish....@syncmonk.net>
wrote:
> 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
