net: ptp: clock rate forced to limit; clock never converges

[ClaCodes]

Describe the bug

Testing on a hardware system consisting of a stm and a linux machine. Observation: Clock never converges. It locks up in a failure loop. Periodic warning about clock being off more then one second and being set instead of adjusted. I am using 4.3.0, it appears the issue might be fixed with #106464. I will retry with #110669. Feedback welcome anyway, especially @DBS06 please take a look.

<wrn> ptp_clock: Clock offset exceeds 1 second.
<wrn> ptp_clock: Set clock time: X

Root cause (unconfirmed):

1. ptp_servo_pi is dimensionally wrong: It takes nanosecond_diff directly into ppb frequency correction. We would expect the diff to be divided by the sync interval?
2. pi_drift is not reset: Once the integrator has wound up, it can never recover. Instead it should be reset, when the step correction takes place, on port changes and on re-init.
3. Return value of ptp_clock_rate_adjust is silently ignored. Drivers are allowed to rejet out of range values. In that case the implementation should consider clamping or maybe stepping instead.

• Servo requests wildly out-of-range rates
• Hardware takes lowest possible rate (90% in my case)
• clock looses ~100ms per second
• pi_drift hard positive -> out of range -> rejected -> permanently frozen an 90%
• So with a 1Hz sync the offset grows by ~100ms per sync. On the 10th sync it crosses 1 s and step correction jumps in but does not restore the integrator. The cycle continues
• -> We observe steps in 10s period

On target, I confirmed by executing the ptp_clock freq PTP_CLOCK 0 shell command. This recovered the system out of the failure-loop (not completely solving the issue though, because pi_drift is still wound up).

Suggested fixes:

• Scale the pi-servo by the sync interval and scale the ppb to a plausible range.
• Reset pi_drift and restore ratio 1.0 when the step correction takes place and other init-like situations
• At least log a warning, when driver rejects a clock rate adjustment (or better, act on it)

Regression

• This is a regression.

Steps to reproduce

1. build with CONFIG_PTP=y, CONFIG_PTP_CLOCK=y for hardware (stm32h7 in my case)
2. Connect to IEEE 1588 time transmitter (for example linux with ptp4l)
3. Should come into the failure mode described above
4. optionally set CONFIG_PTP_LOG_LEVEL_DBG=y

Relevant log output

<wrn> ptp_clock: Clock offset exceeds 1 second.
<wrn> ptp_clock: Set clock time: X

Impact

Major – Severely degrades functionality; workaround is difficult or unavailable.

Environment

Zephyr 4.3.0 (see above for comments on potentially already being fixed on main)

Additional Context

PTP is unusable for time synchronisation on this platform

[DBS06]

Thanks for pinging me. This looks quite familiar :-)

One note regarding #110669: I don't think testing that PR alone will make a difference for the servo problem described here. Although it is labelled as a backport from #106464, it only backports the recvmsg() ancillary-buffer accounting fix from that PR. It does not contain the other PTP clock/servo changes and they will most likely not be backported.

Your observations about the failure loop make sense to me, especially the combination of an out-of-range rate adjustment and an already wound-up integrator.

On current main, some of this behaviour is already handled differently. A hard clock step resets the servo state, including pi_drift, and restores the nominal PHC rate. A failure from ptp_clock_rate_adjust() is also checked now. The failure is logged and the servo is reset instead of silently continuing with the accumulated correction.

The Sync interval question is interesting. I wouldn't necessarily divide the phase offset directly by the Sync interval, since the sampling period can also be incorporated into the PI gains. However, the existing implementation effectively updates the integral once per Sync, so its behaviour is dependent on the Sync interval. I think this deserves a closer look.

This class of problem is also one of the motivations behind the precision-timing work in #115363. The shared discipline there explicitly models rate limits, anti-windup, acquisition/lock/recovery states, hardware capabilities and reset behaviour instead of leaving these properties implicit in the protocol-specific PI servo.

I would therefore try to reproduce this on current main or wait for the 4.5 release. If it still reproduces there, I will look into the servo behaviour in more detail.