[Linuxptp-users] gPTP issues with ntpd

[Jakub R. <j.r...@el...>]

 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