Topic: AVB/Milan - Talker as gPTP - GM Priority 1620

Hello Again RME;

As I dig more into this standard of Milan and its clocking I wonder:

Why are we not able to set the user Priority of a talker such as the 1620 to influence the BMCA ? This setting is available on most compliant switches, but not it appears on any talker I have tested with.

Could this setting not be exposed to the user in some fashion?

My quick glance at IEEE 1588-2008 tells me I think each possible clock has a Priority 1 and 2 as part of the spec, and since all talkers (and listeners?) can be network clocks, this setting must exist somewhere?

For me, where the networks are not overly complex, it seems it might work well to influence things such that the 1620 is both gPTP GM AND when talking, the media clock source at the same time.

2 (edited by Max 2025-10-28 16:01:13)

Re: AVB/Milan - Talker as gPTP - GM Priority 1620

In MILAN, all talker entities have a Prio1 of 248 (see spec 1.3 4.2.6.2.1).

Re: AVB/Milan - Talker as gPTP - GM Priority 1620

Yes thanks, I see this spec:

5.6.2. gPTP Operation
5.6.2.1. Priority1 [gPTP, Clause 8.6.2.1]
If a PAAD is Grandmaster Capable the default priority1 value shall be 248 (Other Time-Aware System).

That leads me to believe 248 is the default, but then we could change it if we wanted and the device manufacturer wanted to make that available. So I guess I am asking if this could be done, or if not, I am curious why not?

Re: AVB/Milan - Talker as gPTP - GM Priority 1620

It should not be necessary to change priorities manually, at least that is the whole idea of using a BMCA. GM changes can occur anytime (after an initial syntonization) without causing dropouts. When a GM changes, there are mechanisms that ensure that streams are not interrupted and current time is held until a new GM takes over.

Re: AVB/Milan - Talker as gPTP - GM Priority 1620

To answer your question: yes, it would be possible to make the priority accessible. But a device with a high priority would then cause GM changes whenever (dis-)connected to the network, and that is a behavior that we would like to avoid suggesting to end users because it seems like a work-around for an unknown bug that just causes unnecessary traffic on the network, and it is quite cumbersome to learn and set up for the end user. Like setting dip-switches at the back of your device 20 years ago. The clocks in the network are all operating at their own pace anyway, so you do not improve anything if you make a specific device gPTP grandmaster.

I believe this all relates to your specific issue at hand (ref. other posts) and we are working with Netgear to solve this issue with stream interruptions when Netgear is gPTP GM.