第2章延迟基础概念

2. 延迟基础概念：延迟的定义、延迟的组成与测量单位

聊IB网络，绕不开一个词——延迟。

我见过不少刚入行的朋友，一上来就盯着带宽看。带宽当然重要，但说实话，在高性能计算集群里，延迟才是那个真正卡脖子的东西。你想想看，一次MPI通信，数据量可能不大，但来回几十万次，每次多花一微秒，累积起来就是灾难。

延迟，简单说就是数据从源头到目的地所花的总时间。嗯，这个定义听起来很直白，但实际落地时，很多人会把它和响应时间搞混。

我个人的习惯是这么区分的：延迟是单向的，数据从A到B的时间；而响应时间往往是往返的，包含了处理时间。在IB网络里，我们更关心的是单向延迟，尤其是端到端的延迟。

核心定义：延迟 = 数据包从发送端网卡发出，到接收端网卡完整接收的时间差。

注意，这里不包括应用层的处理时间，只算网络部分。

我曾经在一个项目中，客户抱怨说他们的AI训练任务延迟很高。我上去一查，发现他们统计的是应用层的往返时间，里面包含了GPU拷贝、CPU处理、甚至日志写入的开销。这其实不是网络延迟，而是端到端响应时间。所以，定义清楚测量边界，是第一步。

延迟不是铁板一块。它由三部分构成：传输延迟、处理延迟、排队延迟。我习惯把它们拆开来看，因为优化手段完全不同。

这是物理定律决定的。光在光纤里跑，电在铜缆里跑，速度是固定的。传输延迟 = 距离 / 信号传播速度。

举个例子：两台机器隔着100米光纤，光速约2×10⁸ m/s（光纤中约是真空的2/3），那传输延迟就是100 / (2×10⁸) = 0.5微秒。这个数字，你换什么协议都改不了。

所以，我经常跟团队说：想降传输延迟？把机器搬近一点。 这不是玩笑。在AI集群里，GPU服务器之间的物理距离，直接影响AllReduce的完成时间。

这部分就复杂了。数据包进入网卡、交换机、路由器，每一站都要做处理：查路由表、做CRC校验、解析包头、转发决策……这些都需要时间。

在IB网络里，处理延迟主要来自：

网卡侧：DMA传输、协议解析、内存拷贝。我记得有一次调优，发现网卡驱动里一个中断合并参数没开对，处理延迟直接多了2微秒。
交换机侧：查转发表、内部交换矩阵调度。高端IB交换机（比如QM9700）的cut-through延迟能做到100纳秒以内，但store-and-forward就慢多了。
CPU侧：中断响应、上下文切换。这个我后面会专门讲，CPU处理延迟往往是最大的坑。

我的经验：处理延迟是唯一可以通过软件和硬件调优来大幅降低的部分。传输延迟你改不了，排队延迟你只能缓解，但处理延迟——从驱动到固件到CPU亲和性——处处都是优化空间。

这是最让人头疼的部分。当多个数据流同时涌向同一个端口，交换机或网卡的缓冲区就开始排队。排队延迟 = 队列长度 × 每个包的服务时间。

为什么会排队？说白了就是瞬时流量超过了处理能力。在AI集群里，AllReduce的同步屏障经常导致所有节点同时发数据，瞬间把交换机端口打满。

我曾经遇到一个案例：训练ResNet-50时，每次迭代的尾延迟（tail latency）忽高忽低。排查了三天，最后发现是某个交换机的出口队列在拥塞时深度不够，导致丢包重传。嗯，丢包重传的延迟，比正常排队高一个数量级。

注意：排队延迟不是线性的。当队列接近满时，延迟会急剧上升。这就是为什么我们常说“延迟的90百分位比平均值重要得多”。

在IB网络里，我们常用的单位是：

你可能会问：为什么不用秒？因为在高性能计算里，秒这个单位太大了。一次GPU kernel launch可能就几十微秒，一次RDMA READ操作在IB里能做到1-2微秒。用秒来度量，小数点后面得写一堆零。

我个人习惯，在IB网络调优时，所有延迟数据都统一用微秒。为什么呢？因为纳秒级的数据，普通测量工具（比如软件打时间戳）根本测不准，误差比信号本身还大。而毫秒级，又太粗糙，看不出微小的波动。

实用建议：用微秒作为基准单位。交换机延迟看纳秒，但最终端到端延迟，微秒就够了。记住：1微秒 = 1000纳秒，在IB网络里，1微秒的优化就是巨大的进步。

下面这张图，是我自己梳理的延迟知识框架。你可以把它当作本章的思维导图：

这张图把延迟拆成了三个维度。你从左边看，是物理层面的限制；中间是软硬件协同的处理开销；右边则是流量行为导致的动态延迟。三者叠加，才是你最终测到的端到端延迟。

这一章我们聊了延迟的基础。说白了，就是三件事：

嗯，基础打牢了，后面我们才能谈怎么测、怎么优化。下一章，我会带你看看实际测量延迟的那些坑——软件打时间戳不准、PTP同步误差、以及我踩过的那些雷。