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
_______________________________________________
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
