Versions Compared
Key
- This line was added.
- This line was removed.
- Formatting was changed.
What tests does PFV perform on message rates / inter-message intervals?
Panel | ||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
PFV can test both average message rates and inter-message intervals. The tests performed are dependent on the message type. The sections below detail the tests performed for each message type as well as references to relevant standards. BackgroundIEEE 1588, clause 7.7.2.1 states:
The mean time interval is carried in the PTP common header in a field called logMessageInterval. This is log2 of the mean interval. The table below shows logMessageInterval values for some of the common PTP rates:
Announce messageIEEE 1588, clause 7.7.2.1 states:
TestsThe PFV will check that the actual interval between Announce messages is within 30% of the logMessageInterval field carried in the message |
...
Expected rates / intervals
The expected message
Tests
Standards
Sync message
Expected rates / intervals
Tests
Standards
Delay-Response message
Expected rates / intervals
Tests
...
. Sync messageIEEE 1588, clause 7.7.2.1 states:
For unicast, the message rate is determined by the unicast negotiation. TestsWhen multicast messaging is being used, the PFV will check that the actual interval between Sync messages is within 30% of the logMessageInterval field carried in the message. When unicast messaging is being used, the PFV has no direct mechanism to determine what rate has been negotiated (this information is not carried in any PTP messages). The PFV calculates a message rate based on the first N sync messages received (rounded to one of the 1588 message rates shown in the table above). This is then used as the expected rate / interval. The actual interval between Sync messages is then checked to confirm that it is within 30% of the calculated interval. Follow-Up messageIEEE 1588, clause 9.5.10 states:
TestsTBC Delay-Response messageIEEE 1588, clause 7.7.2.4 states:
The portDS.logMinDelayReqInterval is not a field carried in the Delay-Req message. This is an internal dataset field. It gets populated from the logMessageInterval carried in Delay_Resp messages from the master. There are two important things to note here:
IEEE 1588, clause 9.5.11.2 states:
The logMessageInterval field is not used for Delay_Req messages i.e. there is nothing in the packet that defines the expected message rate. In multicast, the message rate is set by the Master which populates the logMessageInterval in Delay_Response messages to specify the rate to be used by the Slave. For unicast, the rate is set by the unicast negotiation mechanism. Clause 9.5.11.2 also specifies two timing options:
Notes:
This means that the interval between Delay_Req messages varies randomly. The range of interval is from 0 to two times the logMinDelayRequest interval. The mean value of the interval however, must be less than minDelayRequestInterval. The maximum granularity of buckets in the distribution is 1/16th of the Sync interval. Since the granularity is specified as a maximum, this implies that the difference in any two intervals between pairs of messages must be less than or equal to 1/16th of the Sync interval.
Since the Delay-Req rate can’t be greater than the Sync rate, then it is assumed that “as soon as possible” means as soon as possible after seeing a Sync but at a given rate e.g. as soon as possible after seeing the 32nd Sync after the last Delay_Req TestsTBC |
Related articles
Filter by label (Content by label) | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|
|
On this page:
Table of Contents |
---|