<j.raczyn...@elpromaelectronics.com> wrote: > > > > 20.07.2022 15:23 Miroslav Lichvar <mlich...@redhat.com> write: > > > > > > On Wed, Jul 20, 2022 at 03:12:39PM +0200, Jakub Raczyński wrote: > > > phc2sys[2031.823]: lan1 sys offset 4870 s0 freq +0 delay 1875 > > > phc2sys[2032.824]: lan1 sys offset 4915 s0 freq +0 delay 1875 > > > phc2sys[2033.824]: lan1 sys offset 5011 s0 freq +0 delay 1750 > > > phc2sys[2034.825]: port 360712.fffe.52efd6-1 changed state > > > phc2sys[2034.826]: reconfiguring after port state change > > > phc2sys[2034.828]: master clock not ready, waiting... > > > phc2sys[2035.828]: port 360712.fffe.52efd6-1 changed state > > > phc2sys[2035.830]: reconfiguring after port state change > > > phc2sys[2035.831]: selecting CLOCK_REALTIME for synchronization > > > phc2sys[2035.832]: selecting lan1 as the master clock > > > phc2sys[2035.833]: CLOCK_REALTIME phc offset -5136 s0 freq +0 > > > delay 1875 > > > phc2sys[2036.834]: CLOCK_REALTIME phc offset -4435 s0 freq +0 > > > delay 1875 > > > > > > So, as mentioned "That is not expected to work" but kinda did or seemed > > > like it. Would need more research and debugging what is actually > > > happening inside both servos. > > > > There is only one SHM segment and it's used by ntpd for > > synchronization of the system clock. When phc2sys reverses the > > direction, the offset will flip the sign, intending to synchronize the > > PHC to the system clock, but ntpd will still be using the data it > > receives to synchronize the system clock, which will cause a positive > > feedback loop and the clock will be steered away, stepped, or ntpd > > will give up depending on its configuration. > > > > -- > > Miroslav Lichvar > > Actually it didn't look like it - ntpd was giving up data from ntpshm > instantly after switching to Master and started using ntpshm data right after > switching to Slave. But as said, no idea what was going inside the servo. > > But anyway, I will stick to the proposed workaround. Thanks again. > > Jakub Raczynski >
I want to apologize for many emails, but I do not understand and expressed myself poorly. When using phc2sys with: /usr/sbin/phc2sys -a -r -r -f /etc/ptp4l.cfg -E ntpshm -M 4 it mostly seems to work as I would expect - ntpd is not using data from PTP (ntpshm) when it is in Master state and us using data from ntpshm when Slave. The '-a -r -r' flag selects ntpshm as Slave servo only and CLOCK_REALTIME for Master. So this setup seems to be correct and from the phc2sys log I sent previously it seems to be. So it seems that phc2sys is correctly writing timestamps to ntpshm only when it is Slave. The only problem is caused by ntpd reset - it starts synchronizing to PTP (ntpshm) even if it shouldn't as is it Master. I have yet to debug whether it is phc2sys that does not set some flag for ntpd or if it is ntpd that clears some flag it probably shouldn't. But it seems like that phc2sys stays in mentioned "zombie servo" mode as it is synchronizing ntpshm to itself, even after killing ptp4l. I am merely asking for advice why is it issue. Why is ntpshm being fed timestamps even if it is in Master state? Is it not directly controlled by phc2sys? This should not require any workaround (although it would work, but seems a little excessive). Best regards Jakub Raczynski _______________________________________________ Linuxptp-users mailing list Linuxptp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-users
