Linux 上位机对下位机的 PTP 授时方案
1. 目标与系统结构
本方案使用 Linux 上位机作为 PTP Grandmaster，通过以太网向下位机发送时间同步报文。下位机作为 PTP Slave，调整自身的系统时钟，使两端时间保持一致。
Linux 上位机
enp2s0
Grandmaster
│ Ethernet
│ PTP Sync / Follow_Up / Delay
▼
下位机 Linux
eth1
Slave
当前两端网卡均不支持硬件时间戳。ethtool -T 显示只有：
software-transmit
software-receive
software-system-clock
PTP Hardware Clock: none
因此当前采用软件时间戳模式，PTP 直接使用 Linux 系统时钟。
2. 当前使用的命令
上位机作为 Grandmaster：
sudo ptp4l -i enp2s0 -m -S
下位机作为 Slave：
sudo ptp4l -i eth1 -m -S -s
参数含义：
| 参数 | 含义 |
|---|---|
-i enp2s0 / -i eth1 |
指定 PTP 使用的网卡 |
-m |
将运行状态输出到终端 |
-S |
使用软件时间戳 |
-s |
强制本机作为 Slave |
下位机的 -s 很重要，它可以避免下位机参与主时钟选举并抢占 Grandmaster 角色。
3. 当前日志分析
上位机日志显示：
LISTENING to MASTER
assuming the grand master role
说明上位机已经成为 Grandmaster。
下位机日志显示：
selected best master clock acf466.fffe.4e2e00
LISTENING to UNCALIBRATED
UNCALIBRATED to SLAVE
说明下位机已经发现上位机，并进入 Slave 状态，PTP 报文链路和主从角色基本正常。
日志中最初的偏差约为：
-37527936114501934 ns
这是非常大的初始时间差，约为 1.19 年。随后偏差一度降到毫秒级：
master offset 1566235 ns
master offset 2937741 ns
master offset 4157774 ns
但之后又出现秒级偏差：
master offset -3600184587 ns
freq -100000000
这说明当前已经建立了 PTP 同步关系，但同步过程仍不稳定，尚不能认为已经达到可靠的微秒级授时效果。
另外，日志中的：
foreign master not using PTP timescale
表示主从两端对 PTP 时间尺度的处理可能不一致，或者系统时间与 PTP 时间尺度存在差异。实际部署时应显式统一两端的时间尺度和 linuxptp 配置。
4. 是否需要一直开启 Master 和 Slave
需要。
PTP 是一个持续运行的闭环同步协议。Master 持续发送 Sync 和 Announce 报文，Slave 持续测量偏差、链路延迟，并修正本地时钟频率。因此：
- 只启动 Master，不能完成下位机授时；
- 只启动 Slave，找不到主时钟；
- 停止 Master 后，Slave 会失去同步；
- 停止 Slave 后，下位机时钟会逐渐产生漂移；
- 重新启动后，Slave 通常需要重新进入
UNCALIBRATED和SLAVE状态。
正常部署时，Master 和 Slave 都应作为后台服务持续运行，而不是长期占用终端。开发调试阶段可以使用 -m 前台运行；正式运行时建议配置为 systemd 服务。
5. 运行状态判断
上位机正常状态：
LISTENING to MASTER
assuming the grand master role
下位机正常状态：
LISTENING to UNCALIBRATED
UNCALIBRATED to SLAVE
进入 SLAVE 后，需要继续观察 master offset：
- 稳定在微秒或更低范围：同步效果较好；
- 持续为毫秒级：软件时间戳或系统负载影响明显；
- 偏差重新变成秒级：时钟调整、时间尺度或软件时间戳存在问题；
freq长时间达到+100000000或-100000000：伺服调整达到上限，通常表示初始时间差过大或同步不稳定。
可以使用下面的命令确认 PTP 报文是否正常传输：
sudo tcpdump -ni enp2s0 'udp port 319 or udp port 320'
PTP 使用 UDP 319 和 UDP 320 端口。
6. 正式运行建议
当前命令适合联调：
sudo ptp4l -i enp2s0 -m -S
sudo ptp4l -i eth1 -m -S -s
正式运行时建议：
- 上位机系统时间先通过 NTP、GNSS 或人工方式校准。
- 下位机启动前将系统时间调整到与上位机大致接近，避免初始偏差达到数月或数年。
- 上位机持续运行 PTP Master，下位机持续运行 PTP Slave。
- 用 systemd 设置自动启动和异常重启。
- 应用程序使用同步后的系统时钟生成跨设备时间戳。
- 传感器需要同时采样时，额外使用硬件触发、SYNC 或 PPS 信号。
当前没有 PHC，因此不需要运行 phc2sys。只有网卡支持 PTP Hardware Clock 时，才需要根据时间源方向使用 phc2sys 同步系统时钟和网卡时钟。
7. 精度和限制
当前方案是软件 PTP：
Linux 系统时钟
↓
软件收发时间戳
↓
ptp4l 伺服调整
软件时间戳受 Linux 调度、CPU 负载、网卡驱动、中断合并和交换机排队影响。它可以用于验证 PTP 协议、设备时间关联和低精度授时，但不适合作为严格微秒级机器人传感器同步的最终方案。
如果需要更好的效果，应使用支持以下能力的网卡：
hardware-transmit
hardware-receive
hardware-raw-clock
PTP Hardware Clock: 0
并在传感器采样端使用硬件时间戳。对于相机曝光、IMU 采样和雷达扫描，推荐采用：
PTP：统一设备时间基准
硬件触发或 PPS：统一采样事件
硬件时间戳：记录真实采样时刻
8. 结论
当前测试已经验证：
- 上位机可以成为 PTP Grandmaster；
- 下位机可以通过
-s进入 PTP Slave； - 两端 PTP 报文能够正常交互；
- 软件 PTP 可以将下位机时间向上位机时间靠拢。
当前尚未验证：
- 长时间运行稳定性；
- 稳态同步误差；
- 微秒级同步精度；
- 时间尺度告警的彻底消除。
因此，当前方案可以作为联调和低精度授时方案。要获得稳定的高精度授时，应先统一两端时间尺度，并更换支持硬件 PTP 时间戳的网卡；如果目标是同步采样，还需要增加硬件触发或 PPS。
浙公网安备 33010602011771号