@Chris Caudle, kernel update is in the development queue. The design this one is derived from is not exposed to a network, so system stability (it is not broken, does not fix) was privileged over keeping it up to date. This new design's requirement is different and the kernel will have to be updated.
I think I am misunderstanding a few t. So I have some questions to ask to clarify some points. First question is what does the freq figure means? ptp4l[11303.293]: master offset -578 s2 freq +64977 path delay 78053 ptp4l[11304.294]: master offset 425 s2 freq +65077 path delay 77958 ptp4l[11305.294]: master offset -4653 s2 freq +64565 path delay 77985 ptp4l[11306.294]: master offset -2948 s2 freq +64732 path delay 77985 What could explain its big values in the run I posted in my OP? > ptp4l[23785.675]: master offset 2215 s2 freq +99998938 path delay > 66680 > ptp4l[23786.675]: master offset 1182 s2 freq +99998836 path delay > 66749 > ptp4l[23787.676]: master offset 3788 s2 freq +99999100 path delay > 66749 > ptp4l[23788.676]: master offset 2412 s2 freq +99998965 path delay > 66749 Sometimes, when I start the slave and there is a big difference between its clock and the master's, the offset starts big: ~$ sudo ptp4l -i eth0 -S -s -m -q step_threshold=0.00001 ptp4l[11836.182]: port 1: INITIALIZING to LISTENING on INIT_COMPLETE ptp4l[11836.182]: port 0: INITIALIZING to LISTENING on INIT_COMPLETE ptp4l[11838.868]: port 1: new foreign master aabbcc.fffe.ddee66-1 ptp4l[11843.269]: selected best master clock aabbcc.fffe.ddee66 ptp4l[11843.269]: foreign master not using PTP timescale ptp4l[11843.269]: port 1: LISTENING to UNCALIBRATED on RS_SLAVE ptp4l[11845.469]: master offset -3536460389269 s0 freq -100000000 path delay -29979969 ptp4l[11846.569]: master offset -3536360300857 s0 freq -100000000 path delay -29979969 ptp4l[11847.669]: master offset -3536274698933 s0 freq -100000000 path delay -15493484 ptp4l[11848.769]: master offset -3536181043684 s0 freq -100000000 path delay -9059394 ... ptp4l[11861.972]: master offset -3534976041966 s1 freq -1062624 path delay -13065167 ptp4l[11862.975]: master offset 2772202 s2 freq -782632 path delay -13065167 ptp4l[11862.975]: port 1: UNCALIBRATED to SLAVE on MASTER_CLOCK_SELECTED ptp4l[11863.976]: master offset -6087691 s2 freq -1674709 path delay -3354109 ptp4l[11864.977]: master offset -5337010 s2 freq -1604978 path delay -2385342 ptp4l[11865.979]: master offset -4294068 s2 freq -1504978 path delay -1756173 ptp4l[11866.981]: master offset -3994368 s2 freq -1479002 path delay -486776 ptp4l[11867.983]: master offset -2451261 s2 freq -1327143 path delay -486776 ptp4l[11868.984]: master offset -1054808 s2 freq -1188552 path delay -486776 ptp4l[11869.986]: master offset 155097 s2 freq -1067407 path delay -444443 ptp4l[11870.987]: master offset 1291473 s2 freq -952478 path delay -444443 .... ptp4l[11900.000]: master offset 9506432 s2 freq +95385 path delay 77000 ptp4l[11901.000]: master offset 9478411 s2 freq +102062 path delay 77000 ptp4l[11902.001]: master offset 9442138 s2 freq +107877 path delay 77766 ptp4l[11903.001]: master offset 9397344 s2 freq +112795 path delay 78496 I think I am misusing the step_threshold parameter. What exactly this parameter does? Is there an ideal value or I should just leave it alone (just use the default)? Is there a way to force the slave's system clock to resynchronize with the master's if it changes? Assume when powered up, the grandmaster (diagram in my OP) is not connected, the clock of the Embedded PC is off and the Custom Board's system clock synchronizes with it. When the GM is connected, the EPC's will synchronize with the GM's and then I have my CB totally off. Will I need to restart ptp4l on the CB? _______________________________________________ Linuxptp-users mailing list Linuxptp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-users
