[Linuxptp-devel] First two peer_delay measurements invalid

[Burkhard Ilsen]

Hello,

I tested two-step peer_delay measurement with two peers with a high nrate
ratio.
I noticed that the first two measured delays are erronous because the nrate
is not known yet, and 1.0 is assumed.
The next raw delay measurements are correct but the two first errors still
affect the filtered_delay.

I would like to discuss two issues regarding the function port_peer_delay().

1.
For the first measurement the nrate ratio cannot be calculated.
To avoid an erroneous measurement the calculation could be aborted if the
nrate is not valid,
e.g. by placing a "if(!p->nrate.ratio_valid) return;" between
port_nrate_calculate() and tsproc_update_delay().
The drawback is that peer_delay is not available after the first
delay_response.
I prefer a later but correct measurement instead of an incorrect value
affecting the following filtered values as well.

2.
For the second measurement the nrate ratio is calculated, after the delay
was calculated based on the old (invalid) nrate ratio.
The nrate ratio should be calculated before the delay,
e.g. by moving port_nrate_calculate() in front
of tsproc_set_clock_rate_ratio().
Please tell me if there is a reason for the current sequence of
calculations.

Best regards,
Burkhard

[Keller, Jacob E]

Post by Burkhard Ilsen
Hello,

Hi,

Post by Burkhard Ilsen
I tested two-step peer_delay measurement with two peers with a high
nrate ratio.
I noticed that the first two measured delays are erronous because the
nrate is not known yet, and 1.0 is assumed.
The next raw delay measurements are correct but the two first errors
still affect the filtered_delay.
I would like to discuss two issues regarding the function
port_peer_delay().
1.
For the first measurement the nrate ratio cannot be calculated.
To avoid an erroneous measurement the calculation could be aborted if
the nrate is not valid,
e.g. by placing a "if(!p->nrate.ratio_valid) return;" between
port_nrate_calculate() and tsproc_update_delay().
The drawback is that peer_delay is not available after the first
delay_response.
I prefer a later but correct measurement instead of an incorrect
value affecting the following filtered values as well.

I agree here, I definitely think we shouldn't calculate the values if
the rate is not known. It's slightly slower at the start but erroneous
values can impact the filtered values for some time.

Post by Burkhard Ilsen
2.
For the second measurement the nrate ratio is calculated, after the
delay was calculated based on the old (invalid) nrate ratio.
The nrate ratio should be calculated before the delay,
e.g. by moving port_nrate_calculate() in front
of tsproc_set_clock_rate_ratio().
Please tell me if there is a reason for the current sequence of
calculations.

I think we could change this but I'm not 100% sure of why the logic
exists today.

Thanks,
Jake

Post by Burkhard Ilsen
Best regards,
Burkhard
-------------------------------------------------------------------
-----------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Linuxptp-devel mailing list
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel

[Richard Cochran]

Post by Burkhard Ilsen
1.
For the first measurement the nrate ratio cannot be calculated.
To avoid an erroneous measurement the calculation could be aborted if the
nrate is not valid,
e.g. by placing a "if(!p->nrate.ratio_valid) return;" between
port_nrate_calculate() and tsproc_update_delay().
The drawback is that peer_delay is not available after the first
delay_response.

Yes, and it doesn't make sense to penalize users with reasonable local
clocks by removing the default 1.0 NRR.

Post by Burkhard Ilsen
I prefer a later but correct measurement instead of an incorrect value
affecting the following filtered values as well.

The 802.1-AS standard requires that local clocks be within 100 ppm and
that Pdelay turnaround time stays under 10 ms. That makes the worst
case error 1 usec. Ten milliseconds is already far out, and most
Linux embedded systems are surely under 1 ms. So we talking about an
error of 100 ns or less.

So IMHO we should let systems that have really bad local clocks take
the initial error, rather than allowing them to spoil normal systems.
After all, bad clocks are bad clocks.

Post by Burkhard Ilsen
2.
For the second measurement the nrate ratio is calculated, after the delay
was calculated based on the old (invalid) nrate ratio.
The nrate ratio should be calculated before the delay,
e.g. by moving port_nrate_calculate() in front
of tsproc_set_clock_rate_ratio().
Please tell me if there is a reason for the current sequence of
calculations.

I can't see any reason not to put port_nrate_calculate() first.

Thanks,
Richard

[Burkhard Ilsen]

Hi Richard, Jake,

many thanks for your replies.

Post by Richard Cochran

Post by Burkhard Ilsen
The drawback is that peer_delay is not available after the first
delay_response.

Yes, and it doesn't make sense to penalize users with reasonable local
clocks by removing the default 1.0 NRR.

I agree for AS compliant neighbors, still I want to throw in some

Post by Richard Cochran
The 802.1-AS standard requires that local clocks be within 100 ppm and
that Pdelay turnaround time stays under 10 ms. That makes the worst
case error 1 usec.

- The maximum peak-to-peak rate offset of two neighbors is 200 ppm,
which doubles the worst case error to 2 us.

- The neighborPropDelayThresh for gPTP is 800 ns, which leaves an
error margin of about 200 ns (for 100 m cables).

- As stated by Richard in another thread, there might be 1588 TC peers
(or not fully AS compliant TAB) using a controlled clock instead of
local clock for timestamping, which rockets the maximum rate offset to
max_frequency of the peer. This is what I observed during my tests.

But I guess at least after some pdelay_req this tweak is pointless anyhow.
I am fine with using default NRR of 1.0 although in opinion it is not optimal.

Regards,
Burkhard