ptp4l tx timestamp timeout

取消
显示结果 
显示  仅  | 搜索替代 
您的意思是: 

ptp4l tx timestamp timeout

9,316 次查看
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 回复数

6,901 次查看
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 项奖励

8,427 次查看
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 项奖励