Re: [Linuxptp-devel] [Linuxptp-users] How do I implement Sync message receive timeout according to Automotive and 802.1 AS profiles?

[Y.b. L. <yan...@nx...>]

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 <eri...@ni...>
> Sent: Thursday, September 26, 2019 10:54 PM
> To: Y.b. Lu <yan...@nx...>; Richard Cochran
> <ric...@gm...>
> Cc: Андрей Иванов <ia...@ya...>; rod...@gm...;
> lin...@li...
> 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.