Hi Yangbo,
> > > May I have your suggestion here? To maintain gPTP time in software, > > > I just copied kernel timecounter code into linuxptp for usage. > > > > Why? That sounds wrong. > > Regarding to physical clock adjustment, that's confusing. This will changes > neighbor rate ratio frequently, so the cumulative rate ratio and corrected > residence time/path delay in follow_up and TLV will be not correct for the > receiver. I have some experience with this. With appropriate filtering and servo implementation, the necessary PHC adjustments do not introduce instability. The worst case synchronization error will scale with the number of bridges, and the offset will oscillate slowly, but the error does not "whip crack" to large unpredictable errors. Whether that's acceptable for your application is up to you. But you *can* build a system with a deep clock tree that stays within a narrow synchronization band while adjusting PHCs on all the bridges. As Richard mentioned in the other thread, you must do this if you are building systems that use Qbv queuing. You do not need to do it if your system requires end-station time synchronization only. _______________________________________________ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
