On Thu, Apr 26, 2018 at 07:15:08AM -0700, Richard Cochran wrote: > On Thu, Apr 26, 2018 at 09:09:10AM +0200, Miroslav Lichvar wrote: > > FWIW, 10.2 clearly says that a E2E TC should forward all PTPv2 > > messages and correct all event messages, and it shouldn't make its own > > P2P delay measurements. > > But does it make any sense to send P2P delay frames out multiple > ports?
Probably not, at least until it is specified by the standard. For a E2E TC which has only two PTP ports (and other non-PTP ports) this is not a problem though. It could be inserted between two clocks using the P2P delay mechanism and they wouldn't see a difference except non-zero corrections in received packets. > Correcting P2P delay requires keeping track of all outstanding peer > delay exchanges. IMHO it is a waste of effort to support > mis-configured PTP networks that mix E2E and P2P in some undefined > way. We can always add this later on, if and when this mixing becomes > standardized. Ok, fair enough. > > > But that would make cold start up take longer, wouldn't it? > > > > I'm not sure. I guess it will depend on the servo and delay filtering > > used by the OCs. If the TC makes inaccurate corrections, it might take > > longer for the OCs to converge to the corrected values later. > > So the TC doesn't make inaccurate corrections, it simply makes no > correction at all (residence * 1.0) until the rate ratio is known. > This behavior is actually allowed by 1588, as syntonization is > optional. I think that might be even worse than making inaccurate corrections with zero frequency offset. If a TC and slave are (re)started at the same time, the slave's initial correction may have a large error, which will need to corrected later (when steps may already be disabled). It will also disrupt the slave's frequency estimate if the TC starts correcting the messages before the slave's estimation interval ends. -- Miroslav Lichvar ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
