<j.raczyn...@elpromaelectronics.com> wrote: > > > > 20.07.2022 13:33 Miroslav Lichvar <mlich...@redhat.com> wrote: > > > > > > On Wed, Jul 20, 2022 at 12:06:43PM +0200, Jakub Raczyński wrote: > > > I was trying to setup gPTP using linuxptp (ptp4l + phc2sys) that would > > > allow two way synchronization using ntpd. Setup without ntpd > > > (synchronizing CLOCK_REALTIME) seems to be working perfectly. > > > However with ntpd is that when in network there is no external gPTP > > > Master available and device does become Master itself it may synchronize > > > itself to its own shm memory. > > > > > > > > > phc2sys is run using: /usr/sbin/phc2sys -a -r -r -f /etc/ptp4l.cfg -E > > > ntpshm -M 4 > > > > That is not expected to work. phc2sys has only one servo and ntpshm > > can be used only in one direction. > > > > You would need a second phc2sys instance with an option to only synchronize > > the PHC, when the port is in master state. > > > > As a workaround, you could write a script that would monitor the state > > and start/stop phc2sys as needed. > > Best option would be if phc2sys could exist as Master-only (only '-r' flag > without '-a -r'). Such case could probably only useful for ntpshm servo that > can be used in Time Servers that use different sources of synchronization > (like GPS + PTP in our case). But as you said, right now only option seems to > be such workaround. > > Maybe such option would be worthy TODO? >
Although, I would like to show one thing I accomplished with mentioned setup (phc2sys configuration). Other than that bug it seemed to have worked, although i have no idea what was really going inside the servo to judge if this was bug or intended. Example: - Switching from Slave to Master: phc2sys[1968.791]: CLOCK_REALTIME phc offset 644 s0 freq +0 delay 1750 phc2sys[1969.791]: CLOCK_REALTIME phc offset 512 s0 freq +0 delay 1875 phc2sys[1970.792]: port 360712.fffe.52efd6-1 changed state phc2sys[1970.793]: reconfiguring after port state change phc2sys[1970.794]: selecting lan1 for synchronization phc2sys[1970.794]: selecting CLOCK_REALTIME as the master clock phc2sys[1970.794]: lan1 sys offset -433 s0 freq +0 delay 1875 phc2sys[1971.795]: lan1 sys offset -364 s0 freq +0 delay 1875 phc2sys[1972.795]: lan1 sys offset -231 s0 freq +0 delay 1875 phc2sys[1973.796]: lan1 sys offset -205 s0 freq +0 delay 1875 - Switching from Slave to Master 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. Best regards Jakub Raczynski _______________________________________________ Linuxptp-users mailing list Linuxptp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-users
