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).
Advertising
Ok. Thanks for explaining this. I wonder what ts=8 means in a Dante network. Do you know? > 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". > I'm wondering what blocks you to accept this simple change. It a) > improves compliancy with the standard, b) improves interoperability, > c) is very small and therefore low risk. For me these are already > very strong arguments for the change. You seem to must have even > stronger argument against it, when you still rejecting it. I would > like to learn that logical argument. I do want to support inter-operation as much as is practical. However, I also want to understand the issues and find the best solution, keeping in mind the design of the software. Simply put, I want to keep the non-standard option of matching on transportSpecific. As I mentioned, this allows AVB over IP to just work. Possibly other people are using or will use transportSpecific in creative ways that we don't know about. We can support your use case without breaking any other uses of that field... 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
