Hi Richard,
On 13/02/18 17:27, Richard Cochran wrote:
On Tue, Feb 13, 2018 at 10:50:23AM +0100, brain wrote:
Dante sends ts=8 and other manufacturers send ts=0. Unless Linuxptp
properly implements the ts handling (i.e. ignoring bits 1-3) it
cannot work in such networks. Simply because fix-configuring to one
value (Dante or non-Dante) filters out the other clock source(s).
Ok. Thanks for explaining this. I wonder what ts=8 means in a Dante
network. Do you know?
Maybe it comes from PTPv1? Because Dante natively uses PTPv1 and in
AES67 mode uses PTPv2.
What other answer would offer to this problem then?
I have another idea how to support this use case. We can use a
configuration value of transportSpecific = 0x10 to mean "ignore".
Let me develop this idea further. What about splitting the
transportSpecific into the two nibbles, where lower nibble is as now and
the upper nibble is a mask telling which bits to ignore on RX.
This would have several advantages
* the TX value can be configured independently, whereas with a special
"ignore value" it would be fixed to 1 value.
* on RX it can be fully configured bitwise which bits to process
* backwards compatible (as your proposal)
* all 256 values have a meaning and there is no "special case" value,
which gives a cleaner design
One more thing to mention here. The different tools are still not
aligned on the configuration. So while ptp4l takes the transportSpecific
value from the config file, pmc from the command line, phc2sys doesn't
have this option.
Would this approach still work also with phc2sys?
And does it make sense to require full match of transportSpecific on UDS?
Regards
Petr
------------------------------------------------------------------------------
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
