On Sat, Apr 24, 2021 at 06:01:46AM +0000, Ramana Reddy wrote: > <Ramana> Thanks. What I think is running multiple ptp4l instances might > defeat the purpose of using BMCA as the chosen ptp4l > Instance might not be carrying the best clock compared to other ptp4l > instances. Alternatively we might have to bring in > Additional Intelligence(similar to BMCA) to monitor bunch of ptp4l instances > to pick best one dynamically.
An advantage of having multiple independent clients is that you can better detect failures in synchronization and avoid corrupting the other clocks. > <Ramana> I believe Ordinary Clock can have multiple ports and in such cases > only one of the ports will be in Client/Slave mode and > Other ports shall be either in Listening or passive mode based on whether the > other ports are receiving PTP traffic or > not. The specification defines an ordinary clock as "A PTP Instance that has a single PTP Port in its domain and maintains the timescale used in the domain." If you run ptp4l with multiple specified interfaces, it cannot be an ordinary clock. The boundary_clock_jbod and clientOnly options don't matter here. > Also IMHO port state PASSIVE doesn’t seem to be tied to a specific clock > mode(BC/OC) in the standard. Right. I read the original patch+report again and it's not clear to me why you need the port to be in the passive state. I tried --boundary_clock_jbod=1 --clientOnly=1 with two interfaces and it seems to be switching them between the LISTENING and UNCALIBRATED/SLAVE states as expected. -- Miroslav Lichvar _______________________________________________ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
