Hi Richard, Jake,
many thanks for your replies.
>> 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
On Mon, Apr 03, 2017 at 03:52:13PM +0200, Burkhard Ilsen wrote:
> 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
>
On Mon, 2017-04-03 at 15:52 +0200, Burkhard Ilsen wrote:
> Hello,
>
Hi,
> 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
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
