On Tue, Nov 05, 2019 at 03:52:13PM +0000, Christian Leeb wrote: > After master selection phase has setteled, OC immediately reports > clockQuality of GMC as parent. > An OC client might now erroneously assume that OC is (globally) synced to GMC > with a 100ns + 2 x BC accuracy, say a 500ns. > In reality it will take quite a long time until the entire chain of BC is > stabilized. > > Except for the "steps removed" attribute, there is no hint available to an OC > on how accurately it is synced to the master. > An improvement would be if the BC do not simply forward the parents > clockQuality. Instead it could e.g. forward a lower clockAccuracy as > depending on its offsetFromMaster.
Yeah. > Anyone having the same thoughts/issues? So you could see this as a flaw in the PTP as specified. The BMCA only considers the number of hops when a given GM is reachable by two or more paths. I think the clockQuality and clockAccuracy are meant to characterize the GM in isolation. This does not mean that the slave will always receive the best service from that GM. The new v2.1 standard adds a "synchronization uncertain" flag that, IIRC, aims to address this issue, but I'm not sure if the solution is really practical or not. In general, I doubt there is a "magic bullet" that lets you easily monitor the actual end to end GM-OC synchronization for arbitrary PTP networks. The only sure way is to provide a second channel, like a PPS from GM to OC, or a second network bypassing the BCs and doing using the NetSync Monitor method. If you can't afford a permanent second channel, then you can set one up temporarily to measure the synchronization behavior at the OC. Thanks, Richard _______________________________________________ Linuxptp-users mailing list Linuxptp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-users
