Hi Richard, I'm reading once again the RFC and the AES specifications. The documents indeed say that the receiver just checks if his clock matches the ts-refclk. And if it doesn't it simply indicates that it cannot play. So you're right. There is no need to influence the master selection, as I originally though.
The only remaining question is how to efficiently get the ptp4l status (or even better the status change event) from a C application. Regards Petr On 17/05/17 19:16, Richard Cochran wrote: > On Wed, May 17, 2017 at 04:08:07PM +0200, Petr Kulhavy wrote: >> See the "ts-refclk" attribute defined in RFC7273 > Section 4.3: > > The PTP protocols employ a distributed election protocol called the > "Best Master Clock Algorithm" (BMCA) to determine the active clock > master. The clock master choices available to BMCA can be restricted > or biased by configuration parameters to influence the election > process. In some systems, it may be desirable to limit the number of > possible PTP clock masters to avoid the need to re-signal timestamp > reference clock sources when the clock master changes. > > So you can limit the masters in the normal way, that is, by > configuration of the masters. > > Configuring a slave to choose a particular master is not specified in > RFC 7273. Or is it (TLDR)? If it is, then please point out where. > > Thanks, > Richard > ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Linuxptp-users mailing list Linuxptp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-users
