网站用什么平台开发用asp做网站题目

TSN的时间同步精度，指被测时钟与主时钟的最大偏差。在设备的组网过程中，最大的困难就是保证期望的时间同步精度。主时钟仅负责将自身的时间分发出去，难以判断其他设备的同步效果；此外，若在网络中某处发生了同步故障，也难以定位问题节点，毕竟每个节点依赖的都是上一个节点的信息。

同步精度的测量

同步精度的测量方法有两种常见形式。

其一是让每个设备在同步时间达到整秒时输出一个脉冲信号（1PPS信号），通过示波器等手段观测被测时钟与主时钟的1PPS信号偏差。

其二就是本文提到的Reverse Sync方案。让被动接收同步信息的接收方主动向发送方反馈自己的同步时间，从而使得发送方可以在本地评估下一个节点的同步精度。

假设到接收方的路径上不得不经过一个中继节点（比如带有交换机的混合设备），只需要将额外的驻留时间（residence time）以及链路时延补偿到reverse sync报文里的correction field字段中就可以了。（注：本文将不区分Sync以及Follow Up。）

对于第二种方式，各个控制器开发商可能都会有自己的实现方法。

虽然，只要能达到测量时间同步精度的结果，方法的种类并不关键。但后面嘛，我们还是会详细的聊一聊，在实际的开发环境中， Reverse Sync的实践与结果。

实践出真知-Reverse Sync

9月，我们利用德州仪器开发板进行了TSN功能相关环境的搭建，对TSN的常见协议进行了验证。其中同步精度的测试主要利用了里面的一块tda4vm，以及一块dra821开发板。

后面，我将介绍我们是如何借着802.1 AS-2020协议中多时钟域的东风，实现Avnu扩展定义的reverse sync功能的。

在本次验证中，我们将这两块板子在时钟域0进行同步，一块作为Tester，在域0中担任GM的角色，另一块则作为被测件。

在上面我们说，需要时间同步的接收方反馈自己的同步时间。假设在只有单时钟域的情况下，我们迫不得已也只能修改协议栈的实现逻辑，让原先只能接收sync报文的slave端口向外发送sync报文了。

好在，AS协议从2011版向2020版更新的过程中，增加了多主时钟域这一概念。一个系统中可以同时存在多个不同的时钟域，同一个设备可以在某个时钟域中充当GM的角色，也可以同时在另一个时钟域中充当被同步的角色，这就给我们“偷懒”的行为提供了很大的便利。

在域0你管我叫爸，在域1我管你叫哥，咱俩各论各的，多时钟域就这么一个状态。我们很快就定了，在域0进行正常的时间同步，在域1中，则把被测件设置为GM，反向输送时间同步信息。

那就只剩下一个问题了，域0和域1维护的不是一个同步时间，被测件怎么通过域1把域0维护的同步时间反馈回去呢。这倒是也简单，毕竟父子关系都如此复杂了，域0和域1分家也不太合适，于是我们将被测件上本来分别给域0和域1用的两个硬件时钟缩减至了一个，域0和域1共用一个硬件时钟，同时呢，根据辈分合理剥夺了域1对于硬件时钟的修改权。这样，被测件上的域1就是专门负责将域0的同步时间传递回去的功能性时间域了。

由此，借助于多时钟域实现的Reverse Sync基本大功告成了，还剩下的一小步就是在tester这一侧，记录接收到Reverse Sync时的本地时间戳，算上链路时延之后，和Reverse Sync报文内携带的时间戳作一个差值，这就是我们需要的时间同步精度啦。

那么，结果如何？

在作为tester的设备上，我们额外添加了一个上位机用来显示差值的变化情况，以最大值为评判标准，从图片可以看出，设备的同步误差在正负75ns之间。

但这是设备自测的结果，并不足够证明这一方法的有效性。因此，我们使用Paragon-X设备作为主时钟，利用Reverse Sync方法对被测件的同步精度做了二次验证，结果如下图所示，稳定后波动的幅值在+75ns到-153ns间。

二者结果的差异较小，Reverse Sync实现成功。

总的来说，在很多情况下，量产控制器并没有预留PPS接口，或对应的接口已经设计成其他用处，相对来说实现更加方便、且不需要额外设备支持的Reverse Sync就有了更大的发挥空间，优势更大。