真重传率必须用/proc/net/snmp中TCPRetransSegs与TcpOutSegs的增量比值计算，即(RetransSegs₂−RetransSegs₁)÷(OutSegs₂−OutSegs₁)，绝对值相除会失真；>0.5%需关注，>2%说明链路明显丢包。
直接看 /proc/net/snmp 的增量比值才是真重传率
Linux 没有“实时重传率”命令，TCPRetransSegs 和 TcpOutSegs 必须用差值相除才有效——绝对值相除会严重失真。执行：cat /proc/net/snmp | grep -A1 Tcp | tail -n1，输出类似：Tcp: RtoAlgorithm RtoMin RtoMax InSegs OutSegs RetransSegs InErrs
第 11 列是 OutSegs（总发出段数），第 15 列是 RetransSegs（已重传段数）。用 watch -n1 轮询 5–10 秒，手动记两组值，算：(RetransSegs₂ − RetransSegs₁) ÷ (OutSegs₂ − OutSegs₁)
结果 > 0.005（0.5%）需关注；> 0.02（2%）说明链路已明显丢包。
别信 sar -n TCP，它根本不存在
sar -n TCP 是个无效命令：内核源码和官方文档里都没有这个子选项，执行后要么报错 Unknown subsystem TCP，要么静默忽略、返回其他协议层数据（比如 DEV）。真正能用的是：sar -n ETCP 1 3，它输出 retransmit（累计重传段数）、orsts 等字段，但仍是快照，仍需你自己做差值；sar -n EDEV 1 3 可查物理层错误：rxerr/s、txerr/s 持续 > 0，说明网卡或交换机异常，可能诱发上层重传。
Linux AI 服务器 — 将 Linux 服务器转换为本地 AI 推理集群。使用 systemd、NVIDIA CUDA 实现无头 Linux AI，零 GUI 开销。
ss -ti 的 retransmits 不是重传段数，是超时次数
ss -ti 输出末尾的 retransmits 字段只统计 RTO 超时重传次数，不包括快速重传、SACK 重传或 TLP。这意味着：
– 即使 TCPRetransSegs 每秒涨几十，retransmits 也可能为 0
– 该值在连接关闭后清零，无法回溯历史
– 它对应 /proc/net/snmp 中的 TCPTimeouts，不是 TCPRetransSegs
真要定位高重传流，先用 ss -tunap 找目标四元组，再加 -i 查其 retransmits；若值 > 0 且持续增长，才说明该流路径存在稳定丢包。
冲突率？Linux 不统计以太网冲突，除非是老式半双工网络
现代全双工交换网络中，coll/s（冲突数）恒为 0，sar -n DEV 或 ethtool -S 里的冲突计数器已无实际意义。所谓“冲突”在当前环境下基本等价于：
– rx_discards（驱动丢包）：接收队列满或内存不足
– tx_aborted_errors（发送中止）：物理链路问题（网线松动、光模块故障、协商失败）
– ip_forward 关闭导致的 IP 层丢包
排查优先级应是：先看 /proc/net/snmp 重传率 → 再查 ethtool -S 的 rx_discards 和 tx_aborted_errors → 最后用 tcpdump 抓包确认是否真有重传包。
