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:

For each of the message types Announce, Sync, Delay_Req, and Pdelay_Req, the mean time interval between successive messages shall be represented as the logarithm to the base 2 of this time interval measured in seconds on the local clock of the device sending the message. 

The interpretation of the logMessageInterval depends on the message type. Except for Delay_Req messages, a node shall, with 90% confidence, issue messages with intervals within ±30% of the stated value of this attribute.

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:

The portDS.logAnnounceInterval shall specify the mean time interval between successive Announce messages, i.e., the announceInterval

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:

The portDS.logSyncInterval shall specify the mean time interval between successive Sync messages, i.e., the syncInterval, when transmitted as multicast messages

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:

The Follow_Up message should be transmitted as soon as possible after the transmission of the associated Sync message and shall be transmitted prior to the transmission of a subsequent Sync message to the same destination address

Tests

TBC

Delay-Response message

IEEE 1588, clause 7.7.2.4 states:

The portDS.logMinDelayReqInterval shall specify the minimum permitted mean time interval between successive Delay_Req messages … sent by a slave to a specific port on the master; see 9.5.11.2.

This value is determined and advertised by a master clock based on the ability of the master clock to process the Delay_Req message traffic. The value shall be an integer with the minimum value being portDS.logSyncInterval, i.e., at the same rate as Sync messages, and a maximum value of logSyncInterval+5, i.e., 1 Delay_Req message every 32 Sync messages

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:

Delay_Req messages shall be transmitted such that with 90% confidence, the mean value of the interval in seconds between message transmissions is not less than the value of the 2^{portDS.logMinDelayReqInterval} seconds

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)

Transmission times shall be selected such that the interval between successive Delay_Req messages is taken from a random distribution. Unless otherwise specified in the applicable PTP profile, the random distribution shall be a uniform random distribution with a minimum value of 0 and a maximum value of {2^{logMinDelayReqInterval+1}} seconds. A new random value for the transmission interval shall be computed for each message transmitted. The granularity of this distribution is implementation specific but shall be no greater than 2^{logSyncInterval─4} s. This option should be used when using the multicast communication model and may be used with a unicast model; see 7.3.1. For example, for a value of logMinDelayReqInteval = logSyncInterval (see 7.7.2.4), the distribution has a minimum value of 0, a maximum value of {2^{logSyncInterval+1}} = 2 syncInterval; i.e., the distribution has a maximum value of 2 syncInterval, and the resulting mean transmission interval is 1 syncInterval.

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)

Delay_Req messages should be transmitted as soon as possible following the receipt of a Sync message. This option may be used with a unicast model; see 7.3.1. It shall not be used when using the multicast model unless specified in the applicable PTP profile

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