Commit a44cadcb authored by Davide Ciminaghi's avatar Davide Ciminaghi Committed by Alessandro Rubini

compliance, 11.3, d: take delay_resp cf into account

11.3 d says:

Upon receipt of the Delay_Resp message by the slave:

1) If the received Sync message indicated that a Follow_Up message will not
   be received, the <meanPathDelay> shall be computed as:
   <meanPathDelay> = [(t2 - t3) + (receiveTimestamp of Delay_Resp message -
   originTimestamp of Sync message) -
   correctionField of Sync message -
   correctionField of Delay_Resp message]/2.
2) If the received Sync message indicated that a Follow_Up message will be
   received, the <meanPathDelay> shall be computed as:
   <meanPathDelay> = [(t2 - t3) + (receiveTimestamp of Delay_Resp message -
   preciseOriginTimestamp of Follow_Up message) -
   correctionField of Sync message -
   correctionField of Follow_Up message -
   correctionField of Delay_Resp message]/2.

We assume that:

t1 = originTimestamp of Sync message (one step) or
t1 = preciseOriginTimestamp of Follow_Up message (two steps)

      and

t4 = receiveTimestamp of Delay_Resp message

wich is true for masters not supporting sub-nanosecond
timestamps (we don't support sub-ns precision via standard protocol, so the
assumption should be true for us).

As sync (or followup) arrives, we calculate m_to_s_dly, which is:

t2 - t1 - cf_sync - cf_followup

When delay_resp arrives, we calculate s_to_m_dly, which is:

t4 - t3 - cf_delay_resp

So [(m_to_s_dly + s_to_m_dly) / 2] should be equal to:

(t2 - t3 + t4 - t1 - cf_sync - cf_followup - cf_delay_resp) / 2

which looks like the 11.3 d expression for mean path delay
(note that cf_followup is zero for a one-step master).

To get this result, we just save the delay_resp cf to ppi->cField.
parent c371afa5
......@@ -62,6 +62,8 @@ void pp_servo_got_sync(struct pp_instance *ppi)
/*
* calc 'master_to_slave_delay', removing the correction field
* added by transparent clocks in the path.
* cField contains the sum of sync and followup messages
* correctionField(s)
*/
sub_TimeInternal(m_to_s_dly, &ppi->t2, &ppi->t1);
sub_TimeInternal(m_to_s_dly, m_to_s_dly, &ppi->cField);
......@@ -158,7 +160,7 @@ void pp_servo_got_resp(struct pp_instance *ppi)
return;
}
/*
* calc 'slave_to_master_delay', removing the correction field
* calc 'slave_to_master_delay', removing delay_resp correction field
* added by transparent clocks in the path.
*/
sub_TimeInternal(s_to_m_dly, &ppi->t4, &ppi->t3);
......
......@@ -67,12 +67,9 @@ int pp_slave(struct pp_instance *ppi, unsigned char *pkt, int plen)
&& (ppi->flags & PPI_FLAG_FROM_CURRENT_PARENT)) {
to_TimeInternal(&ppi->t4, &resp.receiveTimestamp);
/*
* FIXME: how is correctionField handled in t3/t4?
* I think the master should consider it when
* generating t4, and report back a modified t4
*/
/* Save delay resp cf in ppi->cField */
cField_to_TimeInternal(&ppi->cField,
hdr->correctionfield);
if (pp_hooks.handle_resp)
e = pp_hooks.handle_resp(ppi);
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment