PTP Synchronization Issue – RAN650 O-RU does not enter synchronized state

[alektoja]

Hi all,
I'm setting up an environment based on the SRS tutorial: https://docs.srsran.com/projects/project/en/latest/tutorials/source/oranRU/source/index.html

I’m working with a Benetel RAN650 as the O-RU and a DU server equipped with an Intel X710 NIC (i40e driver). PTP synchronization is provided by a uFalcon-MX/G Grandmaster Clock, directly connected via 10G SFP+ to both the DU and the O-RU (no switch in between).

I followed the tutorial steps for PTP setup using LinuxPTP. I’ve tried various ptp4l and phc2sys configurations. One example of how I start ptp4l is:
ptp4l -i ens1f3 -f /path/ -m
The synchronization process starts correctly. It selects the grandmaster, transitions through UNCALIBRATED to SLAVE, and initially reports good values like:
rms 5 max 10 freq +9767 +/- 9 delay 178 +/- 0
However, it very frequently logs messages such as:
ptp4l[3236211.210]: rms 6 max 9 freq +9761 +/- 6 delay 178 +/- 0
ptp4l[3236211.337]: clockcheck: clock frequency changed unexpectedly!
ptp4l[3236211.400]: clockcheck: clock frequency changed unexpectedly!
ptp4l[3236211.526]: clockcheck: clock frequency changed unexpectedly!
ptp4l[3236211.653]: clockcheck: clock frequency changed unexpectedly!
ptp4l[3236211.779]: clockcheck: clock frequency changed unexpectedly!
ptp4l[3236211.906]: clockcheck: clock frequency changed unexpectedly!
ptp4l[3236212.032]: clockcheck: clock frequency changed unexpectedly!
ptp4l[3236212.096]: clockcheck: clock frequency changed unexpectedly!
ptp4l[3236212.159]: clockcheck: clock frequency changed unexpectedly!
ptp4l[3236212.318]: timed out while polling for tx timestamp
ptp4l[3236212.318]: increasing tx_timestamp_timeout or increasing kworker priority may correct this issue, but a driver bug likely causes it
ptp4l[3236212.318]: port 1 (ens1f3): send delay request failed
ptp4l[3236212.318]: port 1 (ens1f3): SLAVE to FAULTY on FAULT_DETECTED (FT_UNSPECIFIED)
ptp4l[3236228.388]: port 1 (ens1f3): FAULTY to LISTENING on INIT_COMPLETE
ptp4l[3236228.446]: port 1 (ens1f3): new foreign master 000580.fffe.084918-8
ptp4l[3236228.706]: port 1 (ens1f3): LISTENING to UNCALIBRATED on RS_SLAVE
ptp4l[3236228.726]: clockcheck: clock frequency changed unexpectedly!
ptp4l[3236228.726]: rms 4 max 7 freq +9762 +/- 5 delay 177 +/- 0
ptp4l[3236228.726]: port 1 (ens1f3): UNCALIBRATED to SLAVE on MASTER_CLOCK_SELECTED
ptp4l[3236228.852]: clockcheck: clock frequency changed unexpectedly!
ptp4l[3236228.978]: clockcheck: clock frequency changed unexpectedly!

This seems to indicate instability or a potential bug in timestamp handling. The NIC is on ptp5, and I’ve tried hardware and software timestamp modes. The system time is synced using phc2sys:
phc2sys -s ens1f3 -w -m -R 8 -f /path/

But even this results in very large and inconsistent offsets:
phc2sys[3236694.707]: clockcheck: clock frequency changed unexpectedly!
phc2sys[3236694.707]: CLOCK_REALTIME phc offset -3774 s2 freq -98260 delay 764
phc2sys[3236694.832]: clockcheck: clock frequency changed unexpectedly!
phc2sys[3236694.832]: CLOCK_REALTIME phc offset -2014 s2 freq -97632 delay 759
phc2sys[3236694.957]: clockcheck: clock frequency changed unexpectedly!
phc2sys[3236694.957]: CLOCK_REALTIME phc offset 577 s2 freq -95645 delay 760
phc2sys[3236695.082]: clockcheck: clock frequency changed unexpectedly!
phc2sys[3236695.083]: CLOCK_REALTIME phc offset 2489 s2 freq -93560 delay 766

On the O-RU (RAN650), the PTP packets are clearly being received (checked with tcpdump), and the RU reports the PTP state as locked, with the expected grandmaster ID. But still, the radio never enters synchronized state.

root@benetelru-01:~# tail -f -n 100 /tmp/logs/radio_status
[INFO] /etc/ru-center-frequency-mhz read
[INFO] /home/root/adrv9025/RAN650_n77u_4T2R/ directory used
[INFO] adrv9025 files OK
[INFO] Platform: RAN650_A
[INFO] Frequency: 3950.00
[INFO] SW Version: RAN650-1v1.0.4-dda1bf5
[INFO] Read EEPROM with eeprom2ram
[INFO] Read EEPROM with benetel_read_ru_eeprom.sh
[INFO] Radio bringup begin, 95.45 seconds since boot
[INFO] Initialize TDD Pattern
[INFO] Setting initialization TDD Pattern: DDDDDDDSUU
[INFO] Waiting for PTP sync
[ERROR] RU did not synchronize within 3 mins. Exiting radio initialization.
[ERROR] Radio bringup failed with: 0
[INFO] Resetting
[INFO] Radio bringup attempt finished, 278.11 seconds since boot
[INFO] Radio bringup begin, 278.12 seconds since boot
[INFO] Initialize TDD Pattern
[INFO] Setting initialization TDD Pattern: DDDDDDDSUU
[INFO] Waiting for PTP sync
[ERROR] RU did not synchronize within 3 mins. Exiting radio initialization.
[ERROR] Radio bringup failed with: 0
[INFO] Resetting
[INFO] Radio bringup attempt finished, 460.85 seconds since boot
[INFO] Radio bringup begin, 460.86 seconds since boot
[INFO] Initialize TDD Pattern
[INFO] Setting initialization TDD Pattern: DDDDDDDSUU
[INFO] Waiting for PTP sync
[ERROR] RU did not synchronize within 3 mins. Exiting radio initialization.
[ERROR] Radio bringup failed with: 0
[INFO] Resetting
[INFO] Radio bringup attempt finished, 643.61 seconds since boot
[INFO] Radio bringup begin, 643.61 seconds since boot
[INFO] Initialize TDD Pattern
[INFO] Setting initialization TDD Pattern: DDDDDDDSUU
[INFO] Waiting for PTP sync
[ERROR] RU did not synchronize within 3 mins. Exiting radio initialization.
[ERROR] Radio bringup failed with: 0
[ERROR] Un-recoverable system failure detected, reboot required.
[INFO] Launching o_ru_app

I've verified that both the DU and RU are using domain ID 24 and consistent clockClass and timeSource settings. The RU’s PTP configuration is aligned with the G.8275.1 multicast profile. Hardware timestamping is enabled, and syncmon on the RU reports PTP Lock State: locked. However, DPLL3 (responsible for RF/PTP clock) stays in the INVALID state. DPLL0 (SyncE) is LOCKED, but despite that, the RU never completes its bring-up process.

Is anyone familiar with this behavior? Could this be a driver/firmware issue with the Intel X710 (i40e) and hardware timestamping? Or has anyone seen the RAN650 fail to fully synchronize despite receiving valid PTP packets?

Any help or pointers would be greatly appreciated.