[Linuxptp-devel] Peer delay regression in v1.6

[Richard C. <ric...@gm...>]

We figure the neighbor rate ratio in port_nrate_calculate():

	delta t3 / delta t4  =  peer_interval / local_interval

Originally the peer delay was figured like this:

	pd = tmv_sub(tmv_sub(t4, t1), tmv_sub(t3, t2));

Since t4-t1 are local, and t3-t2 are from the peer, there will be an
error if the local and peer are not syntonized.

In commit bd001fde (in v1.5) Delio changed the peer delay calculation:

	adj_t41 = p->nrate.ratio * tmv_dbl(tmv_sub(t4, t1));
	pd = tmv_sub(dbl_tmv(adj_t41), tmv_sub(t3, t2));

This converts the local interval t4-t1 into the time base of the peer,
and so the peer delay is then expressed with the peer's frequency.
This follows clause 11.2.15.2.4 from IEEE 802.1-AS.

Now, with the tsproc in place, the peer delay figured like this:

	/* delay = ((t2 - t3) * rr + (t4 - t1)) / 2 */

	t23 = tmv_sub(tsp->t2, tsp->t3);
	if (tsp->clock_rate_ratio != 1.0)
		t23 = dbl_tmv(tmv_dbl(t23) * tsp->clock_rate_ratio);
	t41 = tmv_sub(tsp->t4, tsp->t1);
	delay = tmv_div(tmv_add(t23, t41), 2);

The ratio peer/local is applied to t3-t2, but these are peer time
stamps to begin with!  That scaling is wrong, and even if the code did
(t2-t3)*(1/rr), it would still change the meaning of the peer delay,
since it would be then expressed in the local time base.

[ The tsproc code is correct for figuring E2E delay, assuming that
  tsp->clock_rate_ratio is GM/local, since t3-t2 is a local time
  interval. ]

We need to fix this and make a new release soon, since the error in
the peer delay will impact some configurations, especially gPTP with 
free running local clocks.  In order to fix this, I am thinking of
adding a e2e/p2p flag to tsproc_create.  When set to p2p, the formula

	delay = ((t2 - t3) + rr * (t4 - t1)) / 2

would be used.  That would restore the behavior of v1.5.

Thoughts?

Thanks,
Richard