ethtool 不提供物理链路延迟测量值，因其依赖的 MII/GMII 寄存器未定义标准化延迟字段，且 IEEE 802.3 未要求 PHY 上报传播延迟；它仅显示链路状态、速率与双工模式。
ethtool 本身不提供物理链路延迟（如 PHY 层 propagation delay 或 round-trip signal latency）的直接测量值。它能告诉你链路是否 UP、协商速率和双工模式，但无法测出“信号从网卡发出到对端 PHY 返回用了多少纳秒”。真实物理层延迟由线缆材质、长度、PHY 芯片设计决定，Linux 内核不暴露该指标。
为什么 ethtool 没有 Link Latency 字段
以太网标准（IEEE 802.3）未要求 PHY 芯片上报传播延迟；ethtool 读取的是 MII/GMII 寄存器中定义的通用状态位（如 link up/down、speed、duplex），而延迟不是标准化寄存器字段。即使某些高端网卡（如部分 Broadcom 或 Marvell PHY）内部可估算延迟，也未通过 ethtool 接口导出。
能间接反映链路延迟异常的 ethtool 指标
虽然不能读取绝对延迟值，但以下 ethtool 输出可暴露延迟相关的底层问题：
-
Link detected: no或反复 toggle → 物理连接不稳定，常伴随信号反射或长距离衰减，本质是时序对齐失败 -
negotiation_failures非零（ethtool -S eth0 | grep negotiation_failures）→ 自协商超时，说明 PHY 交互响应慢，可能因线缆劣质或模块供电不足 -
rx_errors、rx_length_errors持续增长 +Speed波动 → 误码率升高导致帧重传，等效增加端到端延迟 -
dmesg | grep -i "link.*up\|phy.*reset"中频繁出现 link flap → 表明 PHY 层反复重同步，每次 flap 带来毫秒级中断，业务感知为突发延迟尖峰
替代方案：用 ping 和 tcpdump 定位端到端延迟来源
若你真正关心的是“业务请求变慢”，物理链路只是其中一环。更实用的做法是分层排查：
- 用
ping -c 5 -i 0.1 <gateway_ip></gateway_ip>观察 min/avg/max，若 avg > 1ms 且 jitter 高，先排除本机中断风暴或 CPU 过载（vmstat 1看 si/in 高不高） - 用
tcpdump -i eth0 -c 100 'icmp' && tcpreplay --topspeed -i eth0 tcpdump.pcap对比发送与接收时间戳，确认是否 NIC 发送延迟异常 - 在交换机侧抓包（如有权限），对比两端时间差，才能分离出“线缆+PHY”贡献的单向延迟
真正的物理链路延迟要靠专业仪器（如网络分析仪）测量；日常运维中，盯住 ethtool 的 Link detected 稳定性、negotiation_failures 计数、以及 dmesg 中的 PHY 日志，比试图找一个不存在的“Latency”字段更有效。
