On 12/02/18 19:12, Richard Cochran wrote:
On Mon, Feb 12, 2018 at 08:12:38AM +0100, brain wrote:
I understand that you might find this requirement to be
pointless. However in protocols it is not uncommon that certain bits
are reserved for future use. In order to provide forward compatible
implementations it is a common practice to require reserved bits to
be ignored on reception.
That is not what is going on here. These bits are *not* reserved for
future use.
I cannot agree with you. See Annex D.4 of IEEE1588-2008. It clearly says
"bit 1-3: reserved".
Due to the non-compliant implementation Linuxptp does not work in a
mixed AES67 network where Dante devices are present. Other AES67
implementations work well because they correctly ignore bits 1-3.
Ah, now we are getting somewhere. These bits are set by Dante devices
when they try and do PTP, correct?
Do you have a pointer to the Dante specification that explains this
behavior?
As you probably know, it is closed.
However let's not divert from the original topic. I do indeed have
several pointers to the IEEE1588-2008 specification showing where
Linuxptp is not compliant and do have a real-life situation where this
incompatibility makes Linuxptp unusable in a professional environment.
Which is quite a pity.
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
