标题
- 一、PTP简介：
- 二、PTP的应用场景:
- 三、网络时钟同步的概念：
- 四、PTP基本概念：
- 五、PTP协议内容:
- 六、同步原理：
- 七、 Delay Request-Respond机制：
- 八、Peer Delay机制：
- 九、调试总结：
一、PTP简介：
PTP(Precision Time Synchronization Prorocol)是一种网络精准时间同步协议，定义在1588标准中，PTP提供了一种在网络上进行精确时间同步的方法，具有亚微秒级别的时间同步性能，相比于NTP(毫秒级)精度更高。
二、PTP的应用场景:
在工业和电力、数据中心、城域数据回传，医疗、金融等等各领域都需要用到。
例如在医疗领域：可以为医疗中心的各科室业务系统及其他子系统提供精准时钟同步服务，确保各个系统业务事件数据实时精准有效。
三、网络时钟同步的概念：
时钟同步：也叫频率同步，频率同步指两个信号的变化频率相同或保持固定的比例， 信号之间保持恒定的相位差。
时间同步：也叫相位同步、相位同步是指信号之间的频率和相位都保持一致，即信号之间相位差恒定为零。两个表每时每刻的时间都保持一致。 相位同步的前提是频率同步，所以相位同步也称为时间同步
四、PTP基本概念：
PTP域
我们将应用了 PTP 协议的网络称为 PTP 域。 PTP 域内有且只有一个同步时钟，域内的所有设备都与该时钟保持同步。
时钟节点：
OC（ Ordinary Clock，普通时钟）：该时钟节点在同一个 PTP 域内只有一个 PTP 端口参与时间同步，并通过该端口从上游时钟节点同步时间。此外，当时钟节点作为时钟源时，可以只通过一个 PTP 端口向下游时钟节点发布时间，我们也称其为 OC。
BC（ Boundary Clock，边界时钟）：该时钟节点在同一个PTP域内拥有多个PTP端口参与时间同步。它通过其中一个端口从上游时钟节点同步时间，并通过其余端口向下游时钟节点发布时间。 此外， 当时钟节点作为时钟源时， 可以通过多个PTP端口向下游时钟节点发布时间的，我们也称其为BC。
TC（ Transparent clock，透明时钟）：与 BC/OC 相比， BC/OC 需要与其它时钟节点保持时间同步，而 TC 则不与其它时钟节点保持时间同步。 TC 有多个 PTP 端口，但它只在这些端口间转发 PTP 协议报文并对其进行转发延时校正，而不会通过任何一个端口同步时间。
TC 包括以下两种类型：
E2ETC（ End-to-End Transparent Clock，端到端透明时钟）：直接转发网络中非 P2P（ Peer-to-Peer，点到点）类型的协议报文，并参与计算整条链路的延时。
P2PTC（ Peer-to-Peer Transparent Clock，点到点透明时钟）：只直接转发 Sync 报文、Follow_Up 报文和 Announce 报文，而终结其它 PTP 协议报文，并参与计算整条链路上每一段链路的延时。
PTP中的端口类型
时钟通过端口进行通信，这些端口按类型可分为主端口（Master Port），从端口（Slave Port），被动端口（Passive Port）。
主端口（Master Port）指发布同步时间的端口。
从端口（Slave Port）指接收同步时间的端口。
被动端口（Passive Port）指既不接收同步时间、也不对外发布同步时间的端口。
拓扑图如下
五、PTP协议内容:
PTP消息分为两类:事件消息(事件消息),普通消息(消息)将军,事件消息是在发送和接收端都要打精确的时间戳,普通消息不需要打时间戳。
事件消息包括:sync,Delay_Req Pdelay_Req、Pdelay_Resp;
普通消息包括:announce,Follow_Up, Delay_Resp, Pdelay_Resp_Follow_Up,Management、Signaling;
(1) sync,Follow_Up、Delay_Req Delay_Resp用于产生和传递时序信息,这种时序信息用来同步普通时钟和边界时钟;
(2)Pdelay_Req, Pdelay_Resp,Pdelay_Resp_Follow_Up用来测量两个时钟端口之间的链路时延,测得的路时延用于校正sync与Follow_Up消息中的时间信息;
(3) announce消息用于建立同步分层结构;
(4) Management消息用于查询和更新时钟所维护的PTP数据集;
(5) Signaling消息用于其他的目的,例如在主从之间协调单播消息的发送频率。
(6)PTP消息的封装类型可以是UDP封装,也可以是以太网封装。UDP封装PTP消息时,使用319端口发送事件消息,使用320端口发送通用消息,以太网封装消息时,以太网类型为0x88f7。
(7)PTP报文头格式：http://www.023wg.com/message/message/cd_feature_1588v2_format-general.html
六、同步原理：
PTP 时间同步的实现包括以下步骤：
(1) 确定最优时钟以及主从关系。
(2) 频率同步，实现从时钟频率与主时钟同步。 频率同步是相位同步的前提和基础。
(3) 相位同步，实现从时钟相位与主时钟同步，使得从时钟的时间（从节点的本地时间） 和主时钟的时间保持一致。
PTP通过报文携带的时间戳来实现时间同步,PTP支持两种携带时间戳的模式:
One-Step Clock
报文发送时刻的时间戳随报文发出,该模式需要较高硬件支持,网络负荷小。
Two-Step Clock
报文的发送时刻的时间戳在随后的Follow_Up报文中发出,该模式对硬件需求较低,但软件较为复杂。
计算线路延迟(path delay)有两种方法:Delay Request-Respond(延时请求应答)机制和Peer Delay(对等延时)机制。
Delay Request-Respond机制中,使用Delay_Req, Delay_Resp,结合同步(Follow_Up)进行链路延迟计算,计算的对象为Master到Slave整个链路上的时间时延。Peer Delay机制中,使用Pdelay_Req, Pdelay_Resp (Pdelay_Resp_Follow_Up)进行链路延迟计算,计算对象为每一对Peer Delay机制的时钟之间的链路时延。
七、 Delay Request-Respond机制：
第一步：主发送一个同步消息;
第二步：若为One-step模式,则Sync消息携带发送时间戳t1;若为Two-step模式,Master在发送Sync消息后发送Follow_Up消息,Follow_Up消息携带Sync消息发送时间戳t1;
第三步：Slave收到Sync(Follow_Up)消息,获得t1,并记录同步消息接收时间戳t2;
第四步:Slave发送Delay_Req消息,并记录发送时间戳t3;
第五步:Master收到Delay_Req消息后,将Delay_Req消息接收时间戳t4通过Delay_Resp发送给Slave;
第六步：此时,Slave获得t1、t2、t3和t4四个时间戳。
假定条件:Slave- >Master和Master- >Slave的链路时延是对称的。(在PTP中我们一般都是默认链路时延时对称的)。
链路时延和时钟偏差计算公式如下:
path_delay= [(t4−t1)−(t3−t2)] / 2 = [(t2−t1) + (t4−t3)] / 2
offset= t2−(t1 +path_delay)= [(t2−t1)−(t4−t3)] / 2.
第七步：Slave计算出时钟偏差offset之后,便可进行时间同步,修正本地时钟。使得Slave的时钟同步Master时钟。
八、Peer Delay机制：
第一步：Port-1发送Pdelay_Req消息,并记录时间戳t1;
第二步：Port-2收到Pdelay_Req消息产生时间戳t2,并且发送Pdealy_Resp消息,记录
发送时间戳t3, Port-2可以选择下面的一种方式发送t2、t3给port-1:
−Pdelay_Resp消息中携带t3-t2的差值(One-step模式);
−Pdelay_Resp_Follow_Up消息中携带t3-t2的差值(Two-step模式);
−Pdelay_Resp消息中携带t2, Pdelay_Resp_Follow_Up消息中携带t3(Two_step模式);
第三步：Port-1收到Pdelay_Resp消息产生并记录时间戳t4;
第四步：此时,port-1可以得到时间戳t1、t2、t3和t4,或者得到t1, t3-t2, t4。
假定条件: :Slave- >Master和Master- >Slave的链路时延是对称的.
链路时延计算公式如下:
path_delay= [(t4−t1)−(t3−t2)] / 2 = [(t2−t1) + (t4−t3)] / 2
九、调试总结：
以下内容为我调试过程中出现的问题（仅供参考）：
我们先是使用的交换芯片是盛科的CTC8180,但是在实现10G接口的时间同步，想要去做1G接口的同步时候发现CTC8180对1G接口的PTP功能有较大的问题（时钟不稳定，前后偏差很大，BMC算法调整不了），需要盛科公司的人解决这个芯片缺陷。并且在这个时候得知客户同时需要1G、10G和100G三种接口，于是紧急决定把CTC8180换成CTC7132来进行开发。
先说说我在调试CTC8180中遇到的问题：
问题1：我们代码大致架构是平台-驱动-芯片，也就是说一个报文的发送需要由平台部分来进行发起，然后给到驱动部分，驱动适配芯片，芯片再把报文发出去。驱动有一个重要的作用就是打时间戳。
这是发包需要填写的参数，什么时候用CTC_PTP_CAPTURE_ONLY、什么时候用CTC_PTP_REPLACE_ONLY呢？
需要把时间戳上报给CPU，那么就需要用CTC_PTP_CAPTURE_ONLY，如果时间戳是直接打在报文里面则用CTC_PTP_REPLACE_ONLY。并且只有事件消息需要打时间戳，普通消息是不需要打时间戳的。在two-step模式下，sync、Delay_Req、 Pdelay_Req、Pdelay_Resp都需要上送CPU，所以用CTC_PTP_CAPTURE_ONLY。而在one-step模式下，sync报文不需要上送cpu，所以用CTC_PTP_REPLACE_ONLY即可。Delay_Req、 Pdelay_Req、Pdelay_Resp报文任然需要把时间戳上送CPU，因为需要对时间戳进行计算。
问题2： 如何查看报文中是否打上了时间戳？可以抓包来查看。由于驱动发包部分都是采用同一个接口，如果是其他的协议报文，例如ip报文，这种是不需要打时间戳的，所以需要在驱动的发包函数中把1588v2和其他报文隔离。可以用协议号来进行判断if (0x88F7== sai_ntohs(eth->h_proto))。
问题3：CTC8180打时间戳的方式是通过中断方式来进行上报的,也就是当从芯片发送一个报文出去，那么就在phy这一层芯片自动打一个时间戳，而CTC7132则不支持用中断的方式打时间戳，CTC7132只能用驱动主动获取时间戳的方式并填在报文中。
问题4:当把时间戳的问题解决完之后，通过专门的PTP测试仪来进行测试，结果如下图，两者之间的偏差为86539.5ns，很显然没同步。经过一系列的问题排查，最终确定是硬件问题，我们设备有一个时钟芯片，就是专门用来给ptp协议输出稳定的时钟的，一开始没有采用这个时钟芯片，而是才用的是系统内部时钟，系统内部时钟的精度不高，所以测试结果不正常。而采用专用的时钟芯片的话就需要用到分频的命令，sync-ether 0 clock 0 recovered-port 0x23 divider 164 output enable link-status-detect enable。对与CTC8180芯片来说，此时时钟来自于时钟芯片，而时钟芯片输出的频率是322.265625Mhz，需要经过165分频得到CTC8180需要的1.953125Mhz时钟。
问题5：当把硬件也调好之后，进行测试，偏差果然正常了，但是会出现-500000000ns的问题，也就是-0.5s的问题，这个已经定位是芯片打时间戳的问题，并不是ptp测试仪的问题。如果是采用Peer Delay(对等延时)机制延时测量则会经常出现这个-0.5s的偏差。如果是Delay Request-Respond(延时请求应答)机制则出现-0.5s的数值会少一点，这两种延时测量的方式就是一个是点对点，一个是端对端。然后点对点的报文会多一点，端对端的报文少一点。最终定位为系统问题，不能及时处理报文导致会有-0.5s的延时。
问题6:由于ctc8180的芯片存在时间戳不能及时打上的问题以及1G接口的时钟不稳定的问题，所以交换芯片采用CTC7132。协议层是不用改变的，但是此时驱动层获取时间戳的方式就不是采用中断上报了（中断就是每触发一次发包事件就上报一次当前时间），而是采用主动获取的方式，通过调用ctc_ptp_get_clock_timestamp()这个接口来获取时间。通过这个接口来获取时间戳的话会出现一个问题，这个时间是协议层来发起的，填到报文中,我们需要填到CF域的时间戳信息是也是协议层获取的时间戳，而不是芯片发包的时间戳。因为这个CF域最终是要减掉的，如果是填芯片发包的时间戳的话，那么协议层到芯片的这一段时间相当于没有减掉，会出现误差。把上述问题解决后，最终测试结果如下：结果正常。
SyncE硬件原理:如下图，当不开启synce的时候，本机的时钟来自于晶振，经过时钟芯片输出给交换芯片，而开启SyncE后，时钟来自于从端口中的恢复时钟，也是经过时钟芯片输出给交换芯片，这两种区别就在于时钟质量的问题，如果是采用synce的时钟，时钟质量可以来自于外部GPS，外部GPS通过端口来产生时钟，很显然这种方式的时钟质量远远高于本地晶振所产生的时钟质量。
