linuxptp-users

[Linuxptp-users] negative delay issue

[Merlin He <mer...@gm...>]

hello team,

I found that port_nrate_calculate() save the first ingress1 before slave
clock jumping, if the offset of master and slave is too large, this may
results in an extremly small nrate_ratio value, and cause the nagative
delay issue.
so, is this a problem please?
what about port_nrate_calculate() sampling the first ingress1 until servo
entering lock state?
like this:
1028   if (tmv_is_zero(n->ingress1) && *clock_servo_state(p->clock) ==
SERVO_LOCKED*) {
1029     n->ingress1 = ingress;
1030     n->origin1 = origin;
1031     return;
1032   }

 734 ptp4l[61.809]: negative delay   -2267723
 735 ptp4l[61.809]: delay = (t2 - t3) * rr + (t4 - t1)
 736 ptp4l[61.809]: t2 - t3 =         +0
 737 ptp4l[61.809]: t4 - t1 =   -4535446
* 738 ptp4l[61.809]: rr = 0.000000003*

*Thanks*
*Merlin*

Re: [Linuxptp-users] negative delay issue

[Miroslav L. <mli...@re...>]

On Tue, Mar 28, 2023 at 10:24:47PM +0800, Merlin He wrote:
> hello team,
> 
> I found that port_nrate_calculate() save the first ingress1 before slave
> clock jumping, if the offset of master and slave is too large, this may
> results in an extremly small nrate_ratio value, and cause the nagative
> delay issue.
> so, is this a problem please?

There might be an assumption that the clock if running free. I'm not
very familiar with this feature.

> what about port_nrate_calculate() sampling the first ingress1 until servo
> entering lock state?
> like this:
> 1028   if (tmv_is_zero(n->ingress1) && *clock_servo_state(p->clock) ==
> SERVO_LOCKED*) {
> 1029     n->ingress1 = ingress;
> 1030     n->origin1 = origin;
> 1031     return;
> 1032   }

Another option might be calling port_nrate_initialize() on clock jump.

-- 
Miroslav Lichvar

Re: [Linuxptp-users] negative delay issue

[Merlin He <mer...@gm...>]

ok, i'm going to submit a patch for this issue

Miroslav Lichvar <mli...@re...> 于2023年3月29日周三 17:09写道：

> On Tue, Mar 28, 2023 at 10:24:47PM +0800, Merlin He wrote:
> > hello team,
> >
> > I found that port_nrate_calculate() save the first ingress1 before slave
> > clock jumping, if the offset of master and slave is too large, this may
> > results in an extremly small nrate_ratio value, and cause the nagative
> > delay issue.
> > so, is this a problem please?
>
> There might be an assumption that the clock if running free. I'm not
> very familiar with this feature.
>
> > what about port_nrate_calculate() sampling the first ingress1 until servo
> > entering lock state?
> > like this:
> > 1028   if (tmv_is_zero(n->ingress1) && *clock_servo_state(p->clock) ==
> > SERVO_LOCKED*) {
> > 1029     n->ingress1 = ingress;
> > 1030     n->origin1 = origin;
> > 1031     return;
> > 1032   }
>
> Another option might be calling port_nrate_initialize() on clock jump.
>
> --
> Miroslav Lichvar
>
>