Greetings,
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 Example of problem: remote refid st t when poll reach delay offset jitter ======================================================================== 127.127.28.2 .GPS. 0 l - 8 0 0.000 0.000 0.000 x127.127.28.3 .RTC. 0 l - 8 7 0.000 0.007 0.004 *127.127.28.4 .PTP. 0 l - 8 17 0.000 37000.0 0.010 sending: GET PORT_DATA_SET 360712.fffe.52efd6-1 seq 0 RESPONSE MANAGEMENT PORT_DATA_SET portIdentity 360712.fffe.52efd6-1 portState MASTER logMinDelayReqInterval 0 peerMeanPathDelay 10259 logAnnounceInterval 0 announceReceiptTimeout 3 logSyncInterval 0 delayMechanism 2 logMinPdelayReqInterval 0 versionNumber 2 This can be reproduced by having internal source (RTC in this case) being started first and having significant offset from PTP (that is preferred source in ntpd) which will cause ntpd to restart. After ntpd restart PTP starts to synchronize ntpshm although in PMC it is still Master device. This also creates "zombie servo" (as I did name it) -> in case from the example, phc2sys will still synchronize ntpd, even after killing ptp4l process. To fix that issue all 3 processes (ptp4l, phc2sys and ntpd) have to be killed. Although in example it is caused directly by incorrectly set ptpTimescale flag, it can be caused just by having significant offset to PTP. I would like to ask if you have any idea what could be cause of this? I did expect that Master device would not synchronize ntpshm. Is it possible to achieve two-way synchronization using phc2sys + ptp4l for ntpshm (as said, it seems to work perfectly for CLOCK_REALTIME) ? What is the flag or field that selects direction of synchronization in ptp4l? Or is it controlled by ntpd in that case? Second thing I would like to ask about is: While testing devices with gPTP we encountered, in my opinion, quite inconsequential behavior. Using different setups, I set following flags and had following outcome: gmCapable = 0 , slaveOnly = 0 -> OK gmCapable = 1 , slaveOnly = 0 -> OK gmCapable = 0 , slaveOnly = 1 -> Cannot mix 1588 slaveOnly with 802.1AS !gmCapable gmCapable = 1 , slaveOnly = 1 -> OK Frankly, I would expect combination of "gmCapable = 1 , slaveOnly = 1" to fail with than "gmCapable = 0 , slaveOnly = 1". I would like to ask for reasoning behind that combination block and not the other. Since SlaveOnly flag performs as expected, even for gPTP setup. Best regards, Jakub Raczynski
_______________________________________________ Linuxptp-users mailing list Linuxptp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-users
