On Wed, Jun 07, 2017 at 02:46:39PM +0000, 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. > More specifically, a TAB has the following BC attributes: > - A TAB participates in the BMC selection. > - A TAB has port state. > - A TAB has a separate logSyncInterval dataset member for each port. > > It’s the last point that I think needs further clarification.
Sure, there is a per-port value, but this is only relevant when the port becomes the GM. > NOTE—The value of initialLogSyncInterval is the value of the sync > interval when the port is initialized. The value of the sync > interval may be changed, e.g., if the port receives a Signaling > message that carries a message interval request TLV (see 10.5.4.3), BTW, This part is not (yet) relevant for us, since we don't support signaling messages at all. > 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. Where in the standard is the operation of the timer specified? > It’s also clear that when the slave port of a TAB receives a > sync event, that message is not immediately sent out on downstream > ports. Rather, the configured sync interval for a given port must be > adhered to. You say this is clear. Where can I read about this? Is it modeled in the state machines somewhere? Thanks, Richard ------------------------------------------------------------------------------ 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
