On Sat, Apr 14, 2018 at 09:45:34AM -0700, Richard Cochran wrote: > This series add support for running a TC over multiple ports. > Comments, testing, and review are most welcome.
This is an amazing feature. I'm glad that we'll finally be able to test the processing of the correction field without having to have a PTP-TC switch (I have yet to see one). The code looks good to me, but I didn't look very thoroughly. I ran some tests and it seems to be working nicely. I used two machines with dual-port NICs connected directly to each other. One was running as a E2E/P2P TC using the two ports as JBOD and the other was running two separate ptp4l instances, a grandmaster and slave. phc2sys was used to compare the two clocks to see if there are any errors in the correction. It was close to zero as expected. With E2E TC the delay measured by the slave was the sum of the two links' delays. With P2P TC the delay was just the link it was connected to. E2E TC with the P2P delay mechanism doesn't seem to work. The e2e_tc code drops pdelay req/resp. If I'm reading the 1588 spec correctly, that should be allowed. It took me a while to realize I need to enable free_running to enable the E2E TC to correct for the measured frequency offset. Would it make sense to imply that option automatically? Also, should the TC drop sync/delay messages until it has estimated the offset to minimize disturbances when the TC is restarted? With P2P TC free_running can be disabled, but I'm not sure how much sense such a configuration makes. Are there any plans to support a combined OC+TC? Thanks for your work on this. -- 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 Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
