I've noticed an issue with applying time date when using software timestamping.
What I noticed is that the date&time are updated only over the first state machine loop. Later loops won't do the work for me.
Observed behavior:
In case that everything is set on the environment, connected, Grand Master sending syncs, on the first attempt after service is started (restarted) I usually see updated time and date when ptp4l is printing out event message:
[47.121] port 1: UNCALIBRATED to SLAVE on MASTER_CLOCK_SELECTED
Before that, there is old, usually not correct time.
In case that something prevented the first sync so this state is not reached (there is no GM sending syncs, ptp packages received are not from the best master clock, there is some network issue/firewall is not opened for the first run, or in case of any reason causing ptp4l to enter GM role) time&date would not be updated which is expected.
Later, when problem is cleared, for example of delayed GM boot, when GM is finally up and sending syncs, after being selected as the new master clock, although there is expected state machine transition, on state change mentioned above there is no time&date update so it sticks to the same old value forever (ok...or until restarted).
In addition, timedatectl field 'System clock is synchronized' in the most of the cases changes state to yes.
No matter how many times clock is selected, it is not updated until service is restarted manually over systemctl interface and again application-wise the first time of the new run state machine reaches 'UNCALIBRATED to SLAVE on MASTER_CLOCK_SELECTED'.
I use software timestamping therefore there is only one ptp4l service running in Boundary mode, but it was the same behavior in the Ordinary mode.
Hello community,
I've noticed an issue with applying time date when using software timestamping.
What I noticed is that the date&time are updated only over the first state machine loop. Later loops won't do the work for me.
Observed behavior:
In case that everything is set on the environment, connected, Grand Master sending syncs, on the first attempt after service is started (restarted) I usually see updated time and date when ptp4l is printing out event message: [47.121] port 1: UNCALIBRATED to SLAVE on MASTER_CLOCK_SELECTED Before that, there is old, usually not correct time.
In case that something prevented the first sync so this state is not reached (there is no GM sending syncs, ptp packages received are not from the best master clock, there is some network issue/firewall is not opened for the first run, or in case of any reason causing ptp4l to enter GM role) time&date would not be updated which is expected. Later, when problem is cleared, for example of delayed GM boot, when GM is finally up and sending syncs, after being selected as the new master clock, although there is expected state machine transition, on state change mentioned above there is no time&date update so it sticks to the same old value forever (ok...or until restarted).
In addition, timedatectl field 'System clock is synchronized' in the most of the cases changes state to yes. No matter how many times clock is selected, it is not updated until service is restarted manually over systemctl interface and again application-wise the first time of the new run state machine reaches 'UNCALIBRATED to SLAVE on MASTER_CLOCK_SELECTED'.
I use software timestamping therefore there is only one ptp4l service running in Boundary mode, but it was the same behavior in the Ordinary mode.
Can you help on this?
Thanks in advance!