Hi Richard, Thanks for your inputs. > -----Original Message----- > From: Richard Cochran [mailto:[email protected]] > Sent: Monday, November 5, 2018 9:22 PM > To: Patel, Vedang <[email protected]> > Cc: [email protected]; Sanchez-Palencia, Jesus > <[email protected]>; Gomes, Vinicius > <[email protected]>; Guedes, Andre <[email protected]>; > Hindman, Gavin <[email protected]> > Subject: Re: [PATCH v1 6/7] port: Add interval update timer. > > On Fri, Oct 05, 2018 at 04:25:06PM -0700, Vedang Patel wrote: > > This commit adds functionality to increase the sync and pdelay request > > intervals once gptp synchronization has been achieved. This is useful > > while running Automotive Profile where the network is usually static. > > > > This is done by setting up a timer when the first sync message is > > received by the slave. When the timer expires, the slave will send a > > signaling message which tells the master what interval to switch to. > > So I think using a timer isn't the right approach. How can we be sure the > slave is > always ready after a fixed time? > > Instead, I would have expected this: > > Slave goes LISTENING -> UNCALIBRATED. > > When some pre-defined criterion is fulfilled, then the slave goes UNCALIBRATED > -> SLAVE, and on this state transition the slave then request the slower sync > rate. > > Thoughts? Using the mechanism described above is definitely a better approach than just using a timer.
About the criterion, we can check the last 'n' offsets and see if all those are below a threshold. If that is true, we can send the signaling message to increase the sync interval. Both, the offset threshold and the number of values to check, will be configurable parameters. The downside is the addition of 2 more configuration options. What do you think about this approach? Thanks, Vedang > > Thanks, > Richard _______________________________________________ Linuxptp-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
