On 6/7/17, 12:16 PM, "Richard Cochran" <[email protected]> wrote:
> On Wed, Jun 07, 2017 at 04:51:03PM +0000, 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 from
> > ourselves and the port is enabled and the port is asCapable and the
port is
> > in the master role.
> No, you are really not paying attention.
> Here is the condition on the lower left of Figure 10-8:
> ( ( ( rcvdPSSync &&
> (currentTime lastSyncSentTime >= 0.5*syncInterval) &&
> rcvdPSSyncPtr->localPortNumber != thisPort) )
> || ( (currentTime lastSyncSentTime >= syncInterval) &&
> (lastRcvdPortNum != thisPort) ) )
> && portEnabled && pttPortEnabled && asCapable &&
> selectedRole[thisPort] == MasterPort
> Lets make this more readable:
> 1 (
> 2 (
> 3 (rcvdPSSync &&
> 4 (currentTime lastSyncSentTime >= 0.5*syncInterval) &&
> 5 rcvdPSSyncPtr->localPortNumber != thisPort)
> 6 ) || (
> 7 (currentTime lastSyncSentTime >= syncInterval) &&
> 8 (lastRcvdPortNum != thisPort)
> 9 )
> 10 )
> 11 && portEnabled
> 12 && pttPortEnabled
> 13 && asCapable
> 14 && selectedRole[thisPort] == MasterPort
> The outer expression (lines 1, 10, and 11-14) checks whether the port
> is allow to send at all.
> The inner expression has two conditions with a logical OR (line 6).
> The first condition triggers immediately on "rcvdPSSync", provided
> that the interval is not too short. There is no timer, but rather the
> interval from the last transmission is used.
The first condition does not trigger “immediately”. It is still governed by
the syncInterval, or at least 1/2 of it. So, if this ports syncInterval is set
to
1s and the upstream master’s is set to 125ms, the resulting sync rate from this
port would be 500ms. Since each port can have different sync intervals, even if
a sync message can be sent twice as fast as desired, there still must be a
timer.
The following presentation given at a 802.1AS working group meeting addresses
this
very issue.
http://www.ieee802.org/1/files/public/docs2014/as-noseworthy-sync-interval-0514-v01.pdf
As a result, the 802.1AS corrigendum 1 (802.1AS-Cor-1) has relaxed the
requirement
given in Anex B.2.2.
> See?
> Thanks,
> Richard
On 6/7/17, 12:16 PM, "Richard Cochran" <[email protected]> wrote:
On Wed, Jun 07, 2017 at 04:51:03PM +0000, 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
from
> ourselves and the port is enabled and the port is asCapable and the port
is
> in the master role.
No, you are really not paying attention.
Here is the condition on the lower left of Figure 10-8:
( ( ( rcvdPSSync &&
(currentTime lastSyncSentTime >= 0.5*syncInterval) &&
rcvdPSSyncPtr->localPortNumber != thisPort) )
|| ( (currentTime lastSyncSentTime >= syncInterval) &&
(lastRcvdPortNum != thisPort) ) )
&& portEnabled && pttPortEnabled && asCapable &&
selectedRole[thisPort] == MasterPort
Lets make this more readable:
1 (
2 (
3 (rcvdPSSync &&
4 (currentTime lastSyncSentTime >= 0.5*syncInterval) &&
5 rcvdPSSyncPtr->localPortNumber != thisPort)
6 ) || (
7 (currentTime lastSyncSentTime >= syncInterval) &&
8 (lastRcvdPortNum != thisPort)
9 )
10 )
11 && portEnabled
12 && pttPortEnabled
13 && asCapable
14 && selectedRole[thisPort] == MasterPort
The outer expression (lines 1, 10, and 11-14) checks whether the port
is allow to send at all.
The inner expression has two conditions with a logical OR (line 6).
The first condition triggers immediately on "rcvdPSSync", provided
that the interval is not too short. There is no timer, but rather the
interval from the last transmission is used.
See?
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
