Sorry for the top-post, outlook only likes plain-text for inline replies.
Regarding issues with the spec itself, there’s not much we can do about that –
the spec’s the spec, and influencing that needs to be done within the Avnu
working group. That said, the automotive profile will be superseded by
802.1AS-REV, and much of the automotive profile functionality is rolled forward
to that revision, albeit differently in some cases, so similar changes are
coming one way or another. But, that IEEE version will not be public for quite
some time, and the automotive industry is not waiting around. Our goal with
adding automotive profile support to LinuxPTP is explicitly to avoid forks and
fragmentation, and keep everyone back in a common mainline until we can roll
them over to 802.1AS-REV in the future. Yes, it’s a stop-gap, but a necessary
one to avoid further fragmentation.
Thanks,
Gavin Hindman
Intel Open-Source Technology Center
From: Cliff Spradlin <csprad...@google.com>
Sent: Wednesday, July 18, 2018 12:20 PM
To: Patel, Vedang <vedang.pa...@intel.com>
Cc: linuxptp-devel@lists.sourceforge.net; Sanchez-Palencia, Jesus
<jesus.sanchez-palen...@intel.com>; Gomes, Vinicius <vinicius.go...@intel.com>;
Hindman, Gavin <gavin.hind...@intel.com>; Guedes, Andre <andre.gue...@intel.com>
Subject: Re: [Linuxptp-devel] [RFC 1/1] Add avnu_ap to enable AVnu Automotive
Profile
On Wed, Jul 18, 2018 at 10:36 AM Patel, Vedang
<vedang.pa...@intel.com<mailto:vedang.pa...@intel.com>> wrote:
To take advantage of the quicker startup time the profile specifies.
There will be more features added later on which will further optimize
linuxptp to run more efficiently on the automotive network. I have
described all of the future enhancements in the cover letter:
So the motivation behind these changes is quicker startup time, and faster
synchronization of slave clocks. That is a good goal, but best implemented
directly into an existing spec. Instead, this spec deeply modifies 802.1as
creating yet another non-conforming variant of IEEE 1588.
Removing Announce and BMCA seems to cause all sorts of additional complexity,
such as all this logic for what a boundary clock should do based on the lack of
a Sync message. If it just ran normal PTP it wouldn't need all this complexity
- it could just promote its local clock as grandmaster.
This spec has a lot of special logic that you haven't yet implemented - see
"9.3.2 Non-Continuous Sync Values" for example. One of your planned features is
to slow down Sync messages after stabilization, but that appears to require a
special port-local signalling message to be sent and received.
Normally I'd say that this spec could be implemented by creating a separate
state machine (similar to the slaveOnly state machine), but this is all just
too different. Personally, I think that if you really need to implement this
spec, it would be better to fork linuxptp, strip out all the disabled and
unnecessary features, and implement all special-case logic directly, instead of
conditionally. As far as I can see, this spec will only become more divergent
from IEEE 1588 and 802.1as over time with planned security and path redundancy
features.
If we look at table 6 in Section 5.5 of the spec[1], grand master is
expected to start sending Sync/Follow-Up messages within 250ms. Without
skipping BMCA, I don't see it happening.
Without any patches ptp4l can already become grandmaster quickly: setting
logAnnounceInterval to -10 gets through BMCA in 3 milliseconds on my computer.
------------------------------------------------------------------------------
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
