Re: [Linuxptp-users] negative delay issue
ok, i'm going to submit a patch for this issue
Miroslav Lichvar 于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
>
>
___
Linuxptp-users mailing list
Linuxptp-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-users
[Linuxptp-users] negative delay issue
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.3*
*Thanks*
*Merlin*
___
Linuxptp-users mailing list
Linuxptp-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-users
Re: [Linuxptp-users] Offset details
hi ravi, I think there is no such api, you can only get ptp status through management messages ravi dandamudi 于2023年3月28日周二 15:34写道： > Hi All, > > Just wanted to know, Is there any other way to get offset value without > using PMC command. > > Any APIs are available? > > Thanks > Ravi > > On Tue, 28 Mar, 2023, 12:38 pm Vladimir Oltean, wrote: > >> On Tue, Mar 28, 2023 at 01:42:05PM +0800, Merlin He wrote: >> > Richard Cochran 于2023年3月28日周二 11:27写道： >> > > On Tue, Mar 28, 2023 at 10:57:43AM +0800, merlinhe wrote: >> > > > Hi Miroslav, >> > > > >> > > > We use Synopsys's IP, the driver is the same as stmmac >> > > >> > > Yeah, the stmmac driver is crazy bad. >> > > >> > > It is not clear to me whether setting the time when enabling time >> > > stamping is actually required by the IP core or not. >> > > >> > > But even if it were required, still the driver should attempt to keep >> > > the MAC unaltered by reprogramming the current MAC time. >> > > >> > >> > Hi Richard, >> > Thank you, We are going to report this issue to Synopsys >> >> Problem already solved, please use a kernel which tracks linux-stable. >> >> https://github.com/torvalds/linux/commit/a6da2bbb0005e6b4909472962c9d0af29e75dd06 >> >> >> ___ >> Linuxptp-users mailing list >> Linuxptp-users@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/linuxptp-users >> > ___ Linuxptp-users mailing list Linuxptp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-users
Re: [Linuxptp-users] rogue peer delay response caused by port_synchronize()
Hi Vladimir, Great help, thank you very much, We will consider upgrading the kernel. Vladimir Oltean 于2023年3月28日周二 15:04写道： > On Tue, Mar 28, 2023 at 01:42:05PM +0800, Merlin He wrote: > > Richard Cochran 于2023年3月28日周二 11:27写道： > > > On Tue, Mar 28, 2023 at 10:57:43AM +0800, merlinhe wrote: > > > > Hi Miroslav, > > > > > > > > We use Synopsys's IP, the driver is the same as stmmac > > > > > > Yeah, the stmmac driver is crazy bad. > > > > > > It is not clear to me whether setting the time when enabling time > > > stamping is actually required by the IP core or not. > > > > > > But even if it were required, still the driver should attempt to keep > > > the MAC unaltered by reprogramming the current MAC time. > > > > > > > Hi Richard, > > Thank you, We are going to report this issue to Synopsys > > Problem already solved, please use a kernel which tracks linux-stable. > > https://github.com/torvalds/linux/commit/a6da2bbb0005e6b4909472962c9d0af29e75dd06 > ___ Linuxptp-users mailing list Linuxptp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-users
Re: [Linuxptp-users] rogue peer delay response caused by port_synchronize()
Hi Richard, Thank you, We are going to report this issue to Synopsys Richard Cochran 于2023年3月28日周二 11:27写道： > On Tue, Mar 28, 2023 at 10:57:43AM +0800, merlinhe wrote: > > Hi Miroslav, > > > > We use Synopsys's IP, the driver is the same as stmmac > > Yeah, the stmmac driver is crazy bad. > > It is not clear to me whether setting the time when enabling time > stamping is actually required by the IP core or not. > > But even if it were required, still the driver should attempt to keep > the MAC unaltered by reprogramming the current MAC time. > > Thanks, > Richard > ___ Linuxptp-users mailing list Linuxptp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-users
