F.11 谬误与陷阱

互连网络领域流传着不少误解，也有许多容易忽略的风险。本节给出若干提醒，设计时应谨慎。

谬误：互连网络已经很快，无须改进

互连网络与存储器、I/O 子系统一样，为系统提供特定功能。设计目标应是让处理器尽可能快地执行指令，因此其带宽必须足够高，避免持续饱和而成为整体瓶颈。

20 世纪 80 年代引入虫孔交换后，用单芯片交换机构建大直径拓扑成为可能，网络带宽容量不再一定是限制因素。这却使人错误地认为互连无须继续改进。自那时以来，人们大量关注处理器性能，对互连的关注相对少得多。随着技术进步，互连在系统资源、成本、功耗，以及其他影响功能和性能的属性中所占比例越来越大。单纯把某些网络参数做得过大以提高带宽，已不再具备成本可行性。设计者必须将端到端互连与处理器、存储器和 I/O 子系统协同设计，满足整个系统的成本、功率、功能和性能目标。带片上网络的多核处理器就是显例。

谬误：二分带宽是网络的准确成本约束

二分带宽虽然很流行，却从未成为实际互连实现的主要约束，尽管未来可能如此。相比成本指标，它更适合做性能指标。芯片引脚数才是更实际的带宽约束。

陷阱：只用带宽，尤其二分带宽，衡量网络性能

网络总带宽或二分带宽很少是端到端真正的瓶颈。即使是，分组穿越二分面的效率几乎从不为 100%，即 $\rho<100\%$；网络端点接收效率也几乎不为 100%，即 $\sigma<100\%$。前者高度依赖路由、交换、仲裁等因素，两者又都高度依赖流量特征。忽略这些因素，只看原始带宽，会严重误判性能。例如，一个网络的总带宽或二分带宽完全可能更高，测量性能却更低。

TCP/IP 等复杂协议能够尽量提高交付带宽，这似乎使不少网络公司相信网络只有一个评价指标。对视频流这类收发双方少有交互的应用，也许如此；但许多应用是请求—响应型，每条大消息都伴随一条或多条小消息，NFS 就是一例。

图 F.41 比较 NFS 流量在共享 10 Mbit/s 以太网 LAN 与交换式 155 Mbit/s ATM LAN 上的表现。以太网驱动优化更好，因此载荷不超过 512 字节时，10 Mbit/s 以太网反而更快。表中分别给出发送全部 NFS 消息的开销、传输及总时间。ATM 峰值链路速度高约 15 倍，8 KB 消息的实测链路速度也近九倍，但较高开销抵消了带宽优势，发送 NFS 流量最终只快 1.2 倍。

**译注：**表内个别行显示的分项之和与显示的总时间不一致。

陷阱：接收链路带宽不足，使端节点更成为性能瓶颈

除非流量模式是一一置换，否则多数源同时注入流量时，一些目的地会同时收到多个分组，从而争用。如果不处理，争用可能演变为拥塞，并传播到整个网络。可通过分析流量模式、提供额外接收带宽应对，例如让接收带宽高于注入带宽。IBM Blue Gene/L 的片上交换机就采用 7 位注入链路、12 位接收链路，接收带宽等于交换机全部输入链路总带宽。

陷阱：使用高性能 NIC，却忘记 NIC 与主机处理器之间的 I/O 子系统

这与上一个问题有关。消息通常先在用户空间缓冲区中组成，再调用通信库发送函数；某些 SAN 和 OCN 也可能由实现一致性协议的 缓存 控制器组成消息。两种情况下，传输前都必须将消息复制到网络接口存储器。如果 I/O 带宽低于链路带宽，或引入较大开销，通信性能会明显受影响。例如，最早上市的万兆以太网卡使用 PCI-X 系统总线接口，其带宽显著低于 10 Gbit/s。

谬误：零复制协议无须在缓冲区之间复制消息或片段

传统计算机网络协议只允许通过特权模式系统调用访问通信设备。因此，发送消息时，通信例程需要将用户缓冲区内容复制到内核缓冲区。协议可能需要保留副本，以便出错重传，而系统调用一旦返回应用，应用就可能修改用户缓冲区。零复制协议的通信例程在用户空间执行，协议也简单得多，因此消除了这一缓冲区到缓冲区的复制。

不过，消息仍须从应用缓冲区复制到 NIC 存储器，网卡硬件才能从那里向网络发送。直接在 NIC 内存分配应用消息缓冲，可以消除这一复制，某些协议确实如此；但这在当时系统中未必方便，因为 NIC 内存通常通过 I/O 子系统访问，远慢于主存。一般更高效的办法，是在主存组成消息，再让 DMA 设备搬到 NIC 内存。

还有一份很少被计入的复制：从计算消息片段的地方，通常为 ALU，结果先在处理器寄存器中，复制到主存。20 世纪 80 年代的某些类脉动体系结构，如 iWarp，能把消息片段从处理器直接送入网络，真正消除全部消息复制。Cray X1E 共享内存多处理器超级计算机也采用这一方法。

接收端同样有类似问题。不过，这并不意味着零复制协议低效；它们代表当时系统使用的最高效实现类型。

陷阱：评估性能时忽略软件开销

要降低软件开销，必须得到操作系统和通信库配合。即使协议卸载，软件开销仍大于硬件开销，绝不能忽略。图 F.32 和 F.41 分别展示 SAN 与 WAN 标准的实例，超级计算机专有 SAN 也有类似情况。20 世纪 90 年代初，Connection Machine CM-5 发送消息的软件开销为 20 μs，硬件仅 0.5 μs。同一时期第一代 Intel Paragon 的硬件开销只有 0.2 μs，初版软件却有 250 μs；后续降至 25 μs，再降到几微秒，仍然主导硬件开销。IBM Blue Gene/L 的 MPI 发送／接收开销约为 3 μs，其中硬件最多只占三分之一。

这不过是 Amdahl 定律在网络中的体现：若软件开销没有同步降低，更快的网络硬件就难以发挥作用。如今 OS bypass、轻量协议和卸载已将软件开销通常降到几微秒甚至更少，但它仍是重要性能因素。

谬误：MIN 比直接网络更具成本效益

MIN 所用交换机通常明显少于待连接设备数。直接网络则往往在每节点内集成交换机，交换机数与节点数相同。但完全可以在一个节点放多个计算设备，例如片上有交换机的多核处理器，或让多个设备连接一台交换机，即 bristling。此时，直接网络的成本效益可以与 MIN 相当甚至更好。注意，MIN 每个节点还可能需要多块网络接口，才能匹配直接网络每节点多条链路的带宽。

谬误：低维直接网络比超立方体等高维网络性能更高

一些研究以二分带宽为主要物理约束，分析最优维数后得出这一结论。但多数研究没有考虑链路流水化，只考虑很短的链路，或忽略交换机体系结构约束。把二分带宽当作主要限制，也使结论失准。如今多数研究者和设计者，包括此前得出相反结论的一部分人，都认为高 radix，即高端口数，交换机比低 radix 更具成本效益。

谬误：虫孔交换比其他交换技术性能更好

虫孔交换与虚拟 cut-through 等流水交换技术的空载延迟相同。20 世纪 80 年代末虫孔交换机出现，恰逢网络带宽大幅增长，许多人便认为性能提升主要来自虫孔交换。实际上，主要收益来自链路带宽急剧提高；而链路带宽提高，是因为虫孔允许用片上缓冲存分组片段，不必使用节点主存或其他片外存储。后来更大的片上缓冲成为可能，虚拟 cut-through 在达到相同空载延迟的同时，提供高得多的吞吐量。但虫孔交换并未因此消失；在只能采用小缓冲的应用中，例如某些 OCN，它仍是首选。

谬误：少量虚拟通道总能让分组越过前方阻塞分组，从而提高吞吐量

一般而言，在虫孔交换机中采用少量虚拟通道是好主意，分组较可能越过前方阻塞分组，降低延迟、显著提高吞吐量。但虚拟 cut-through 的收益没那么大。它的缓冲区应足以容纳多个分组，因此每个虚拟通道都可能引入 HOL 阻塞，高负载下甚至降低性能。增加虚拟通道提高成本，却可能收效甚微，除非通道数与交换机端口数相同，并按目的地映射分组，即使用虚拟输出排队。

虚拟通道当然可以分离不同流量类别，在虚拟 cut-through 网络中很有价值。但按 flit 在物理链路上复用，会让不同虚拟通道的所有分组都受到延迟。若按整分组复用，平均延迟会明显更低；此时又必须限制分组大小，避免一个分组独占大部分链路带宽。

谬误：自适应路由导致乱序，目的端重新排序开销太大

自适应路由让分组根据流量选择不同路径，因此通常会导致乱序交付。但这不必然意味着目的端重排开销很大，以至自适应路由没有价值。例如，迄今最高效的一些算法在部分虚拟通道支持完全自适应路由，同时要求其他通道采用确定性路由避免死锁，IBM Blue Gene/L 就是这样。此时，每个分组都很容易在两者间选择：头部一个比特即可告知交换机，是可用全部虚拟通道，还是只用确定性通道。配合如下协议，就能消除目的端重排开销。

并行计算机和集群的多数通信协议，会按消息大小使用两种机制。短消息采用 eager 协议，直接发送，接收节点用预分配缓冲暂存。长消息采用 rendezvous 协议：先发送控制消息，请求目的端分配足以容纳整条消息的缓冲区；目的端确认分配后，发送者将消息拆成有大小上限的分组并传送。

若 eager 消息只用确定性路由，显然没有重排开销。长消息的分组则可自适应路由，每个分组都含消息内序号或距消息起点的偏移量，因此目的节点能直接放入消息缓冲中的正确位置，相比确定性路由没有额外复制或重排。唯一差别是完成条件：不再只检查消息最后一个分组是否到达，而要累计到达分组，计数与消息大小相符时通知接收完成。长消息即使不频繁，通常也占大部分带宽，所以多数分组都能从自适应路由获益，而无须增加重排开销。

谬误：自适应路由提供备选路径，因此本身总能提高容错能力

仅有自适应路由不足以容忍链路或交换机故障。还需要检测并通知故障的机制，路由逻辑才能排除故障路径、使用剩余路径。而且，同一故障在确定性路由下只影响一定数量的路径，自适应路由下却可能影响更多源—目的节点对。因此，某些自适应交换机在故障时会切换到确定性路由，由源节点选择备选路径。

例如 Cray T3E 用方向顺序路由容忍少量故障，按方向次序使用资源，如 $X^+$、$Y^+$、$Z^+$、$Z^-$、$Y^-$、最后 $X^-$，避免形成环。同时，需要时很容易经非最短路径绕过故障部件；例如，即使分组稍后必须向 $X^-$ 移动，也可先沿 $X^+$ 走几跳。

陷阱：只在网络内部实现功能，而不做端到端实现

问题在于，把只能在最高层完成的功能放到较低层，便只能部分满足通信需求。Saltzer、Reed 和 Clark［1984，第 278 页］提出端到端论证：

只有了解通信系统两端的应用，并得到应用协助，才能完整、正确地规定所讨论的功能。因此，不可能仅把该功能作为通信系统自身的一项特性来完整提供。

他们举了 MIT 一个网络的例子：网络有多个网关，每个都为到下一网关的传输添加校验和。应用程序员误以为校验和保证了准确性，认为消息存于各网关内存期间也受保护。后来一个网关出现瞬态故障，每传输一百万字节就交换一对字节。久而久之，一套操作系统的源代码反复经过该网关，被逐渐破坏。唯一办法竟是将受损文件与纸质程序清单对照，手工修复！如果校验和由端系统应用计算和检查，就能保证安全。

不过，只要有端到端检查，链路级中间检查仍有价值。端到端检查只能发现两节点之间某处出错，不能定位；中间检查可以找出坏掉的部件。

第二个问题是性能。出错时由端点重传整个消息，虽足以保证正确性，但在中间位置只重传消息的一部分，往往比等待端点超时再全部重传快得多。

陷阱：不顾延迟、带宽或软件要求，所有网络一律使用 TCP/IP

早期工作站网络设计者认为，不管消息是发到房间另一头还是大洋彼岸，都采用同一协议栈很优雅，于是都必须付出 TCP/IP 开销。考虑到早期以太网硬件不可靠，这当时也许明智，却为后来的商用系统设下高软件开销门槛。如果消息只走几十米甚至更短，软件却浪费数百微秒，那么低延迟接口硬件和互连就很难获得投入动力。TCP/IP 还会占用大量处理器资源。一个粗略经验是，每 1 Mbit/s 带宽需要约 1 MHz 处理器速度，因此 1000 Mbit/s 链路可能使一颗 800–1000 MHz 处理器饱和。

反过来看，从软件角度 TCP/IP 最有吸引力，因为连接面最广，带来的机会最多。针对某种 LAN 或 SAN 优化的软件，适用范围有限。例如 Java 程序通信依赖 TCP/IP，若为另一协议优化，就必须编写连接 Java 与该协议的适配软件。

TCP/IP 支持者指出，协议本身理论上不必像当时实现那么沉重，但商用系统的进步有限。市场已有 TCP/IP 卸载引擎，希望既保持通用软件模型，又降低处理器占用和消息延迟。如果处理器性能继续远快于网络速度增长，或者多处理器变得普遍，软件 TCP/IP 对处理器占用和消息延迟的影响也可能减弱。