linuxptp-users

[Linuxptp-users] Raw socket close issue

[ramesh t <ram...@ya...>]

Hello,

Have ptp4l running in BC mode providing clock to connected TestUnits (via port 2) and syncing clock from BC/GM (via port 1)

Did few more iterations of testing (ptp4l in BC mode) by doing ifconfig down. Observing PTP4l reporting below error in port 1 connected to BC/GM

ptp4l: [704774.649] port 1: announce timeout
ptp4l: [704774.649] port 1: SLAVE to MASTER on ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES

On debugging further, when port 2 is configured for down state, we call raw_close in port_disable, to close the open FDs. This closure is taking around 600ms to 800ms. This in turn impacts handling on accounce packets on port1 connected to BC/GM.

Can you please suggest how we can resolve this issue?

regards,
Ramesh 

Re: [Linuxptp-users] Raw socket close issue

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

On Wed, Mar 16, 2022 at 06:23:23PM +0000, ramesh t via Linuxptp-users wrote:
> ptp4l: [704774.649] port 1: announce timeout
> ptp4l: [704774.649] port 1: SLAVE to MASTER on ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES
> 
> On debugging further, when port 2 is configured for down state, we call raw_close in port_disable, to close the open FDs. This closure is taking around 600ms to 800ms. This in turn impacts handling on accounce packets on port1 connected to BC/GM.
> 
> Can you please suggest how we can resolve this issue?

Maybe some optimization could be implemented in the kernel to shorten
that time. I don't know why it takes so long. What is your
logAnnounceInterval and announceReceiptTimeout? Could they be
increased?

-- 
Miroslav Lichvar

Re: [Linuxptp-users] Raw socket close issue

[ramesh t <ram...@ya...>]

Hello Miroslav Lichvar,

Please find the value of ptp config as per 8275.1 standards.

logAnnounceInterval     -3
announceReceiptTimeout  3

We can't increase beyond the above values.

regards,
Ramesh

On Thursday, March 17, 2022, 04:10:38 PM GMT+5:30, Miroslav Lichvar <mli...@re...> wrote: 





On Wed, Mar 16, 2022 at 06:23:23PM +0000, ramesh t via Linuxptp-users wrote:

> ptp4l: [704774.649] port 1: announce timeout
> ptp4l: [704774.649] port 1: SLAVE to MASTER on ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES
> 
> On debugging further, when port 2 is configured for down state, we call raw_close in port_disable, to close the open FDs. This closure is taking around 600ms to 800ms. This in turn impacts handling on accounce packets on port1 connected to BC/GM.
> 
> Can you please suggest how we can resolve this issue?


Maybe some optimization could be implemented in the kernel to shorten
that time. I don't know why it takes so long. What is your
logAnnounceInterval and announceReceiptTimeout? Could they be
increased?

-- 
Miroslav Lichvar

Re: [Linuxptp-users] Raw socket close issue

[ramesh t <ram...@ya...>]

Hello Miroslav Lichvar,

Tried as suggested, observed below error.
ptp4l: [806352.926] clockcheck: clock jumped backward or running slower than expected!

So set sanity_freq_limit to 0, but still observing errors:

ptp4l: [806913.536] timed out while polling for tx timestamp
ptp4l: [806913.536] increasing tx_timestamp_timeout may correct this issue, but it is likely caused by a driver bug
ptp4l: [806913.536] port 2: send sync failed
ptp4l: [806913.536] port 2: MASTER to FAULTY on FAULT_DETECTED (FT_UNSPECIFIED)
ptp4l: [806913.922] port 1: received link status notification
ptp4l: [806913.922] port 2: received link status notification
ptp4l: [806913.922] port 2: link down
ptp4l: [806913.922] port 2: received link status notification DOWN
ptp4l: [806913.922] selected local clock 40a6b7.fffe.0da261 as best master
ptp4l: [806913.922] port 1: assuming the grand master role
ptp4l: [806913.922] port 1: SLAVE to GRAND_MASTER on RS_GRAND_MASTER
ptp4l: [806913.922] selected best master clock 000580.fffe.07cc8a
ptp4l: [806913.922] updating UTC offset to 37
ptp4l: [806913.922] port 1: GRAND_MASTER to UNCALIBRATED on RS_SLAVE

Not sure if any other parameter needs to be changed.

regards,
Ramesh

On Thursday, March 17, 2022, 05:23:15 PM GMT+5:30, ramesh t via Linuxptp-users <lin...@li...> wrote: 





Hello Miroslav Lichvar,

Please find the value of ptp config as per 8275.1 standards.

logAnnounceInterval     -3
announceReceiptTimeout  3

We can't increase beyond the above values.

regards,
Ramesh

On Thursday, March 17, 2022, 04:10:38 PM GMT+5:30, Miroslav Lichvar <mli...@re...> wrote: 





On Wed, Mar 16, 2022 at 06:23:23PM +0000, ramesh t via Linuxptp-users wrote:

> ptp4l: [704774.649] port 1: announce timeout
> ptp4l: [704774.649] port 1: SLAVE to MASTER on ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES
> 
> On debugging further, when port 2 is configured for down state, we call raw_close in port_disable, to close the open FDs. This closure is taking around 600ms to 800ms. This in turn impacts handling on accounce packets on port1 connected to BC/GM.
> 
> Can you please suggest how we can resolve this issue?


Maybe some optimization could be implemented in the kernel to shorten
that time. I don't know why it takes so long. What is your
logAnnounceInterval and announceReceiptTimeout? Could they be
increased?

-- 
Miroslav Lichvar





_______________________________________________
Linuxptp-users mailing list
Lin...@li...
https://lists.sourceforge.net/lists/listinfo/linuxptp-users