On Wed, Apr 18, 2018 at 03:28:08PM +0200, Miroslav Lichvar wrote:
> This is an amazing feature. I'm glad that we'll finally be able to
> test the processing of the correction field without having to have a
> PTP-TC switch (I have yet to see one).
Me neither!
> With E2E TC the delay measured by the slave was the sum of the two
> links' delays. With P2P TC the delay was just the link it was
> connected to.
Right. (That is expected. The P2P TC accumulate the delays into the
correction field.)
> 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.
So I don't feel any great need to support P2P over E2E until we hear
how this 1:N relation is supposed to work!
> It took me a while to realize I need to enable free_running to enable
> the E2E TC to correct for the measured frequency offset. Would it make
> sense to imply that option automatically?
Both configuration files for TC do have free_running enabled.
> 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 think shortening startup is more important than restart behavior.)
> 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, 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...
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
