TechBlog

Appearance

RTC、PTP、NTP 与 ROS TimeSync：板端到底是谁在校时 ​

嵌入式板上经常同时存在 RTC、ptp4l、phc2sys、timedatectl 和业务自己的 timesync 节点。看到 NTPSynchronized=yes 后，很容易误以为 NTP 正在运行，或者担心 NTP 与 PTP 同时修改系统时间。

正确做法是先区分每一层的职责。

四种角色 ​

text
RTC ──开机时提供初始 wall clock──> CLOCK_REALTIME

PTP Grandmaster ─> ptp4l ─> PHC
                            │
                            └─ phc2sys ─> CLOCK_REALTIME

NTP client ─────────────────────────────> CLOCK_REALTIME

业务 TimeSync ──映射 PX4 / 传感器时间──> ROS message stamp
  • RTC：断电后保持粗略时间，开机时可通过 hctosys 初始化系统时钟；
  • PTP：通过网卡硬件时钟 PHC 获得高精度网络时间，再由 phc2sys 驯服系统时钟；
  • NTP：另一种网络授时方式，是否在运行要看真实进程和 unit；
  • 业务 TimeSync：把 PX4 boot time、PPS 或传感器 timestamp 映射到系统/ROS 时间，不一定修改 CLOCK_REALTIME。

NTPSynchronized=yes 不是进程清单 ​

timedatectl 的这个字段更接近“系统时钟被标记为已同步”，不能单凭它判断当前时间源一定是 NTP。

判断真实链路应检查：

bash
systemctl --type=service --state=running | grep -E 'ptp|timesync|chrony|ntp'
ps -ef | grep -E 'ptp4l|phc2sys|chronyd|ntpd|systemd-timesyncd'

如果只有 ptp4l 与 phc2sys 在工作，就不存在 NTP/PTP 双主竞争，即使 timedatectl 显示 synchronized。

hwclock 失败不等于 RTC 坏了 ​

普通用户运行 hwclock --show 可能因为设备权限失败。判断 RTC 是否工作，应组合证据：

  • /sys/class/rtc/rtc0/name 与 since_epoch；
  • /dev/rtc0 是否存在；
  • dmesg 是否记录 RTC driver 与 hctosys；
  • 间隔几秒两次读取 since_epoch 是否递增；
  • root 权限下的 hwclock；
  • 真正需要验证保持能力时，再做 reboot 或断电测试。

两次计数递增只能证明 RTC 在走时，不能证明电池、断电保持和长期漂移都正常。

如何找出谁在修改系统时间 ​

建议按顺序检查：

  1. timedatectl 只作为状态入口；
  2. 查实际运行的 time-sync services；
  3. 查 ptp4l 的 port state 与 grandmaster；
  4. 查 phc2sys 的 source/target；
  5. 确认 NTP/chrony 是否同时运行；
  6. 区分业务 timesync 是改系统时钟，还是只改消息 timestamp。

设计原则 ​

生产系统应只有一条明确的 CLOCK_REALTIME 驯服主链。RTC 负责 bootstrapping，PTP 或 NTP 负责持续校准，业务 TimeSync 负责跨时钟域消息映射。把三者分层，才能避免“服务都 active，但没人知道谁是时间真相”的状态。