Hi Richard,
Unfortunately the fixed configuration doesn't work in mixed networks, as I
already said.
An AES67 network with Dante and some other AES67 manufacturer equipment
(Ravenna, Archwave or other) is a very common use case. AES67 is all about
interoperability of different vendors and Dante is very widely used technology
in pro audio networking. So the chances that an AES67 network contains one
Dante and one non-Dante device are quite high.
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). So there would have to be someone
permanently standing there and changing the Linuxptp configuration according
to the current best master clock selected. Which is totally impractical.
What other answer would offer to this problem then?
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.
RegardsPetr
Advertising
-------- Původní zpráva --------Od: Richard Cochran <richardcoch...@gmail.com>
Datum: 13.02.18 3:11 (GMT+01:00) Komu: Petr Kulhavy <br...@jikos.cz> Cc:
linuxptp-devel@lists.sourceforge.net Předmět: Re: [Linuxptp-devel] Transport
specific in UDP
On Mon, Feb 12, 2018 at 08:05:36PM +0100, Petr Kulhavy wrote:
> As you probably know, it is closed.
I don't know very much about it, and that is why I asked. Maybe there
is a good reason to set these bits. If dante networks use value X,
then the easiest and most logical way to inter-operate is to use
--transportSpecific=X and be done with it. As an added bonus, all of
the PTP frames will be consistent.
The general approach that I have haven with linuxptp is to make most
everything configurable. That is how we are able to support such a
large variety of profiles, including 1588 and 802.1-AS. Rather than
hard coding different profiles, the user may freely mix and match.
For example, there has been some talk about using AVB over IP
networks. With linuxptp, this is already supported. You simply edit
gPTP.cfg and change 'network_transport' from 'L2' to 'UDPv4', and it
works.
> 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.
Too bad the software isn't working in your "professional" environment.
Sorry,
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
