ptp4l tx timestamp timeout

キャンセル
次の結果を表示 
表示  限定  | 次の代わりに検索 
もしかして: 

ptp4l tx timestamp timeout

10,504件の閲覧回数
lpm
Contributor I

When running ptp4l as a slave I occasionally (every few minutes) get the following error:

ptp4l[556.407]: timed out while polling for tx timestamp
ptp4l[556.408]: increasing tx_timestamp_timeout may correct this issue, but it is likely caused by a driver bug

If I do increase tx_timestamp_timeout, the error happens less frequently, but at 10 ms, ten times the default, it still happens.

As I understand it, the tx timpestamp is returned by the SoC itself after sending the delay request message, so it is strange that it should take this much time. I don't wether the ptp4l author means that it is a driver bug when it takes much time, or when the timestamp does not arrive at all. I can see that the timestamp always arrive eventually when this happens by re-polling.

How come it takes so long time to get back the timestamp? Is this a bug? If not, how long should the timeout value be?

My kernel is based on linux 4.14 from LSDK 18.12, and the SoC is LS2044A.

タグ(1)
0 件の賞賛
返信
2 返答(返信)

8,089件の閲覧回数
jimmy21
Contributor I

Please I'm currently facing the same problem

Could you please suggest me how do I fix it? appreciated much for your help on my thread here

https://community.nxp.com/t5/Using-Our-Community/ptp4l-send-delay-request-failed-and-minimum-delay-r...

0 件の賞賛
返信

9,615件の閲覧回数
yipingwang
NXP TechSupport
NXP TechSupport

Hello Lars Petter Mostad,

LSDK uses ptpd for IEEE 1588 on arm64 platform, OpenIL uses ptp4l, we also found this issue, please refer to the following workaround.

The ptp4l stack may report a timeout for getting the tx timestamp, but this rarely appears. This is not a bug. The stack tries to get the tx timestamp after sending a message, but cannot get it if the driver has not completed tx timestamp processing in time.

Just increasing the tx_timestamp_timeout parameter and re-running the stack will resolve this problem.


ptp4l[574.149]: timed out while polling for tx timestamp
ptp4l[574.152]: increasing tx_timestamp_timeout may correct this issue, but it is likely
caused by a driver bug

Thanks,

Yiping

0 件の賞賛
返信