企业官网建设流程全解析

1. 项目概述：为什么要在ZYNQ上做IEEE1588/PTP

做工业控制、电力系统或者5G小基站的朋友，应该对IEEE1588/PTP不陌生。简单说，它就是通过以太网报文，把主时钟的时间精确同步到各个从设备上，精度能做到亚微秒甚至几十纳秒级别。我这次在ZYNQ平台上实现这套方案，核心目的就是解决多节点设备之间的时间同步问题。

先说背景。之前我们用NTP做同步，精度在毫秒级，说实话大部分场景够用。但遇到需要采样数据打时间戳、多台设备协同采集、或者做分布式系统时，毫秒级误差会导致数据严重错位。比如两个设备同时采集电压波形，时间差一个毫秒，波形对不齐，后面的分析全白做。所以必须上PTP，目标是把同步误差压到100ns以内，这样才能满足协同采集和实时控制的要求。

为什么选ZYNQ？因为ZYNQ是ARM+FPGA的异构SoC，ARM端跑Linux系统负责协议栈和上层应用，FPGA端可以做灵活的逻辑扩展。更重要的是，ZYNQ的PS端自带千兆以太网MAC（GEM），支持IEEE1588 v2的硬件时间戳功能。这样就不用在FPGA里用逻辑实现整个MAC协议栈，开发难度大幅下降。

但这里有个关键选择：硬件时间戳到底在哪一层打？这是整个方案的核心分歧点。时间戳可以在MAC层打，也可以在PHY层打，两者的精度差距非常明显。我这次选的是PHY层方案，理由后面详细说。

这篇文章面向的是有一定嵌入式基础的开发者。如果你用过ZYNQ，跑过Linux系统，但对PTP协议实现和硬件时间戳的细节不太清楚，那么这篇文章正好适合你。我会把从原理到实操的完整链路拆开讲，包括PHY芯片选型、硬件接口设计、软件配置、常见坑点，一次性说透。

2. 核心技术拆解：PTP时间同步的基本原理

2.1 主从时钟同步的四步握手

要理解方案设计，得先把PTP的工作原理搞清楚。PTP的核心是主从时钟之间定期交换时间报文，通过四个关键时间点计算出钟差和链路延迟。

假设主时钟是Master，从时钟是Slave。第一次握手，Master发送Sync报文，此时记下发送时间T1；Slave收到Sync报文，记下接收时间T2。这里有个细节，Sync报文可以携带T1时间戳（One-Step模式），也可以不携带，后面靠Follow_Up报文单独发（Two-Step模式）。我们实际用的是Two-Step模式，因为硬件上更容易实现，One-Step需要实时修改报文内容，对硬件逻辑要求更高。

第二次握手，Slave发送Delay_Req报文，记下发送时间T3；Master收到后记下接收时间T4，然后通过Delay_Resp报文把T4回传给Slave。这样Slave手里就有四个时间点：T1、T2、T3、T4。

算出两个值：

偏移Offset = (T2 - T1) - (T4 - T3) / 2，这个值表示Slave和Master之间的时钟偏差。

链路延迟Delay = (T4 - T3) + (T2 - T1) / 2，这个值表示报文在链路上传输的单程延迟（假设双向对称）。

然后Slave用Offset调整本地时钟，就完成了一次同步。这套逻辑看起来不复杂，但真正的难点在于：T1、T2、T3、T4四个时间戳必须极准。如果时间戳打的不准，后面算出来的Offset和Delay全是垃圾数据，同步精度永远上不去。

2.2 时间戳的三个可选位置

以太网报文从应用层到物理线缆，要经过一条完整的路径。这条路径上，任何一个环节都可能引入不确定延迟，所以在哪个位置打时间戳，直接决定最终精度。

第一个位置是应用层打时间戳。在用户态程序里，调用clock_gettime函数拿到当前时间，同时记录报文的发送或接收时刻。这个方案实现最简单，但误差也最大。因为报文从应用层到内核协议栈，再到网卡驱动、MAC、PHY，中间有大量的排队延迟、中断延迟、调度延迟，这些延迟还是动态变化的，可能几微秒到几十微秒不等。所以应用层打时间戳只适合对精度要求不高的场景。

第二个位置是MAC层打时间戳。这是ZYNQ PS端GEM控制器的能力，在报文通过MAC时，控制器自动记录时间。相比应用层，MAC层时间戳已经避开了操作系统调度和协议栈排队的影响，精度可以到几百纳秒级别。但MAC层前面还有PHY在等着，报文从MAC到PHY，再经过PHY内部编解码、PCS、PMA等处理，会有固定延迟和一定范围内的变化延迟。

第三个位置是PHY层打时间戳。这是精度最高的方案，时间戳在报文真正进入物理介质的一瞬间打上，完全避开了MAC内部和PHY内部的处理延迟。目前工业级PHY芯片，比如TI的DP83640、DP83867，Marvell的88E1512，都内置了IEEE1588硬件时间戳单元，可以做到纳秒级精度。

我这次选PHY层方案，目标很直接：精度要压到100纳秒以内，MAC层时间戳的精度不够。搜热词的读者里应该有很多做工业控制的，应该能理解这个需求。如果只是做精度要求不高的同步，MAC层方案能省不少事，但既然标题写了“高效实现方案”，那就直接上PHY层。

2.3 PTP时钟类型与角色分配

除了主从时钟，PTP还定义了多种时钟类型。普通时钟（Ordinary Clock, OC）只有单个PTP端口；边界时钟（Boundary Clock, BC）有多个端口，可以级联；透明时钟（Transparent Clock, TC）只转发PTP报文并修正时间，不参与主从选举。

设计时要考虑设备在网络里的角色。如果所有设备都直接接到一台交换机上，那每个设备都是OC，交换机做TC或者BC。如果设备需要级联组网，那中间的节点就要考虑跑BC或TC。ZYNQ平台的GEM控制器有几个独立的MAC和DMA通道，理论上可以做BC，但软件复杂度会高不少。我们第一批产品只做了OC模式，组网时靠交换机解决级联问题。

另外还有一个概念，PTP OTC。搜索热词里出现了“ptp otc都是什么”，OTC其实是Grandmaster（GM）的候选时钟节点，也就是可能当选为主时钟的设备。在设计时，每个OC节点都可以配置成可当选GM的模式，然后通过最佳主时钟算法（BMC）自动选主。ZYNQ平台跑Linux的话，ptp4l协议栈自带BMC算法，不需要额外开发。

3. 硬件设计要点：ZYNQ与PHY芯片的配合

3.1 以太网MAC和PHY的接口模式

ZYNQ PS端的GEM控制器对外接口有两种常用模式：RGMII和SGMII。

RGMII是并行接口，12根线，时钟125MHz（千兆模式），数据线宽度4位双沿采样。优点是协议简单，驱动容易；缺点是PCB走线要求高，信号完整性要仔细处理。RGMII一般和板级PHY直接相连，PHY内置时钟恢复和自适应均衡，适合板内短距离布线。

SGMII是串行接口，一对差分收发信号，速度1.25Gbps。它把MAC和PHY之间的数据传输变成串行，减少引脚数量，适合板间连接，但逻辑上需要GEM支持SGMII接口。ZYNQ UltraScale+系列的GEM原生支持SGMII，而ZYNQ-7000系列需要借助PL端的SGMII IP核转接。

这里有个很关键的配置坑：用SGMII IP核配合外置PHY芯片时，SGMII IP核不能配置成“PHY模式”或“autonegotiation模式”，必须配置成“MAC模式”。我最初踩过这个坑，IP核默认配置成了PHY模式，结果上行时钟一直反，PTP时间戳完全不对。换成MAC模式后，一切正常。搜热词里提到了“sgmii ip核与phy芯片一起使用时,应配置成mac模式”，这确实是实际项目里反复遇到的问题，各位留意。

3.2 PHY芯片选型：时间戳能力是关键

PHY芯片选型是这套方案里最重要的一步。我梳理了三款主流产品，做个对比：

最后选了Marvell 88E1512，主要考虑是千兆速率（未来带宽扩展空间更大）、RGMII接口方便连接ZYNQ PS端GEM、资料丰富社区活跃度好。但88E1512有个特点需要注意：它的1588时间戳时钟是由外部参考时钟驱动的，需要额外提供一路精确的参考时钟源，一般用25MHz或125MHz的温补晶振（TCXO）或恒温晶振（OCXO）。如果对这个外部时钟不重视，精度会大打折扣。

顺带提一下国产百兆PHY芯片。搜热词里有“国产百兆phy芯片”，说明不少项目正在做国产化替代。国产PHY芯片（比如裕太微的YT8512系列）在成本和供应稳定性上有优势，百兆速率下做IEEE1588需要确认具体型号是否支持硬件时间戳功能。我建议在选型前直接联系原厂FAE，拿到芯片的1588实现细节，避免后期踩坑。

3.3 硬件时间戳参考时钟的设计

硬件时间戳的精度上限由参考时钟的质量决定。PHY芯片内部记录时间戳时，是对参考时钟周期做计数。假如参考时钟是125MHz，理论分辨率为8ns，但实际抖动还受晶振本身的相位噪声影响。

这里提醒一个关键细节：PHY时间戳计数器的时钟频率不一定等于参考时钟频率。像88E1512内部有PLL，参考时钟输入后可以倍频，时间戳分辨率最终取决于内部计数频率。但外部参考时钟的稳定度直接决定了长期同步精度。做现场实测时，我们用100MHz OCXO做参考时钟，和板载普通晶振对比，同样的PTP协议栈，平均同步误差从约80ns降到了约12ns。所以硬件方案里给PHY配一个好晶振，是最值得的投资。

PCB布局上，参考时钟的走线要短、要直，远离开关电源和高速数字信号。如果成本允许，参考时钟旁边放一个LDO单独供电，比直接从电源轨取电的噪声低很多。这些细节看似微不足道，但对同步精度的影响是实打实的。

4. 软件实现：从裸机到Linux

4.1 基于Linux的PTP协议栈方案

ZYNQ平台跑Linux，PTP协议栈的选择基本就是LinuxPTP项目里的ptp4l。这是开源的事实标准，支持绝大多数带硬件时间戳的网卡和PHY，配置灵活，文档也比较多。

架构上分三层：ptp4l跑在应用层，负责协议状态机、BMC、时间计算；内核驱动负责配置网卡和PHY的时间戳功能，并通过SIOCSHWTSTAMP接口给应用层提供时间戳信息；PHY芯片负责在硬件层面记录时间戳。这三层配合得当，才能发挥PHY层时间戳的精度优势。

编译ptp4l需要注意一点：要让ptp4l识别到我们的PHY硬件时间戳能力，需要提供正确的PTP_SYS_OFFSET和PTP_PIN_SETFUNC支持。LinuxPTP通过调用PHY驱动的ptp_clock_info接口来获取时间和Pin功能，如果内核里PHY驱动没有正确实现这些回调，ptp4l就只会用软件时间戳，精度直接掉一个数量级。调试时可以用ethtool -T eth0查看设备的时间戳能力，如果输出里没有hardware-transmit和hardware-receive字样，说明驱动配置有问题。

4.2 内核配置与PHY驱动适配

ZYNQ平台的Linux内核需要配置两大部分：GEM驱动和PHY驱动。

GEM驱动这边，需要在内核设备树里给ethernet节点添加local-mac-address、phy-mode（比如rgmii-id）、phy-handle等属性。具体到1588功能，ZYNQ GEM硬件本身有1588定时器，但我们在PHY层做时间戳，GEM的1588功能就不需要启用，内核里相关的CONFIG_NET_XGENE、CONFIG_XILINX_LL_TEMAC这类配置保持默认即可，不要额外开启。

PHY驱动这边，如果用的是88E1512，内核自带micrel目录下驱动或者由marvell10g驱动继续兼容，具体看内核版本。但marvell PHY的1588功能单独按开放源码驱动，早期版本有bug，时间戳寄存器偏移地址可能不对。建议先测一下：让PHY在环回模式下收自己发的报文，看是否能在ptp4l -H模式下正常工作，如果时间戳明显不准或压根没有，就要查驱动补丁。

设备树里还要给PHY节点加上interrupt-parent和interrupts属性，因为PHY的中断信号需要接到ZYNQ的GPIO上。没有中断驱动，PHY状态变化要靠轮询，延迟高一些，但对PTP报文本身影响不大。真正影响大的是PHY的tx-fifo-depth和rx-fifo-depth配置，这个要在驱动里设置合理值，不然报文在PHY内部排队，时间戳记录时刻会偏移。

4.3 petalinux 2025.1镜像构建与SD卡制作

软件环境上，我们用的是PetaLinux 2025.1。从构建到烧录，流程大致是这样。

先创建PetaLinux工程：

petalinux-create -t project --name zynq_ptp --template zynq cd zynq_ptp petalinux-config --get-hw-description=../hardware_export

硬件描述文件（XSA）从Vivado工程导出。导入后，硬件配置会自动映射到设备树，但PHY相关节点可能需要手动微调。配置内核时，确保开启以下选项：

CONFIG_PPS=y CONFIG_PTP_1588_CLOCK=y CONFIG_PTP_1588_CLOCK_PCH=y CONFIG_NETWORK_PHY_TIMESTAMPING=y CONFIG_MARVELL_PHY=y

这几项缺一不可。NETWORK_PHY_TIMESTAMPING是内核网络子系统对PHY时间戳的支持开关，不开的话驱动上报的时间戳会被内核丢弃；MARVELL_PHY则是88E1512驱动。

接着构建：

petalinux-build petalinux-package --boot --fsbl zynq_fsbl.elf --fpga system.bit --u-boot

生成的文件包括BOOT.BIN、boot.scr、image.ub。对应搜索热词“petalinux 2025.1 zynq 生成boot.bin boot.scr image.ub”，这里说明一下三个文件的职责：

• BOOT.BIN：包含FSBL（First Stage Boot Loader）、bitstream、U-Boot。其中bitstream是PL端配置，即使PL端没用到，也会加载空bitstream。
• boot.scr：U-Boot启动脚本，告诉U-Boot从哪里加载内核和设备树。
• image.ub：打包了Linux内核和设备树，相当于一体化的映像文件。

制作SD卡时，把BOOT.BIN、boot.scr、image.ub三个文件拷贝到FAT32分区的根目录。然后在设备上设置启动模式为SD卡启动（ZYNQ开发板一般是拨码开关），上电就能看到U-Boot启动，自动加载内核。

我再补充一点：BOOT.BIN和image.ub如果是从别的机器拷贝来的，序列号、MAC地址、证书信息可能是错的，会导致网络设备无法上网。我们生产时专门加了一步，在U-Boot里读取板上的EEPROM，动态注入MAC地址，这样每块板的MAC都不冲突。这个细节对PTP没有直接影响，但对网络通信是必须的。

4.4 裸机方案对比：什么时候需要绕开Linux

搜索热词里有“zynq裸机usb”、“zynq裸机usb通信方案 基于libusb”这类，说明不少场景要求裸机实现，不跑完整Linux系统。裸机方案和Linux方案的取舍，本质是精度与时延的权衡。

裸机方案的优势是极低的时延和完全可控的中断处理。没有Linux内核的调度延迟和协议栈排队，PTP同步周期可以做到更短，同步收敛也更快。但裸机方案需要自己实现PTP协议栈，从状态机到报文解析全套自己写，开发量非常大，而且ZYNQ的GEM驱动在裸机下没有官方开源实现可以白嫖，基本参考SDK例程手写。

我自己的建议是：除非你有特别紧急的时延需求（比如同步周期要小于1ms），否则优先用Linux+ptp4l。Linux方案成熟稳定，大批应用层代码可以直接复用，维护成本低一个数量级。我们这次产品碰巧两套方案都做了，Linux版本性能一直很稳，裸机版本只作为某型需要极低时延的设备的备选方案。

5. 实操过程：PHY时间戳的PTP调试实录

5.1 硬件连接与寄存器初始化

硬件连接上用ZYNQ PS GEM的RGMII接口接88E1512。RGMII接口需要配置PHY的时钟方向，我们用rgmii-id模式，让PHY自己处理时钟延迟，省去在PCB上加延时走线的麻烦。设备树里GEM节点的phy-mode就写rgmii-id。

上电后，先通过MDIO总线读取PHY ID寄存器，确认驱动正确识别了芯片：

mdio-tool eth0 phy_read 0x02

正常情况会读到0x0141开头的值（88E1512的PHY ID是0x01410dd1）。如果读出来的值是0xffffffff，说明MDIO时序或PHY地址配置不对，需要回头检查。

接下来初始化PHY的1588功能。88E1512的1588寄存器位于扩展寄存器空间，驱动会在config_aneg或config_init阶段自动配置。如果驱动没有正确初始化，可以在应用层通过ethtool -S eth0查看是否有tx_hwtstamp_ok和rx_hwtstamp_ok计数，这两个值正常应该随收发报文增长。

5.2 ptp4l配置与启动

测试环境里，我搭了一台主时钟设备（同样的ZYNQ板），从时钟设备接到同一台交换机。两边都是Linux + ptp4l。

ptp4l的配置文件/etc/linuxptp/ptp4l.conf里，关键参数如下：

[global] verbose 1 time_stamping hardware ptp_dst_mac 01:1B:19:00:00:00 network_transport L2 delay_mechanism E2E logSyncInterval -6 logAnnounceInterval 0 logDelayReqInterval -6

logSyncInterval -6表示同步报文间隔是2^-6秒，也就是约15.625ms；logDelayReqInterval同理。这两个参数决定同步频率，频率越高精度越高，但占用的网络带宽也越大。在千兆以太网下，15ms间隔完全够用。

启动从时钟设备：

ptp4l -i eth0 -f /etc/linuxptp/ptp4l.conf -m

从时钟会通过BMC选举出一台Master，然后开始周期性同步。正常输出应该显示：

ptp4l[1234.567]: master offset 128 s2 freq +123 path delay 152 ptp4l[1234.567]: master offset 112 s2 freq +121 path delay 149

其中offset表示当前时钟偏差，单位是纳秒。如果这个值稳定在100以内，说明同步已经收敛。这里看到offset在120ns附近，说明我们这套配置精度已经达标。

要注意freq字段是频率偏差，单位ppb，表示本地时钟相对于主时钟的频率偏移。如果freq波动很大，说明晶振品质不行，或者时钟伺服算法没有收敛。

5.3 同步精度的验证方法

验证PTP同步精度，不能光看ptp4l自己报的offset，那只是软件计算值，不代表实际差分时间。我用了三种方法互相印证。

第一种，用两个设备的GPIO产生同步脉冲信号，用示波器对比上升沿。具体做法：主时钟设备在每次PTP同步完成后，拉高GPIO并持续1us；从时钟设备也做同样的动作。示波器接到两个GPIO上，测量两个脉冲上升沿的时间差。这个方法直观，能直接看到硬件层面的同步效果。实测下来，我们这套方案的差分时间最大在180ns左右，平均值约40ns，效果符合预期。

第二种，用专业的PTP测试仪，比如Calnex的Sentinel或oscilloscope厂商的时间戳分析模块，这类设备能解析PTP报文里的时间戳并评估精度。这种方法最准，但测试设备贵，适合实验室阶段。

第三种，软件层面用phc_ctl工具做时钟验证。从时钟设备获取PHC（PTP Hardware Clock）的当前时间，和主时钟对比：

phc_ctl eth0 get

如果PHC时间与主时钟时间相差很小，说明硬件时间戳链路工作正常。如果PHC时间总是慢或快，可以让ptp4l运行一段时间后再对比，排除启动瞬间未收敛的情况。

6. 常见问题与排查技巧实录

6.1 时间戳抖动过大

排查PTP问题时，如果发现ptp4l报的offset一直在几百纳秒到微秒级别来回跳动，说明时间戳本身存在较大抖动。我遇到过的原因有三个。

一是PHY参考时钟的噪声过大，或者参考时钟和MAC时钟不在同一个频点。解决方案：用示波器测参考时钟的频偏和抖动，正常频偏应该在±1ppm以内；有条件的话换TCXO或OCXO试试，对比改善幅度。

二是RGMII接口的时钟延迟配置不对。rgmii-id模式下PHY自己调整延迟，但某些PHY芯片需要额外的rgmii-rxid或rgmii-txid配置。可以反复切换这几种模式，观察offset的变化。88E1512官方推荐rgmii-id，但如果PCB布线长度有偏差，可能需要微调。

三是PHY和MAC之间在运行中出现了CRC错误或链路重协商。可以查看ethtool -S eth0里的rx_crc_errors、rx_missed_errors计数。链路一重协商，PHY的1588时间戳计数器就会跳变，但协议栈恢复后重新收敛需要时间，这段时间内offset肯定大。这种情况要从物理层找问题，比如网线接触不良、RJ45座子焊点虚焊等。

6.2 PHY芯片不产生时间戳

更麻烦的问题是驱动配置正确，但PHY就是不吐时间戳。我排查这类问题有一套固定的顺序。

先确认内核网卡接收路径上开了NET_RX_TIMESTAMP：

cat /proc/net/softnet_stat

如果time_squeeze列的值一直在涨，说明内核软中断处理不过来，报文在驱动层被丢弃或者时间戳来不及读取。这时要调大网卡队列长度：

ethtool -G eth0 rx 1024 tx 1024

如果网卡层面的软中断没问题，再去查驱动是否用了正确的PHY时间戳读取接口。Linux内核从4.16开始引入struct skb_shared_hwtstamps机制，PHY驱动要在接收中断里通过skb_hwtstamps(skb)写入时间戳。查看驱动源码，确认PHY中断处理函数里有没有调用ptp_clock_event。如果没有，说明驱动的1588功能可能没被正确注册。

还有一种情况是PHY的1588功能被当成了普通PHY功能，被内核的BYPASS逻辑关闭。这就要在内核配置里确保CONFIG_PHYLIB下的相关选项没有被裁剪，尤其是CONFIG_NETWORK_PHY_TIMESTAMPING。

6.3 同步精度无法收敛

有些时候，设备之间能同步上，但offset就是无法收敛到100ns以内，一直保持微秒级。这时要检查的是PTP报文传输链路的对称性。

PTP计算延迟的公式默认收发链路延迟是相等的。如果交换机端口、网线、PCB走线导致收和发的延迟不对称，算出来的Offset就会有系统性偏差。解决办法是用交换机的1588 TC功能，或者改为P2P透明时钟模式，让交换机加入时间修正计算。

软件层面，检查ptp4l的delay_mechanism是否为E2E。如果网络里有不支持1588的交换机，E2E模式不要求交换机参与计算，只是把交换机的排队延迟当作对称误差的一部分。虽然这会引入一定误差，但实测在普通千兆交换机下，这个误差通常在百纳秒级，还能接受。

如果真的需要高精度，就得让每台设备的PHY参考时钟都做tracing，或者直接上同步以太网（SyncE）方案，让物理层时钟和PTP主时钟锁定。当然这已经超出PHY时间戳的范畴了，属于另一个层面。

6.4 FSBL文件缺失与Flash操作报错

搜索热词里还有“zynq fsbl file needed x a valid fsbl file is required for flash operation fo”。这个是Vivado/SDK里烧写Flash时的常见问题。

当你在SDK里用Program Flash或者qspi-flash工具烧写BOOT.BIN时，如果工程里没有导入或者没有正确指定FSBL文件，就会提示“a valid fsbl file is required for flash operation”。解决办法是在烧写前，先把FSBL编译出来，并且确保FSBL文件和BOOT.BIN配套。

注意FSBL需要和PL端bitstream匹配。如果bitstream里包含PL端逻辑，FSBL必须能正确初始化PL端时钟和引脚，否则PTP相关的硬件模块不会工作。我们实际调试时踩过一次：换了bitstream但忘了重新生成FSBL，结果板子上电后PHY的引脚一直不认，后来重新用SDK生成FSBL才解决。

7. 经验总结与扩展方向

做这套系统，最有价值的认知是：PTP时间同步不是简单的软件配置，而是一个“硬件基线 + 协议栈 + 系统环境”协同优化的整体工程。硬件时间戳只能保证时间戳足够准，但如果软件链路没有把时间戳正确传递到应用层，或者系统里有中断风暴、定时器抖动，最终同步精度一样会被拖垮。

我个人的体会是，ZYNQ平台做IEEE1588方案，最大的便利在于ARM端有成熟Linux生态，ptp4l可以白嫖；最大的坑在于硬件的时钟链路细节，尤其是PHY参考时钟和RGMII接口时序。这两块只要处理好，精度做进100ns是完全可行的

如果项目后续要扩展，有两个方向值得考虑。一个是做边界时钟，ZYNQ的多个GEM口可以同时跑PTP，实现多端口级联；另一个是和FPGA逻辑联动，比如把PHY的时间戳直接映射到PL端的AXI寄存器，这样FPGA逻辑也能拿到PTP时间，便于做同步采样和触发信号。

最后再分享一个小技巧：在现场调试时，多准备几根高质量的成品网线，千万别用自制网线。百兆千兆以太网对链路质量很敏感，接触到不良链路导致的重协商，会把你的PTP同步精度直接打回原形。这个教训，我们是在现场被折腾了一整天才得到的。