On Fri, Apr 20, 2018 at 11:01:09PM -0700, Richard Cochran wrote: > On Wed, Apr 18, 2018 at 03:28:08PM +0200, Miroslav Lichvar wrote: > > E2E TC with the P2P delay mechanism doesn't seem to work. The e2e_tc > > code drops pdelay req/resp. If I'm reading the 1588 spec correctly, > > that should be allowed. > > Not exactly. There is this: > > 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? If some future standard will figure it out, will it work with the current TC implementation? 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. > > Also, should the TC drop > > sync/delay messages until it has estimated the offset to minimize > > disturbances when the TC is restarted? > > 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. > > With P2P TC free_running can be disabled, but I'm not sure how much > > sense such a configuration makes. Are there any plans to support a > > combined OC+TC? > > 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? > but > still someone may want to have the TC synchronized, and I think the > user should be able to have it that way. > > 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. 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? -- 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
