> When I first looked at it, I made a conscious decision *not* to
> support it, because it appeared to me as a special hack for someone
> pulling strings in the standards process.
That's exactly our opinion.
> Do you mind telling us what HW is using the hardwareCompatibility bit?
In the audio
On Wed, Jul 20, 2016 at 02:19:11PM +, Jesuiter, Henry (ALC NetworX GmbH)
wrote:
> In fact we have a project here, that uses such mixed-mode network (some
> devices set that bit, other don't).
> To distinguish between gPTP and PTP one could just use the additional
> information about the tra
> We don't support the hardwareCompatibility bit. It conflicts with
> gPTP according to 802.1AS. It is hack (I guess for a particular
> vendor) for compatitibiliy with some legacy PTP Version 1 hardware.
> Why on earth would you want it?
Thank you for your quick answer.
In fact we have a pro
On Wed, Jul 20, 2016 at 10:03:52AM +, Jesuiter, Henry (ALC NetworX GmbH)
wrote:
> according to IEEE 1588-2008 Annex D.4 it is possible to set the
> transport specific bit to signal that PTP event (and Announce)
> messages have to be padded. Now we are discussing here, if that
> consequently al
Hello,
according to IEEE 1588-2008 Annex D.4 it is possible to set the transport
specific bit to signal that PTP event (and Announce) messages have to be
padded. Now
we are discussing here, if that consequently allows to have a mixed mode
PTP-Network, where one or more hosts set this bit and o
