根本原因是Go默认用time.Now()测时存在调度、GC等抖动，而Linux ping使用CLOCK_MONOTONIC_RAW硬件级单调时钟；建议改用syscall.ClockGettime、禁用deadline、单goroutine循环测量并丢弃极值。
用 digineo-go-ping 发 ICMP 包时，为什么测出来的时间总比 ping 命令大？
根本原因不是代码写错了，而是 Go 默认用 time.Now() 记录时间戳，而系统调用、Go 运行时调度、GC 暂停都会引入抖动。Linux ping 命令直接用 clock_gettime(CLOCK_MONOTONIC_RAW, ...) 获取硬件级单调时钟，绕过内核时间校正和调度干扰。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 不要依赖
time.Now().UnixNano()做微秒级差值——它在 Go 1.20+ 虽已优化，但仍有纳秒级不确定性 - 改用
runtime.nanotime()（非公开 API，不推荐生产）或封装clock_gettime的 syscall（如golang.org/x/sys/unix.ClockGettime） - 对同一目标连续发 5–10 个包，丢弃最大最小值，取中位数而非平均值——网络抖动不服从正态分布
SetDeadline 和 SetReadDeadline 对时延测量的影响
它们控制的是 socket 层超时，不是精度本身，但错误使用会掩盖真实延迟特征。比如设 SetReadDeadline(time.Now().Add(100 * time.Millisecond))，当网络实际 RTT 是 95ms 但偶尔抖动到 105ms，你就会误判为“超时”，而非“高延迟”。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 测量阶段禁用所有 deadline，用独立计时器 +
select+time.After控制整体等待窗口 - 读取 ICMP 回复时，用
conn.ReadFrom配合非阻塞 socket（syscall.SetNonblock），避免被其他 goroutine 调度延迟拖累 - 如果必须用 deadline，请设为预期最大 RTT 的 3 倍（例如局域网设 30ms，跨城设 300ms），并记录每次是否 hit deadline
并发发包时，goroutine 调度如何污染单次测量结果
一个常见误区是起 100 个 goroutine 同时 ping 不同主机，以为“并发 = 精确”。但 Go 的 GMP 调度器不会保证每个 goroutine 在固定时间片内完成；若某次 GC STW 正好发生在某个 goroutine 执行 WriteTo 前，那个包的发送时间就被拉长了 100μs 以上——而这会被计入 RTT。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 单次测量只用 1 个 goroutine，用循环控制多轮测量，避免调度干扰叠加
- 若需批量探测，用 channel 控制并发度（如
sem := make(chan struct{}, 10)），每轮只放行固定数量 goroutine，并在它们全部返回后再启动下一轮 - 关键路径上禁用 GC：在测量前调用
debug.SetGCPercent(-1)，结束后恢复；注意这仅适用于短时测量（
为什么 PTP 协议实现里的时间戳字段不能直接用 time.Now()
PTP 要求时间戳精度达 sub-microsecond 级，而 time.Now() 返回的是 wall clock，受 NTP 校正、闰秒插入、时钟漂移影响。更严重的是，它不反映 packet 实际进出网卡的时刻——那是 NIC 硬件时间戳（hardware timestamping）该干的事。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- Linux 下启用硬件时间戳：
sudo ethtool -T eth0查看支持情况，再用unix.SetSockoptInt开启SO_TIMESTAMPING - 解析
recvmsg返回的unix.Cmsghdr，从中提取SCM_TIMESTAMPING附带的硬件时间戳（unix.TsClockRealtime或unix.TsClockMonotonic） - 不要试图用软件方式“对齐”两个不同来源的时间戳——NIC 时间戳和 CPU 时间戳的偏移本身就需要 PTP 协议去校准
真正影响精度的从来不是代码行数，而是你是否清楚每个时间戳来自哪一层：网卡驱动、内核协议栈、Go 运行时，还是用户空间。混淆它们，再精细的算法也测不准。
