Rodney,
I appreciate your explanation of the state of the standards. It is
quite helpful. I have a few comments, below.
On Sat, Sep 28, 2019 at 08:19:32PM +0000, Rodney Cummings wrote:
> I'd recommend either (in order of preference):
> 1. Integrate time-aware bridge into linuxptp's Boundary Clock code, as
> originally suggested by Rodney Greenstreet.
> 2. Integrate time-aware bridge as a new "hybrid" clock, as suggested by
> Richard Cochran (as I understand). I'd recommend "PRI" as an acronym (not
> "TAB").
> That being said, it is great that the debate between #1 and #2 above
> is not "Should we integrate this standard?", but instead "What is
> the correct way to integrate this standard?"
+1
> In my opinion, the most
> important thing is to answer Yes to the 1st question. Although I
> have an opinion on the 2nd question, I don't feel strongly about it,
> and I'm happy to defer to those who know more about the code
> structure.
In the end, it does not matter whether you call it TAB, BC, TC, or
whatever else you like. What matters to linuxptp is having the
cleanest possible implementation of the new functionality.
> Why are the timelines of these documents so close? The answer comes
> back to an issue discussed for linuxptp: Is 802.1AS a distinct
> protocol, or is it a profile of 1588?
It is a sad fact that many so-called 1588 "profiles" mandate new
behaviors in arbitrary and mostly pointless ways. IEEE 1588 Clause
19.3 clearly spells what exactly what a profile may specify. In
particular, this part is definitive:
A PTP profile shall extend the standard only by:
a) The use of the TLV mechanism of 14.3.
b) The specification of an optional best master clock algorithm; see 9.3.1.
c) The specification of an optional management mechanism; see 15.1.1.
d) The provisions of 19.2.2.
e) The provisions of 7.3.1.
In many cases authors of profiles apparently felt no obligation to
follow the specification.
> This was a reasonable question
> to ask, because 802.1AS-2011 did some things that were formally
> non-conformant to 1588-2008 (e.g. different BMCA, WiFi time sync
> using radio). Members of both standards working groups felt that
> this was a problem,
I am glad to hear that the committee members recognized this issue.
In my view, 802.1-AS is the "profile" with the severest case of NIH
wrt 1588 and thus most egregious violations of 19.3.
> 7.5 c) In gPTP there are only two types of PTP Instances: PTP End
> Instances and PTP Relay Instances, while IEEE 1588 has Ordinary
> Clocks, Boundary Clocks, end-to-end Transparent Clocks, and P2P
> Transparent Clocks. A PTP End Instance corresponds to an IEEE 1588
> Ordinary Clock, and a PTP Relay Instance is a type of IEEE 1588
> Boundary Clock where its operation is very tightly defined,
s/defined/re-defined/ ???
> so much
> so that a PTP Relay Instance with Ethernet ports can be shown to be
> mathematically equivalent to a P2P Transparent Clock in terms of how
> synchronization is performed."
IOW it is more like a TC than a BC.
> It is important to understand that in both 802.1AS-2011 and
> 802.1AS-2020, conformance requires support for different Sync
> intervals on each port.
You say that the "PTP Relay Instance" conforms to a IEEE 1588 BC.
Where in IEEE 1588 are per-port Sync rates defined or allowed for a BC?
> Therefore, the TC-like behavior of the
> 802.1AS BC is never guaranteed to exist. I realize that this sort of
> interval difference seems counter-intuitive, but there are
> legitimate use cases that drove it as an optional capability. For
> example, when you turn on the ignition in your car, the in-vehicle
> PTP network will need to reach stable sync quickly, so the Sync
> intervals start off fast, and slow down later once stable sync is
> achieved, such that during the transition from fast to slow
> different intervals exist.
We already support this use case in the end points.
> To be clear, I am not recommending that linuxptp attempt to
> implement features from 1588-2020 or 802.1AS-2020 at this time,
> because the lack of formal publication makes that impossible. My
> reference to the 2020 drafts is only intended to clarify that
> 802.1AS is a BC, and that the term "TAB" will be dead in a few
> months time. We don't necessarily need to use "PRI" (PTP Relay
> Instance) now, but I tend to think that would result in better
> alignment with the standard in the long run.
I don't have a strong opinion about the name, but I agree about
avoiding names that are disappearing.
> Regarding requests for "the automotive profile of 802.1AS", we need
> to be careful, because there is no such document at the
> moment.
Oh really? So what do you call this?
https://avnu.org/wp-content/uploads/2014/05/Automotive-Ethernet-AVB-Func-Interop-Spec-v1.5-Public.pdf
> There are at least two documents in the automotive industry
> that specify this concept,
And what is the other one?
> but neither of those documents is conformant to IEEE 802.1AS-2011
> (or 2020).
But who cares? As I said before, many of the IEEE 1588 "profiles"
violate the standard, but no one ever complained before.
(Sorry for my snappy tone, but I am the poor schmuck who has to turn
the wild jungle of profiles into some kind of coherent software that
actually works on real life hardware running under a real operating
system ;^)
Thanks,
Richard
_______________________________________________
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
