Re: [Linuxptp-devel] [RFC 1/1] Add avnu_ap to enable AVnu Automotive Profile

[Hindman, G. <gav...@in...>]

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 <csp...@go...>
Sent: Wednesday, July 18, 2018 12:20 PM
To: Patel, Vedang <ved...@in...>
Cc: lin...@li...; Sanchez-Palencia, Jesus <jes...@in...>; Gomes, Vinicius <vin...@in...>; Hindman, Gavin <gav...@in...>; Guedes, Andre <and...@in...>
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 <ved...@in...<mailto:ved...@in...>> 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.