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
