Hi,

> No, in a correctly configured gPTP network, all of the nodes have the same 
> settings.
Hmm, I don't agree ... The purpose of Signaling messages was to 
communicate/request rates that are needed by the slave/requester device and 
each slave device can have different "needs". What is more, as specified by 
Automotive Profile, the gPTP bridge should track and follow, on its slave port, 
the fastest rate on its master ports (see AVnu AP 6.2.3.1 SyncInterval [gPTP, 
Clause 10.2.4.5]):

"An AED-B may use the gPTP signaling technique to alter the SyncInterval on its 
slave port based upon the Sync intervals on its master ports. In such a case 
the AED-B's slave port's SyncInterval should track a value equal to the 
shortest SyncInterval across all the active AS master role ports on the Bridge. 
If the the AED-B does reduce the SyncInterval on its slave port, it shall do it 
within 4 seconds of the event that causes the update."

So, requesting master's initial sync rate interval instead own initial sync 
rate interval (that you just configured in *.cfg file) is just ptp4l issue ...

Cheers,
Pawel

-----Original Message-----
From: Richard Cochran <richardcoch...@gmail.com> 
Sent: Monday, June 21, 2021 1:57 PM
To: Miklas, Marcin <marcin.mik...@harman.com>
Cc: linuxptp-devel@lists.sourceforge.net
Subject: [EXTERNAL] Re: [Linuxptp-devel] [PATCH 0/2] gPTP profile 
interoperability problems

[EXTERNAL EMAIL]

On Mon, Jun 14, 2021 at 12:03:45PM +0000, Miklas, Marcin via Linuxptp-devel 
wrote:

> gPTP requires that PTP_TIMESCALE flag is set in messages. I noticed 
> that PDelayReq, PDelayResp, PDelayRespFollowUp, Sync, FollowUp and 
> Signaling all have that flag set to 0. One of the bridges just ignores 
> communication with ptp4l because of that.
> 
> The fault is on both sides, because gPTP specification says that 
> PTP_TIMESCALE should be set to 1 and ignored on reception.

No, the fault is not on both sides.

> Since fixing linuxptp is easier I created a patch which should fix that 
> problem.

Adding a hack into linuxptp is easier than fixing the actual problem in the 
other implementation, but that is a poor excuse.

> We can see that ptp4l slave is requesting gPTP master to use master's 
> initial sync interval.  This might be different than slave's initial 
> sync interval. If this is a case the signallings will be send over and over 
> again.

No, in a correctly configured gPTP network, all of the nodes have the same 
settings.

> Slave's own
> initalLogSyncInterval should be used here.
> 
> Current version is causing other problems with OpenAvnu's daemon_cl.

So fix daemon_cl.

NAK to both of these patches.

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

Reply via email to