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.

Background

IEEE 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 log₂ of the mean interval. The table below shows logMessageInterval values for some of the common PTP rates:

Announce message

IEEE 1588, clause 7.7.2.1 states:

Tests

The PFV will check that the actual interval between Announce messages is within 30% of the logMessageInterval field carried in the message.

Sync message

IEEE 1588, clause 7.7.2.1 states:

For unicast, the message rate is determined by the unicast negotiation.

Tests

When 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 message

IEEE 1588, clause 9.5.10 states:

Tests

TBC

Delay-Response message

IEEE 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:

1. The permitted time interval is defined in terms of the mean. This is different from Sync and Announce messages where each interval is bounded.

2. The maximum and minimum interval values specified by the Master in the Delay_Resp messages is relative to the Sync interval.

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:

1. Uniform random distribution (“should” be used for multicast; “may” be used for unicast)

Notes:

• The minimum interval is 0 seconds

• The maximum interval is 64 Sync intervals. This comes from the maximum mean of logMinDelayReq = logSyncInterval+5 so giving a maximum on the distribution of logSyncInterval+6

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/16^th 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/16^th of the Sync interval.

1. As soon as possible (“shall not” be used for multicast; “may” be used for unicast)

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 32^nd Sync after the last Delay_Req

Tests

TBC