On Tue, Mar 21, 2017 at 08:37:49AM +0100, Stefan Lange wrote: > phc2sys[28966.852]: [0:eth1+eth2] selecting eth2 for synchronization > phc2sys[28966.852]: [0:eth1+eth2] selecting CLOCK_REALTIME for > synchronization > phc2sys[28966.853]: [0:eth1+eth2] selecting eth1 as the master clock > phc2sys[28966.853]: [0:eth1+eth2] phc offset -6283178 s0 freq +0 > delay 680 > phc2sys[28966.853]: [0:eth1+eth2] phc offset 5 s0 freq +0 > delay 2130 > phc2sys[28967.853]: [0:eth1+eth2] phc offset -6285375 s0 freq +0 > delay 680 > phc2sys[28967.853]: [0:eth1+eth2] phc offset 5 s0 freq +0 > delay 2170 > phc2sys[28968.853]: [0:eth1+eth2] phc offset -6287640 s0 freq +0 > delay 680 > phc2sys[28968.854]: [0:eth1+eth2] phc offset 5 s0 freq +0 > delay 2130
I think the interleaving of the offset explains what is happening here. phc2sys is synchronizing the system clock to eth1 via SHM and at the same time it is synchronizing eth2 to eth1 via the same SHM. The eth1-sys sample is immediately overwritten by the eth1-eth2 sample, which is what ntpd sees and complains about timestamps from future. I guess phc2sys needs to be improved to detect interfaces sharing the same clock. Note that the SHM servo (using one segment) can meaningfully work only with two clocks, i.e. it can't be used in a jbod setup. -- Miroslav Lichvar ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Linuxptp-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
