4. 链路层延迟分析：链路层协议、流控机制与重传
好，咱们今天聊聊链路层。很多人觉得链路层就是物理层上面那层“胶水”，没什么好分析的。其实不然。我这些年调过不少IB网络，发现很多莫名其妙的延迟抖动，根子就在链路层。说白了，链路层是数据从A到B的第一道关卡，也是最后一道防线。
4.1 链路层协议：不只是“包”的搬运工
IB的链路层，核心是处理“包”的封装、定界和错误检测。它不像以太网那样用前导码和SFD来同步，IB用的是符号同步和有序集。嗯，这里要注意，IB链路层的数据单元叫Flit（Flow Control Unit），而不是以太网的帧。
Flit的大小是固定的吗？不是。IB链路层支持多种Flit大小，但最常见的是64字节。为什么是64？我猜跟缓存行大小有关，但这不是重点。重点是，Flit是链路层流控和重传的基本单位。
关键点：IB链路层协议定义了Flit的格式，包括起始定界符、数据载荷、CRC校验和结束定界符。其中CRC校验是强制的，用于检测传输错误。
我个人习惯把链路层协议拆成三块来看：
- 定界：怎么知道一个Flit从哪里开始，到哪里结束？IB用特殊的控制符号来标记边界。
- 校验：CRC覆盖整个Flit，包括头部和数据。一旦发现错误，就触发重传。
- 流控：这是重头戏，我们下面细说。
我在项目中遇到过一个问题：某次测试，链路层CRC错误率极低，但应用层就是跑不满带宽。后来发现是Flit定界出了问题，导致接收端频繁丢失同步，触发了链路层复位。你看，链路层协议看似简单，但细节决定成败。
4.2 流控机制：Credit-Based Flow Control
IB的流控机制叫基于信用的流控（Credit-Based Flow Control，CBFC）。这玩意儿跟以太网的暂停帧（Pause Frame）完全是两码事。以太网是“你发太快了，停一下”，IB是“我告诉你我有多少缓冲区，你按这个量发”。
为什么会这样？因为IB的设计目标是零丢包。你想想看，如果接收端缓冲区满了，发送端还在猛发，那只能丢包。丢包就要重传，重传就增加延迟。CBFC就是为了避免这种情况。
CBFC的工作原理是这样的：
- 接收端初始化时，告诉发送端自己有多少个可用的接收缓冲区（即信用）。
- 发送端每发送一个Flit，就消耗一个信用。
- 接收端处理完一个Flit后，返还一个信用给发送端。
- 发送端如果信用耗尽，就必须停止发送，直到收到新的信用。
避坑指南：我曾经遇到过信用更新延迟过高的问题。接收端明明已经处理完Flit了，但信用返还的报文在路上堵车，导致发送端长时间等待。这其实就是链路层延迟的一个隐藏来源。解决办法是调整信用更新的优先级，或者增加初始信用量。
CBFC的延迟影响有多大？我给你们算一笔账：
| 场景 | 信用充足 | 信用耗尽 |
|---|---|---|
| 发送延迟 | 几乎为0 | 等待信用往返时间 |
| 典型值 | < 100ns | 几百ns到几μs |
你看，信用耗尽时的延迟可能比正常情况高出几个数量级。所以，优化CBFC的关键就是保持信用充足。怎么保持？增加接收端缓冲区深度，或者提高信用返还的频率。
4.3 链路层重传：最后的保险
链路层重传，是IB网络保证可靠性的最后一道保险。当接收端检测到CRC错误时，会发送一个NAK（Negative Acknowledgment）给发送端，要求重传那个Flit。
但这里有个问题：重传的延迟是多少？
我给你们画个流程图：
从图上你能看到，一次重传的延迟至少是一个往返时间（RTT）。在IB网络中，RTT通常在几百纳秒到几微秒之间。但如果链路层缓冲区很深，或者重传调度有优先级问题，这个延迟可能会更大。
警告：链路层重传虽然能保证可靠性，但它会引入显著的延迟抖动。如果你的应用对延迟敏感（比如分布式训练中的AllReduce），重传可能导致整个集群的同步时间变长。我曾经在一个192节点的集群上，因为一条链路的CRC错误率偏高，导致训练速度下降了15%。排查了三天才发现是重传引起的。
怎么优化？我建议从这几个方向入手：
- 降低CRC错误率：检查光模块、线缆、连接器。很多时候重传的根本原因是物理层问题。
- 调整重传超时：IB允许配置重传超时时间。太短会导致不必要的重传，太长会增加延迟。我个人习惯设置为RTT的1.5倍。
- 启用FEC：前向纠错（Forward Error Correction）可以在一定程度上避免重传。但FEC本身也会引入延迟，需要权衡。
4.4 链路层延迟的测量与诊断
说了这么多，怎么实际测量链路层延迟呢？我常用的工具是ibdiagnet和ibping。但这两个工具测的是端到端延迟，不是纯粹的链路层延迟。
要测链路层延迟，我建议用回环测试：
# 在发送端和接收端之间建立回环
# 发送端发送一个Flit，接收端原样返回
# 测量往返时间，除以2就是单向链路层延迟
# 示例命令（伪代码）
ib_send_lat -a -d mlx5_0 -n 1000 -s 64
这个命令会发送1000个64字节的报文，并统计平均延迟。注意，这里测的是包括链路层、网络层和传输层的总延迟。要单独看链路层，需要结合硬件计数器。
IB网卡通常提供丰富的硬件计数器，比如：
port_rcv_data：接收数据量port_xmit_data：发送数据量port_rcv_errors：接收错误数symbol_error_counter：符号错误数
我一般会先看symbol_error_counter，如果这个值在增长，说明物理层有问题。然后看port_rcv_errors，如果这个值也在增长，说明链路层重传可能很频繁。
小技巧：用perfquery可以读取这些计数器。我习惯写一个脚本，每隔1秒采集一次，然后画成曲线图。这样能直观地看到链路层延迟的波动情况。
好了，链路层延迟的分析就讲到这里。记住，链路层是IB网络的基石，它的延迟虽然小，但影响很大。优化链路层，就是优化整个网络的稳定性。