On Thu, Apr 26, 2018 at 09:09:10AM +0200, Miroslav Lichvar wrote: > On Fri, Apr 20, 2018 at 11:01:09PM -0700, Richard Cochran wrote: > > > > NOTE -- Peer-to-peer clocks are normally used only in a > > homogeneous system of peer-to-peer clocks. The provisions of > > 11.5.4 allow the use of end-to-end transparent clocks in systems > > based on future versions of the standard that might specify how to > > implement mixed systems with one-to-many connections between > > peer-to-peer clocks. > > I don't really understand what this means. Does it apply to TC or > rather BC/OC?
Clause 11.5.4 is about correcting P2P delay residence in an E2E TC. > If some future standard will figure it out, will it work > with the current TC implementation? No, because we drop P2P delay frames when in E2E mode. > 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? 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. > > 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. > > Right, so the P2P TC with free_running=0 will synchronize to the GM. > > My tests show that that causes larger errors at the OC slaves, > > Have you tried it with a slower servo configuration? No, I only ran with the default automatic PI weights. So maybe TC synchronization can be improved by end user configuration. > > For E2E, I suppose we could snoop the delay from the switch port that > > is the slave state... > > I think a combined OC+TC should make its own delay measurements. There > are some notes at the end of the sections 6.5.4 and 6.5.5 in the spec. Hm. Well in any case I don't like how my E2E TC acts differently than a P2P TC with respect to free_running. The E2E mode needs to synchronize when free_running=0. > I have another question about the TC implementation. What happens > when it's forwarding messages from different domains? I have not tried > it. The TC code doesn't seem to care much about the number. For > estimating the frequency offset, shouldn't it avoid mixing > measurements from different domains? Yes, good point. 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-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
