linuxptp-users

[Linuxptp-users] Slave's clock servo not going to locked state

[Aditya V. <adi...@5g...>]

Hi fellow linuxptp users,

I want to know what might be the reason for the slave's clock servo state
not going to locked state. State always oscillates between S0 and S1. Here
are my setup details.

a) My FPGA card acting as a ptp master
b) Intel NIC as a ptp slave
c) I'm doing two step, HW timestamping
d) I'm using default config files for both master and slave(attaching them
for reference)

The slave's servo state wouldn't get locked after running the master and
slave. What can be the potential reason for that?

Please let me know if any further information is required.

Regards,
Aditya

-- 


Disclaimer:- This footer text is to convey that this email is sent by one 
of the users of IITH. So, do not mark it as SPAM.

Re: [Linuxptp-users] Slave's clock servo not going to locked state

[Aditya V. <adi...@5g...>]

Hi All,
In other words, what could be the reason for slave's servo clock state not
going to locked state?
Literally stuck at this point. Any inputs will help me in setting the
direction for debugging.

-Aditya

On Fri, Jan 13, 2023 at 12:32 PM Aditya Venu <adi...@5g...>
wrote:

> Hi fellow linuxptp users,
>
> I want to know what might be the reason for the slave's clock servo state
> not going to locked state. State always oscillates between S0 and S1. Here
> are my setup details.
>
> a) My FPGA card acting as a ptp master
> b) Intel NIC as a ptp slave
> c) I'm doing two step, HW timestamping
> d) I'm using default config files for both master and slave(attaching them
> for reference)
>
> The slave's servo state wouldn't get locked after running the master and
> slave. What can be the potential reason for that?
>
> Please let me know if any further information is required.
>
> Regards,
> Aditya
>

-- 


Disclaimer:- This footer text is to convey that this email is sent by one 
of the users of IITH. So, do not mark it as SPAM.

Re: [Linuxptp-users] Slave's clock servo not going to locked state

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

On Mon, Jan 16, 2023 at 12:17:33PM +0530, Aditya Venu via Linuxptp-users wrote:
> Hi All,
> In other words, what could be the reason for slave's servo clock state not
> going to locked state?

Clock stepping would be one example.

> Literally stuck at this point. Any inputs will help me in setting the
> direction for debugging.

If you provided your config, you might get a better advice.

-- 
Miroslav Lichvar

Re: [Linuxptp-users] Slave's clock servo not going to locked state

[Aditya V. <adi...@5g...>]

Hi Miroslav,

Attaching the slave and master's config files below.

On Mon, Jan 16, 2023 at 3:38 PM Miroslav Lichvar <mli...@re...>
wrote:

> On Mon, Jan 16, 2023 at 12:17:33PM +0530, Aditya Venu via Linuxptp-users
> wrote:
> > Hi All,
> > In other words, what could be the reason for slave's servo clock state
> not
> > going to locked state?
>
> Clock stepping would be one example.
>
> > Literally stuck at this point. Any inputs will help me in setting the
> > direction for debugging.
>
> If you provided your config, you might get a better advice.
>
> --
> Miroslav Lichvar
>
>

-- 


Disclaimer:- This footer text is to convey that this email is sent by one 
of the users of IITH. So, do not mark it as SPAM.

Re: [Linuxptp-users] Slave's clock servo not going to locked state

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

On Mon, Jan 16, 2023 at 03:40:20PM +0530, Aditya Venu wrote:
> Hi Miroslav,
> 
> Attaching the slave and master's config files below.

Your config sets step_threshold to 2 microseconds, which is less than
the offsets measured by the client and causes it to constantly step.
Such a poor performance with hardware timestamping indicates a problem
in the network (e.g. have the switches enabled PTP support?).

-- 
Miroslav Lichvar

Re: [Linuxptp-users] Slave's clock servo not going to locked state

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

On Fri, Jan 13, 2023 at 12:32:21PM +0530, Aditya Venu via Linuxptp-users wrote:

> d) I'm using default config files for both master and slave(attaching them
> for reference)

You are NOT using the default configuration.
You changed step_threshold from the default of zero.
This is the reason for the oscillation between S0 and S1.

Thanks,
Richard

Re: [Linuxptp-users] Slave's clock servo not going to locked state

[Aditya V. <adi...@5g...>]

Hi Richard,
Corrected step_threshold to 0 and observed that slave's servo state going
to locked state.

But the offset is continuously increasing..

ptp4l[12074.007]: master offset     -31076 s2 freq      -1 path delay
 4145
ptp4l[12075.008]: master offset     -46783 s2 freq      -1 path delay
 4997
ptp4l[12076.008]: master offset     -60785 s2 freq      -1 path delay
 4145
ptp4l[12077.008]: master offset     -76475 s2 freq      -1 path delay
 4977
ptp4l[12078.008]: master offset     -92161 s2 freq      -1 path delay
 5809
ptp4l[12079.008]: master offset    -107002 s2 freq      -1 path delay
 5809
ptp4l[12080.008]: master offset    -121631 s2 freq      -1 path delay
 5596
ptp4l[12081.012]: master offset    -136760 s2 freq      -1 path delay
 5809
ptp4l[12082.008]: master offset    -151538 s2 freq      -1 path delay
 5809
ptp4l[12083.008]: master offset    -166173 s2 freq      -1 path delay
 5596
ptp4l[12084.009]: master offset    -181008 s2 freq      -1 path delay
 5596
ptp4l[12085.008]: master offset    -194884 s2 freq      -1 path delay
 4624
ptp4l[12086.008]: master offset    -208806 s2 freq      -1 path delay
 3698
ptp4l[12087.008]: master offset    -223651 s2 freq      -1 path delay
 3698
ptp4l[12088.008]: master offset    -238042 s2 freq      -1 path delay
 3241
ptp4l[12089.008]: master offset    -252481 s2 freq      -1 path delay
 2838
ptp4l[12090.009]: master offset    -267209 s2 freq      -1 path delay
 2722
ptp4l[12091.008]: master offset    -282064 s2 freq      -1 path delay
 2722
ptp4l[12092.009]: master offset    -296912 s2 freq      -1 path delay
 2722
ptp4l[12093.009]: master offset    -310850 s2 freq      -1 path delay
 1819
ptp4l[12094.009]: master offset    -327346 s2 freq      -1 path delay
 3463
ptp4l[12095.009]: master offset    -342191 s2 freq      -1 path delay
 3463
ptp4l[12096.009]: master offset    -356094 s2 freq      -1 path delay
 2521
ptp4l[12097.009]: master offset    -372022 s2 freq      -1 path delay
 3604
ptp4l[12098.009]: master offset    -386867 s2 freq      -1 path delay
 3604
ptp4l[12099.009]: master offset    -401705 s2 freq      -1 path delay
 3604
ptp4l[12100.009]: master offset    -416547 s2 freq      -1 path delay
 3604

Can you please help me in knowing what might be the reason for this?

-Aditya

On Tue, Jan 17, 2023 at 3:05 PM Richard Cochran <ric...@gm...>
wrote:

> On Fri, Jan 13, 2023 at 12:32:21PM +0530, Aditya Venu via Linuxptp-users
> wrote:
>
> > d) I'm using default config files for both master and slave(attaching
> them
> > for reference)
>
> You are NOT using the default configuration.
> You changed step_threshold from the default of zero.
> This is the reason for the oscillation between S0 and S1.
>
> Thanks,
> Richard
>

-- 


Disclaimer:- This footer text is to convey that this email is sent by one 
of the users of IITH. So, do not mark it as SPAM.

Re: [Linuxptp-users] Slave's clock servo not going to locked state

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

On Tue, Jan 17, 2023 at 03:46:29PM +0530, Aditya Venu via Linuxptp-users wrote:
> Corrected step_threshold to 0 and observed that slave's servo state going
> to locked state.
> 
> But the offset is continuously increasing..

It might be a driver issue. What does phc_ctl /dev/ptp0 (or the
corresponding device) print?

-- 
Miroslav Lichvar

Re: [Linuxptp-users] Slave's clock servo not going to locked state

[Aditya V. <adi...@5g...>]

Hi Miroslav,

*Below is the output for master*:








*sudo ./phc_ctl /dev/ptp2phc_ctl[14216.300]: capabilities:  999999999
maximum frequency adjustment (ppb)  0 programable alarms  0 external time
stamp channels  0 programmable periodic signals  doesn't have pulse per
second support*

*And this is for slave*:








*sudo ./phc_ctl /dev/ptp0phc_ctl[14301.195]: capabilities:  999999999
maximum frequency adjustment (ppb)  0 programable alarms  2 external time
stamp channels  2 programmable periodic signals  has pulse per second
support*

On Tue, Jan 17, 2023 at 4:11 PM Miroslav Lichvar <mli...@re...>
wrote:

> On Tue, Jan 17, 2023 at 03:46:29PM +0530, Aditya Venu via Linuxptp-users
> wrote:
> > Corrected step_threshold to 0 and observed that slave's servo state going
> > to locked state.
> >
> > But the offset is continuously increasing..
>
> It might be a driver issue. What does phc_ctl /dev/ptp0 (or the
> corresponding device) print?
>
> --
> Miroslav Lichvar
>
>

-- 


Disclaimer:- This footer text is to convey that this email is sent by one 
of the users of IITH. So, do not mark it as SPAM.

Re: [Linuxptp-users] Slave's clock servo not going to locked state

[Aditya V. <adi...@5g...>]

Hi Miroslav,
Any suggestions to the above issue please?!

On Tue, Jan 17, 2023 at 4:21 PM Aditya Venu <adi...@5g...>
wrote:

> Hi Miroslav,
>
> *Below is the output for master*:
>
>
>
>
>
>
>
>
> *sudo ./phc_ctl /dev/ptp2phc_ctl[14216.300]: capabilities:  999999999
> maximum frequency adjustment (ppb)  0 programable alarms  0 external time
> stamp channels  0 programmable periodic signals  doesn't have pulse per
> second support*
>
> *And this is for slave*:
>
>
>
>
>
>
>
>
> *sudo ./phc_ctl /dev/ptp0phc_ctl[14301.195]: capabilities:  999999999
> maximum frequency adjustment (ppb)  0 programable alarms  2 external time
> stamp channels  2 programmable periodic signals  has pulse per second
> support*
>
> On Tue, Jan 17, 2023 at 4:11 PM Miroslav Lichvar <mli...@re...>
> wrote:
>
>> On Tue, Jan 17, 2023 at 03:46:29PM +0530, Aditya Venu via Linuxptp-users
>> wrote:
>> > Corrected step_threshold to 0 and observed that slave's servo state
>> going
>> > to locked state.
>> >
>> > But the offset is continuously increasing..
>>
>> It might be a driver issue. What does phc_ctl /dev/ptp0 (or the
>> corresponding device) print?
>>
>> --
>> Miroslav Lichvar
>>
>>

-- 


Disclaimer:- This footer text is to convey that this email is sent by one 
of the users of IITH. So, do not mark it as SPAM.

Re: [Linuxptp-users] Slave's clock servo not going to locked state

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

On Mon, Jan 23, 2023 at 11:54:25AM +0530, Aditya Venu wrote:
> Any suggestions to the above issue please?!

I don't see anything wrong in the phc2ctl output, but your ptp4l
output shows frequency stuck at -1, which makes no sense to me.
Does it work if you enable SW timestamping on client?
What NIC, kernel, and linuxptp version is it using?

-- 
Miroslav Lichvar

Re: [Linuxptp-users] Slave's clock servo not going to locked state

[Aditya V. <adi...@5g...>]

*Does it work if you enable SW timestamping on the client?*

I'm pasting the output below with HW timestamping at master and SW
timestamping on client:
























*ptp4l[641.740]: port 1: INITIALIZING to LISTENING on
INIT_COMPLETEptp4l[641.740]: port 0: INITIALIZING to LISTENING on
INIT_COMPLETEptp4l[645.780]: selected local clock b49691.fffe.a72050 as
best masterptp4l[646.596]: port 1: new foreign master
000a35.fffe.000002-1ptp4l[648.596]: selected best master clock
000a35.fffe.000002ptp4l[648.596]: port 1: LISTENING to UNCALIBRATED on
RS_SLAVEptp4l[649.721]: rms 36994812072 max 36994830538 freq -1000000 +/-
0 delay 21137 +/- 1465 ptp4l[650.722]: rms 36994771193 max 36994793561 freq
-1000000 +/-   0 delay 22453 +/- 276 ptp4l[651.722]: rms 36994737242 max
36994749517 freq -1000000 +/-   0 delay 21996 +/- 680 ptp4l[652.722]: rms
36994709493 max 36994747491 freq -1000000 +/-   0 delay 21561 +/- 507
ptp4l[653.723]: rms 36994672571 max 36994686986 freq -1000000 +/-   0 delay
21531 +/- 761 ptp4l[654.723]: rms 36994644178 max 36994694356 freq -1000000
+/-   0 delay 22666 +/- 223 ptp4l[655.723]: rms 36994602115 max 36994617235
freq -1000000 +/-   0 delay 20980 +/- 873 ptp4l[656.724]: rms 36994572174
max 36994588866 freq -1000000 +/-   0 delay 22051 +/- 959 ptp4l[657.724]:
rms 36994536525 max 36994551653 freq -1000000 +/-   0 delay 23524 +/- 300
ptp4l[658.724]: rms 36994503810 max 36994522571 freq -1000000 +/-   0 delay
22821 +/- 921 ptp4l[659.725]: rms 36994470556 max 36994531559 freq -1000000
+/-   0 delay 21131 +/- 2000 ptp4l[660.725]: rms 36994442536 max
36994473073 freq -1000000 +/-   0 delay 20562 +/- 964 ptp4l[661.726]: rms
36994401104 max 36994416693 freq -1000000 +/-   0 delay 22141 +/- 972
ptp4l[662.726]: rms 36994394078 max 36994606592 freq -1000000 +/-   0 delay
22251 +/- 227 ptp4l[663.726]: rms 36994335309 max 36994354631 freq -1000000
+/-   0 delay 22678 +/- 310 ptp4l[664.727]: rms 36994297566 max 36994315433
freq -1000000 +/-   0 delay 24249 +/- 610 ptp4l[665.727]: rms 36994264080
max 36994280858 freq -1000000 +/-   0 delay 24312 +/- 391 ptp4l[666.727]:
rms 36994231842 max 36994246342 freq -1000000 +/-   0 delay 23605 +/- 109 *


*What NIC, kernel, and linuxptp version is it using?*
NIC: The client NIC is Intel XXV710
Kernel: 5.4.0-132-generic
linuxptp version: 2.0

We are running the master on an FPGA card with PCIe interface. The
timestamping logic is implemented in FPGA and driver and ptp4l are running
on x86.


On Mon, Jan 23, 2023 at 2:03 PM Miroslav Lichvar <mli...@re...>
wrote:

> On Mon, Jan 23, 2023 at 11:54:25AM +0530, Aditya Venu wrote:
> > Any suggestions to the above issue please?!
>
> I don't see anything wrong in the phc2ctl output, but your ptp4l
> output shows frequency stuck at -1, which makes no sense to me.
> Does it work if you enable SW timestamping on client?
> What NIC, kernel, and linuxptp version is it using?
>
> --
> Miroslav Lichvar
>
>

-- 


Disclaimer:- This footer text is to convey that this email is sent by one 
of the users of IITH. So, do not mark it as SPAM.

Re: [Linuxptp-users] Slave's clock servo not going to locked state

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

On Mon, Jan 23, 2023 at 03:54:27PM +0530, Aditya Venu wrote:
> *Does it work if you enable SW timestamping on the client?*
> 
> I'm pasting the output below with HW timestamping at master and SW
> timestamping on client:

It seems the first clock step is disabled. Did you change
first_step_threshold in your config?

-- 
Miroslav Lichvar

Re: [Linuxptp-users] Slave's clock servo not going to locked state

[Aditya V. <adi...@5g...>]

*It seems the first clock step is disabled. Did you
changefirst_step_threshold in your config?*

It is set to the default value itself(0.00002).

On Mon, Jan 23, 2023 at 4:31 PM Miroslav Lichvar <mli...@re...>
wrote:

> On Mon, Jan 23, 2023 at 03:54:27PM +0530, Aditya Venu wrote:
> > *Does it work if you enable SW timestamping on the client?*
> >
> > I'm pasting the output below with HW timestamping at master and SW
> > timestamping on client:
>
> It seems the first clock step is disabled. Did you change
> first_step_threshold in your config?
>
> --
> Miroslav Lichvar
>
>

-- 


Disclaimer:- This footer text is to convey that this email is sent by one 
of the users of IITH. So, do not mark it as SPAM.

Re: [Linuxptp-users] Slave's clock servo not going to locked state

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

On Mon, Jan 23, 2023 at 04:36:11PM +0530, Aditya Venu wrote:
> *It seems the first clock step is disabled. Did you
> changefirst_step_threshold in your config?*
> 
> It is set to the default value itself(0.00002).

I have no explanation. Sorry.

-- 
Miroslav Lichvar

Re: [Linuxptp-users] Slave's clock servo not going to locked state

[Aditya V. <adi...@5g...>]

Cloned the latest git repo and tried the same. Getting single digit ns
offset, frequency with some values and clock servo to locked state.

Thanks for your time :)

-Aditya

On Mon, Jan 23, 2023 at 4:41 PM Miroslav Lichvar <mli...@re...>
wrote:

> On Mon, Jan 23, 2023 at 04:36:11PM +0530, Aditya Venu wrote:
> > *It seems the first clock step is disabled. Did you
> > changefirst_step_threshold in your config?*
> >
> > It is set to the default value itself(0.00002).
>
> I have no explanation. Sorry.
>
> --
> Miroslav Lichvar
>
>

-- 


Disclaimer:- This footer text is to convey that this email is sent by one 
of the users of IITH. So, do not mark it as SPAM.