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

[Michael W. <mi...@wa...>]

Hi all,

Am 2019-09-26 16:53, schrieb Erik Hons:
> 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.

This is only true if the hardware has only one clock. There is also
hardware which supports two clocks and which can do cross timestamping
between these. Eg. one is free-running and one is synchronized. The
former is used for PTP and the latter is then used for Qbv.

But I'm not sure if this is actually worth the hassle to actually
implement this, esp. if there is no/little disadvantage in real life
applications, like Erik mentioned. Although there are some rumors
that 802.1AS needs two clocks for different time domains? Maybe
Rodney could shed a light on that.


-michael