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
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
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
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
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
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
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
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.
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:
-
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
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:
11 matches
Mail list logo