Hi,
On 6/7/2022 7:54 AM, Mehmet Akbulut wrote: > Hello, > > We see that if a 'certain' process is running, it causes ptp4l to switch > into faulty state at some point. After that, phc2sys never syncs back to > ptp4l. > I'm sorry to hear this. > This certain process is a proprietary application running as > non-root/unprivileged but, at a very high level, it receives UDP > packets, transforms the data, sends TCP packets. It does not perform any > high frequency scheduling or other unusual activity. The CPU load from > this application is 50-70%. We have verified that simply running a CPU > stress test with 100% load does not cause ptp4l to go into this faulty > state so we don't think CPU load is a contributor by itself. > Sure. Does this application request Tx timestamps? > We have also tried to increase `tx_timestamp_timeout` to 10ms but same > behavior was observed. Network driver is `ixgbe` on Linux kernel 5.4. > ixgbe only supports a single outgoing Tx timestamp per interface at a time. Multiple applications attempting to issue Tx timestamps could interfere with each other. As far as I know there's no lock or indication to the application that its Tx timestamp was ignored. > We are looking for any pointers to help resolve this issue and > especially figure out what's causing this transition to faulty state. > Can you gather the output of ethtool -S? It should have tx_hwtstamp_timeouts and tx_hwtstamp_skipped statistics. Are either of those incrementing? Thanks, Jake _______________________________________________ Linuxptp-users mailing list Linuxptp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-users
