Hi Erik and Richard, Thank you very much for your suggestions. I initially implemented the end-station and time-aware bridge with gPTP time maintained in software with timecounter.
After seeing Erik's comments, I realize it makes sense to adjust physical clock. Although the cumulativeScaledRateOffset in TLV couldn't be utilized (I think only time offset is required for physical clock adjustment), and the cumulativeScaledRateOffset/correction may be not very correct (because clock is adjusted frequently), the servo will adjust all slaves to same time and stable state finally. Then cumulativeScaledRateOffset/correction will become correct and stable too. I just tried physical clock adjustment today. The result seemed fine. I'd like to clean up my patches and send to community for reviewing. I used two new clock type, STATION and BRIDGE (will change to TAB which I think better). The implementation of TAB is similar to Rodney's notes, I created bridge.c which had minor changes from p2p_tc.c. Thanks a lot. Best regards, Yangbo Lu > -----Original Message----- > From: Erik Hons <erik.h...@ni.com> > Sent: Thursday, September 26, 2019 10:54 PM > To: Y.b. Lu <yangbo...@nxp.com>; Richard Cochran > <richardcoch...@gmail.com> > Cc: Андрей Иванов <ia...@yandex.com>; rodney.greenstr...@gmail.com; > linuxptp-devel@lists.sourceforge.net > Subject: RE: [Linuxptp-devel] [Linuxptp-users] How do I implement Sync > message receive timeout according to Automotive and 802.1 AS profiles? > > > 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
