Re: [Linuxptp-devel] [PATCH 1/3] Added support for IEEE 802.1AS 2011 bridges.

2017-06-07 Thread Richard Cochran
On Wed, Jun 07, 2017 at 06:20:40PM +, Rodney Greenstreet wrote: > I think this SM is optimized for behaving as you suggest, with the > assumption all sync intervals are the same. However, a port’s > syncInterval, or some fraction of it, must be adhered to. Also, if a > Sync event is not

Re: [Linuxptp-devel] [PATCH 1/3] Added support for IEEE 802.1AS 2011 bridges.

2017-06-07 Thread Rodney Greenstreet
On 6/7/17, 12:16 PM, "Richard Cochran" wrote: > On Wed, Jun 07, 2017 at 04:51:03PM +, Rodney Greenstreet wrote: > > Please review this state machine again. The syncInterval is used to govern > > the transition back to the ‘SEND_MD_SYNC’ state. This

Re: [Linuxptp-devel] [PATCH 1/3] Added support for IEEE 802.1AS 2011 bridges.

2017-06-07 Thread Richard Cochran
On Wed, Jun 07, 2017 at 04:51:03PM +, Rodney Greenstreet wrote: > Please review this state machine again. The syncInterval is used to govern > the transition back to the ‘SEND_MD_SYNC’ state. This transition only occurs > if the the syncInterval has elapsed and the received Sync message is not

Re: [Linuxptp-devel] [PATCH 1/3] Added support for IEEE 802.1AS 2011 bridges.

2017-06-07 Thread Rodney Greenstreet
On 6/7/17, 11:33 AM, "Richard Cochran" wrote: > On Wed, Jun 07, 2017 at 06:11:42PM +0200, Richard Cochran wrote: > > On Wed, Jun 07, 2017 at 02:46:39PM +, Rodney Greenstreet wrote: > > > Based on these clauses, it’s clear that each port maintains its

Re: [Linuxptp-devel] [PATCH 1/3] Added support for IEEE 802.1AS 2011 bridges.

2017-06-07 Thread Richard Cochran
On Wed, Jun 07, 2017 at 04:24:52PM +, Rodney Greenstreet wrote: > Please read clause 10.6.2.3 ‘time-synchronization event message transmission > interval’ and clause 10.6.2.4 ‘Interval for providing synchronization > information > by ClockMaster entity’. The last clause makes it very clear

Re: [Linuxptp-devel] [PATCH 1/3] Added support for IEEE 802.1AS 2011 bridges.

2017-06-07 Thread Richard Cochran
On Wed, Jun 07, 2017 at 06:11:42PM +0200, Richard Cochran wrote: > On Wed, Jun 07, 2017 at 02:46:39PM +, Rodney Greenstreet wrote: > > Based on these clauses, it’s clear that each port maintains its own > > sync interval setting and needs to maintain its own sync interval > > timer. It’s also

Re: [Linuxptp-devel] [PATCH 1/3] Added support for IEEE 802.1AS 2011 bridges.

2017-06-07 Thread Rodney Greenstreet
On 6/7/17, 10:38 AM, "Richard Cochran" wrote: On Wed, Jun 07, 2017 at 02:46:39PM +, Rodney Greenstreet wrote: > > Thank you for your feedback. I want to explain why we chose to add TAB to your BC implementation rather than adding a new type of device. A TAB

Re: [Linuxptp-devel] [PATCH 1/3] Added support for IEEE 802.1AS 2011 bridges.

2017-06-07 Thread Richard Cochran
On Wed, Jun 07, 2017 at 02:46:39PM +, Rodney Greenstreet wrote: > Thank you for your feedback. I want to explain why we chose to add TAB to > your BC implementation rather than adding a new type of device. A TAB is > mathematically equivalent to a TC but is functionally equivalent to a BC.

Re: [Linuxptp-devel] [PATCH 1/3] Added support for IEEE 802.1AS 2011 bridges.

2017-06-07 Thread Rodney Greenstreet
Hi Richard, Thank you for your feedback. I want to explain why we chose to add TAB to your BC implementation rather than adding a new type of device. A TAB is mathematically equivalent to a TC but is functionally equivalent to a BC. More specifically, a TAB has the following BC attributes: -

Re: [Linuxptp-devel] [PATCH 1/3] Added support for IEEE 802.1AS 2011 bridges.

2017-06-06 Thread Richard Cochran
This patch doesn't let ptp4l work as a Time Aware Bridge! On Thu, Jun 01, 2017 at 04:05:57PM +, Erik Hons wrote: > This commit only focuses on time transfer and not BMCA changes. This change log is totally inadequate. You need to tell us why your changes are needed. Is something not in

Re: [Linuxptp-devel] [PATCH 1/3] Added support for IEEE 802.1AS 2011 bridges.

2017-06-06 Thread Richard Cochran
Apart from the actual logic, this patch (and the other two) have formatting issues. First off, these patches don't apply. They are white space damaged. Secondly: In order to submit a patch from someone else, please follow this direction from linux/Documentation/process/submitting-patches.rst: