2269173_en-US

はい

S32N55: sequence ID in gPTP bridge device when acting as a GM

Hi team,

I was testing the bridge device behavior in the gPTP example. I use the GrayVIP_1_0_22_0.

According to the User Manual, if the bridge does not receive any Sync messages after StartupTimeoutS, it should start operating as a GM. However, I observed that in this situation, the Sequence ID in both Sync and Sync Follow-Up frames remains at 1024 and does not increase.

After checking the related code, I found that when the bridge transitions to GM mode, the Sequence ID used for generating Sync messages is taken from the prSyncMachines[prDomain->u8SlaveMachineId].u16SequenceId of the slave port.

If the slave port has not received any Sync messages, this value is never updated, which causes the Sequence ID in the Sync messages sent by the master port to remain unchanged.

This behavior suggests that the bridge cannot function properly as a GM under this mechanism.
Could you please help explain why the bridge is designed to behave this way?

BR,
Bridget

GPTP_STACK

Re: S32N55: sequence ID in gPTP bridge device when acting as a GM

Hello @Bridget,

The team has picked up a case and will provide an answer as soon as possible

Best regards,
Radu

Re: S32N55: sequence ID in gPTP bridge device when acting as a GM

Hi @Bridget,

We are working to reproduce the issue and will discuss further steps in the team. I will get back to you.

Thanks,
Lukas

Re: S32N55: sequence ID in gPTP bridge device when acting as a GM

@Bridget,

As it turns out, this behavior of the gPTP Bridge is intended, and in line with the 802.1as standard.

The Bridge is supposed to relay Sequence ID received on master port. If the Grand Master is lost, the Sequence ID indeed stops being updated - this is one of the ways that downstream devices are able to tell when GM is lost.

For a Bridge that never had a GM in the first place, the Sequence ID is random per standard. Our interpretation of random is that nothing about the Sequence ID is guaranteed, or should be assumed. A hardcoded 1024 is considered compliant to that (could be any other number).

Is the Sequence ID causing issues in your application? As you have surely observed, Endpoints are perfectly capable of synchronizing to the Bridge, regardless of Sequence ID.

Apologies for taking so long. Please do let me know if anything is unclear.

BR, Lukas