An In-Depth Analysis of the Slingshot Interconnect

作者/机构: Daniele De Sensi (ETH Zurich), Kim H. McMahon (Hewlett Packard Enterprise), Salvatore Di Girolamo (ETH Zurich), Duncan Roweth (Hewlett Packard Enterprise), Torsten Hoefler (ETH Zurich)

A1 主要贡献

本文深入分析了为大规模计算系统设计的 Slingshot 互连网络。随着系统规模的扩大，互连网络对应用性能的影响日益关键，特别是在高性能计算（HPC）领域，通信密集型应用的性能远低于计算密集型应用。为了应对 HPC、数据中心和 AI/ML 工作负载融合带来的挑战，Slingshot 旨在解决以下核心问题：
1. 大规模系统下的可扩展性与效率：如何构建能够支持百亿亿次（Exascale）和超大规模（Hyperscale）数据中心的网络，同时保持低延迟和高吞吐。
2. 与现有生态系统的兼容性：如何设计一个高性能网络，使其能与数据中心广泛采用的标准以太网设备无缝集成。
3. 应对网络拥塞和噪声：如何减少由共享网络资源的其他应用造成的干扰（网络噪声），并有效管理拥塞，特别是降低对延迟敏感应用的尾延迟。

为实现上述目标，Slingshot 提出并实现了以下关键特性与创新点：
- 高基数交换机和低直径拓扑：采用 64 端口、每端口 200 Gb/s 的高基数 ROSETTA 交换机，构建 Dragonfly 拓扑，确保在百亿亿次级系统中任意两点间的通信最多只需三次交换机到交换机的跳步。
- 先进的自适应路由和拥塞控制：实现了高效的自适应路由算法，可根据网络负载动态选择多条最小或非最小路径中的最优路径。其硬件实现的拥塞控制机制能精确跟踪每对端点间的在途数据包，快速对拥塞源施加反压，从而有效隔离应用，减少网络噪声。
- 高度可定制的服务质量（QoS）：提供高度可调的流量类别（Traffic Classes），允许系统管理员为不同作业或通信模式分配不同的优先级、带宽保证和路由策略，实现细粒度的性能隔离。
- 增强的以太网协议：在保持与标准以太网完全兼容的基础上，Slingshot 引入了优化的以太网协议，包括更小的最小帧大小、链路级可靠性（LLR）和端到端重传机制，为 HPC 应用提供低延迟、低开销和高可靠性的通信。

本研究通过在微基准测试、HPC、数据中心及 AI 应用上的实验，系统地评估了 Slingshot 的这些特性。研究发现，与上一代网络相比，运行在 Slingshot 上的应用受拥塞的影响显著减小，证明了其设计的有效性。

A2 方法细节

II-A 交换机技术 (ROSETTA)

ROSETTA交换机核心规格。Slingshot 互连的核心是 ROSETTA 交换机，它提供 64 个双向 200 Gb/s 的端口。每个端口使用四条 56 Gb/s 的串行器/解串器（SerDes）模块，并采用四电平脉冲幅度调制（PAM-4）技术。由于前向纠错（FEC）的开销，每条通道的有效数据速率为 50 Gb/s。ROSETTA ASIC 采用台积电（TSMC）的 16 纳米工艺制造，功耗最高可达 250 瓦。该交换机由 32 个外围功能块和 32 个瓦片块（tile block）组成。外围块实现了 SerDes、介质访问控制（MAC）、物理编码子层（PCS）、链路层可靠性（LLR）以及以太网查找功能。

ROSETTA交换机的分层瓦片结构。32 个瓦片块实现了 64 个端口之间的交叉开关（crossbar）功能，并负责处理自适应路由和拥塞管理。如图 1 所示，这些瓦片被组织成四行八列的结构，每个瓦片处理两个交换机端口。同一行上的瓦片通过 16 个行总线（per-row buses）连接，而同一列上的瓦片则通过专用通道和列交叉开关（per-tile crossbars）连接。每个行总线用于将数据从其对应端口发送到该行上的其他 16 个端口。列交叉开关有 16 个输入（来自该行的 16 个端口）和 8 个输出（通往该列的 8 个端口）。对于每个端口，一个多路复用器用于从四个输入中选择一个（为清晰起见，图中未明确显示）。数据包最多通过两跳即可路由到目标瓦片。图 1 展示了一个例子：如果一个数据包在端口 19 接收到，并且需要路由到端口 56，它首先在行总线上路由，然后通过图中高亮的 16-to-8 交叉开关，再沿着列通道向下到达端口 56。由于这种分层瓦片结构，系统无需一个 64 端口的仲裁器，数据包只需经历一次 16 到 8 的仲裁。

功能专用的内部交叉开关。ROSETTA 中的 32 个瓦片实现了 64 个端口间的交叉开关。出于性能和实现复杂度的考虑，这个交叉开关在物理上由多个功能专用的交叉开关组成，每个都处理交换流量的不同方面：
- 发送请求 (Requests to Transmit): 为了避免线头阻塞 (Head-of-Line blocking, HOL) 【索引13，W. H. Tranter 等人，Input Versus Output Queueing on a SpaceDivision Packet Switch，2007】，ROSETTA 采用了一种虚拟输出排队架构【索引14，Y. Tamir 和 G. L. Frazier，High-performance multiqueue buffers for vlsi communication switches，1988】【索引15，Thomas E. Anderson 等人，High-speed switch scheduling for local-area networks，1993】，其中路由路径在数据发送前就已确定。数据被缓存在输入缓冲区中，直到资源可用，确保后续不再有阻塞。在转发数据之前，会向对应于交换机输出端口的瓦片发送一个发送请求。当从输出端口收到发送许可后，数据才会被转发。
- 发送许可 (Grants to Transmit): 发送许可是由处理输出端口的瓦片发送给接收数据包的瓦片。在之前的例子中，许可将从处理端口 56 的瓦片传输到处理端口 19 的瓦片。许可用于通知可以向下一跳转发数据。发送请求和许可的使用是服务质量（QoS）管理的核心部分。
- 数据 (Data): 数据在一个更宽的交叉开关（48字节）上传输。为了加速处理，ROSETTA 在数据包头部到达时就立即进行解析和处理，即使数据部分可能仍在传输中。
- 请求队列信用 (Request Queue Credits): 信用提供了队列占用情况的估计。自适应路由算法（见 II-C 节）利用这些信息来评估不同路径的拥塞程度，并选择最不拥塞的路径。
- 端到端确认 (End-to-End Acks): 端到端确认用于跟踪每对网络端点之间未完成的数据包。拥塞控制协议（见 II-D 节）使用这些信息。
通过使用物理上分离的交叉开关，Slingshot 确保了不同类型的消息不会相互干扰，例如，大数据传输不会减慢发送请求和许可的速度。

交换机延迟分析。为了分析交换机架构对延迟的影响，我们在图 2 中报告了交换机处理 RoCE 流量时的延迟。值得注意的是，因为我们使用的是标准的 RoCE 网卡，网卡发送的是普通的以太网帧，所以我们无法利用 Slingshot 专用以太网协议（II-F 节）的所有特性。但一些特性，如链路级可靠性和拥塞信息传播，仍在交换机间的通信中使用。为了计算交换机延迟，我们考虑了 2 跳和 1 跳延迟之间的差值（拓扑结构细节见 II-B 节）。我们观察到 ROSETTA 的平均和中位延迟为 350 纳秒，除了少数异常值外，整个分布都位于 300 到 400 纳秒之间。

II-B 拓扑

默认拓扑结构：Dragonfly。ROSETTA 交换机可以被组织成任意拓扑。Dragonfly 【索引12，J. Kim 等人，Technology-driven, highlyscalable dragonfly topology，2008】是基于 Slingshot 的系统的默认拓扑，也是本文后续讨论所参照的拓扑。Dragonfly 是一种分层的直接拓扑结构，其中所有交换机都同时连接到计算节点和其他交换机。一组交换机相互连接，形成所谓的“组”。每个组内的交换机可以使用任意拓扑连接，而组与组之间则以全连接图的方式连接。在 Slingshot 实现的 Dragonfly 拓扑（如图 3 所示）中，每个 ROSETTA 交换机通过铜缆（最长 2.6 米）连接到 16 个端点，剩余的 48 个端口用于交换机间的连接。这 48 个端口在组内和组间连接中的分配，以及每组的交换机数量，取决于系统的规模。在 Slingshot 中，一个组内的交换机总是通过铜缆实现全连接。不同组的交换机则通过长距离光缆（最长 100 米）连接。由于组内和组间都是全连接的，这种拓扑的直径为 3 次交换机到交换机的跳步。

节点分配对性能影响的分析。由于其低直径特性，应用性能对特定节点分配的依赖性很小。我们在图 4 中报告了在一个隔离系统中，不同距离节点之间以及不同消息大小下的延迟和带宽。我们考虑了连接到同一交换机上端口的节点（1 次交换机间跳步）、连接到同一组内两个不同交换机的节点（2 次交换机间跳步），以及连接到两个不同组内两个不同交换机的节点（3 次交换机间跳步）。对于同一交换机的情况，我们观察到使用同一交换机瓦片上的两个端口或不同瓦片上的两个端口没有显著差异。首先，我们观察到，在最坏情况下，对于 8B 消息，节点分配对延迟的影响仅为 40%，而从 16KiB 消息开始，不同节点距离之间的延迟差异小于 10%。带宽情况也类似，在所有消息大小下，不同距离之间的差异小于 15%。在某些情况下，当节点位于两个不同的组时，我们观察到带宽略高，因为连接两个节点的路径更多，从而增加了可用带宽。

Slingshot拓扑的可扩展性。在最大的系统配置中（如图 3 所示），每个组有 32 个交换机（总共 32 × 16 = 512 个节点），组内交换机通过使用 31 个交换机端口实现全连接。每个交换机剩余的 17 个端口用于将所有组以全连接网络的方式全局连接起来。在这种特定情况下，因为每个组包含 32 个交换机，且每个交换机使用 17 个端口连接到其他组，所以每个组有 32 × 17 = 544 个指向其他组的连接。这构成了一个拥有 545 个组的系统，每个组连接到 512 个节点，总共可支持 279,040 个端点，并提供完整的全局带宽。这个端点数量满足了百亿亿次超级计算机和超大规模数据中心的需求。实际上，这比数据中心使用的服务器数量【索引16，A Peek Inside Amazon’s Cloud，2016】还要多，并且远超当前性能最强的超级计算机 Summit 【索引17，Summit Supercomputer】所使用的 4,608 个节点。得益于如此多的端点，每个计算节点可以有多个连接到同一网络，从而增加了注入带宽，并在网卡故障时提高了网络弹性。

II-C 路由

Dragonfly网络中的多路径特性。在包括 Slingshot 在内的 Dragonfly 网络中，任意一对节点之间都存在多条最小路径和非最小路径【索引12，J. Kim 等人，Technology-driven, highlyscalable dragonfly topology，2008】【索引18，Maciej Besta 等人，FatPaths: Routing in Supercomputers, Data Centers, and Clouds with Low-Diameter Networks when Shortest Paths Fall Short，2019】。例如，考虑图 3 中的拓扑，连接 N0 和 N496 的最小路径包括交换机 S0 和 S31。在较小的网络中，由于链路的冗余性，任意一对节点之间都存在多条最小路径【索引18，Maciej Besta 等人，FatPaths: Routing in Supercomputers, Data Centers, and Clouds with Low-Diameter Networks when Shortest Paths Fall Short，2019】。另一方面，一条可能的非最小路径会经过一个同时直接连接到 S0 和 S31 的中间交换机。对于位于不同组的节点也是如此，此时非最小路径会穿过一个中间组。

Slingshot的自适应路由机制。在空闲网络中，通过最小路径发送数据显然是最佳选择。然而，在存在多个活动作业的拥塞网络中，这些路径可能比更长但拥塞程度较低的路径要慢。为了提供最高的吞吐量和最低的延迟，Slingshot 实现了自适应路由：在发送数据包之前，源交换机估计多达四条最小和非最小路径的负载，并根据路径的拥塞程度和长度综合考虑，将数据包发送到最佳路径上。拥塞程度是通过考虑每个输出端口的请求队列总深度来估计的。这些拥塞信息通过一个环路在芯片上分发给每个输入端口的转发块，并且通过搭载在确认包中在相邻交换机之间进行通信。拥塞和负载信息的总开销平均为前向传输的每个数据包在反向产生四个字节。随着更多数据包走非最小路径，每个数据包的平均跳数增加，延迟和链路利用率都会上升。因此，Slingshot 的自适应路由会偏向于让数据包更频繁地选择最小路径，以补偿非最小路径带来的更高成本。

II-D 拥塞控制

拥塞类型与传统控制机制的局限性。互连网络可能受到两种拥塞的影响：端点拥塞和中间拥塞【索引6，Sudheer Chunduri 等人，Gpcnet: Designing a benchmark suite for inducing and measuring contention in hpc networks，2019】。端点拥塞主要发生在最后一跳的交换机上，而中间拥塞则分布在整个网络中。自适应路由通过改变数据包的路径来避免中间拥塞，从而提高网络利用率和应用性能。然而，即使自适应路由可以绕过拥塞的中间交换机，两个节点之间的所有路径都会同样受到端点拥塞的影响。正如我们在 III-A 节中所示，这在其他网络中是一个相关问题，特别是对于多对一的通信模式。在这种情况下，由于接收端链路高度拥塞，自适应路由会将数据包分散到不同路径上，但无法避免拥塞，因为它发生在最后一跳。拥塞控制通过降低产生拥塞的节点的注入带宽来缓解此问题。然而，现有的拥塞控制机制（如 ECN 【索引19，Sally Floyd，Tcp and explicit congestion notification，1994】和 QCN 【索引20，IEEE 802.1Qau – Congestion Notification】【索引21，Yibo Zhu 等人，Congestion control for large-scale rdma deployments，2015】）并不适用于 HPC 场景。它们通过标记经历拥塞的数据包来工作。当一个节点收到被标记的数据包时，它会请求发送方降低其注入速率。这些拥塞控制算法在处理大流量且稳定的通信（即大象流）时效果尚可，但往往很脆弱、难以调优【索引22，Yibo Zhu 等人，Ecn or delay: Lessons learnt from analysis of dcqcn and timely，2016】【索引23，Y. Gao 等人，Dcqcn+: Taming large-scale incast congestion in rdma over ethernet networks，2018】，并且通常不适合突发性的 HPC 工作负载。实际上，在标准的拥塞控制算法中，控制回路太长，无法足够快地适应变化，在收敛到正确的传输速率之前，违规流量仍然会干扰其他应用。

Slingshot的硬件拥塞控制方法。为了缓解这个问题，Slingshot 引入了一种复杂的拥塞控制算法，该算法完全在硬件中实现，能够跟踪系统中每对端点之间所有在途的数据包。Slingshot 能够区分出拥塞的受害者和拥塞的贡献者，并对正在造成拥塞的源头施加迅速而严厉的反压。通过独立跟踪所有的端点对，Slingshot 只限制那些造成端点拥塞的数据包流，而不会对其他未造成拥塞的作业或同一作业内的其他数据包流产生负面影响。这为其他作业释放了缓冲区空间，避免了整个网络的线头阻塞，并降低了尾延迟，这对于以全局同步为特征的应用尤其重要。Slingshot 采用的拥塞控制方法与更传统的方法（如基于 ECN 的拥塞控制【索引19，Sally Floyd，Tcp and explicit congestion notification，1994】【索引20，IEEE 802.1Qau – Congestion Notification】）有根本不同，并能在不同应用之间实现良好的性能隔离，正如我们在 III-A 节中展示的那样。

II-E 服务质量 (QoS)

QoS与拥塞控制的正交关系。尽管拥塞控制在一定程度上保护了作业免受相互干扰，但作业之间仍然可能相互影响。为了提供完全的隔离，Slingshot 允许将作业分配到不同的流量类别（traffic classes），并提供有保障的服务质量。QoS 和拥塞控制是正交的概念。实际上，由于流量类别是需要大量交换机缓冲空间的昂贵资源，每个流量类别通常由多个应用共享，因此在单个流量类别内部仍然需要应用拥塞控制。

流量类别的可调优性与应用。每个流量类别都是高度可调的，系统管理员可以根据优先级、数据包排序要求、最小带宽保证、最大带宽限制、有损性以及路由偏好【索引5，Daniele De Sensi 等人，Mitigating network noise on dragonfly networks through application-aware routing，2019】进行定制。系统管理员需要确保不同流量类别的最小带宽需求总和不超过可用带宽。网络流量可以按数据包进行流量类别分配。作业调度器会为每个作业分配少量的流量类别，然后用户可以选择将其应用流量发送到哪个类别。对于 MPI，这是通过在环境变量中指定流量类别标识符来完成的。此外，通信库甚至可以在每个消息（或每个数据包）的粒度上更改流量类别。例如，MPI 可以将不同的集合操作分配到不同的流量类别。比如，它可以将对延迟敏感的集合操作（如 MPI_Barrier 和 MPI_Allreduce）分配给高优先级、低带宽的流量类别，而将大块的点对点操作分配给高带宽、低优先级的类别。

QoA的硬件实现。流量类别完全在交换机硬件中实现。交换机通过数据包头中的差分服务代码点（Differentiated Services Code Point, DSCP）标签【索引24，Differentiated Services Codepoint (DSCP) - RFC 3260】来确定特定数据包所需的流量类别。根据标签的值，交换机将数据包分配到多个虚拟队列之一。每个交换机将为每个流量类别分配足够的缓冲区以达到期望的带宽，而剩余的缓冲区将动态分配给未指定任何特定流量类别的流量。

II-F 以太网增强功能

以太网兼容性与性能优化。为了提高互操作性并更好地适应数据中心场景，Slingshot 完全兼容以太网，并且可以无缝连接到第三方的基于以太网的设备和网络。Slingshot 在标准以太网之上提供了额外的功能，从而提高了其性能，使其更适合 HPC 工作负载。Slingshot 对内部流量使用这种增强协议，但可以在所有端口上以数据包级粒度与标准以太网流量混合。这使得 Slingshot 在实现高性能的同时，也能够与标准以太网设备通信，使其能够高效地用于超级计算和数据中心领域。

具体的增强特性。为了提升性能，Slingshot 将 64 字节的最小帧大小减少到 32 字节，允许 IP 数据包在没有以太网头的情况下发送，并取消了包间间隙。最后，Slingshot 通过实现低延迟的前向纠错（FEC）【索引25，25G Ethernet Consortium. Low-Latency FEC Specification】，用于容忍瞬时错误的链路级可靠性（LLR），以及用于容忍硬故障的通道降级【索引26，Lane error detection and lane removal mechanism to reduce the probability of data corruption】等技术，在不同层级上提供了弹性。此外，Slingshot 网卡提供了端到端重传功能以防止数据包丢失。这些是高性能网络中的重要特性。例如，对于 100Gb/s 或更高速度的所有以太网系统，无论系统大小如何，都需要 FEC；而 LLR 在大型系统（如超大规模数据中心）中很有用，可以将错误处理本地化并减少端到端的重传。

II-G 软件栈

通信库与接口。通信库既可以使用标准的 TCP/IP 栈，也可以对于高性能通信库（如 MPI【索引27，Message Passing Interface Forum，MPI: A message-passing interface standard, version 3.0】【索引28，Rajeev Thakur 等人，MPI at Exascale，2010】、Chapel【索引29，Pavan Balaji，Programming Models for Parallel Computing，2015】、PGAS【索引30，George Almasi，PGAS (Partitioned Global Address Space) Languages，2011】和 SHMEM【索引31，Karl Feind，Shared Memory Access (SHMEM) Routines，2012】）使用 libfabric 接口【索引32，Libfabric Library】。Cray 为 libfabric 开源的 verbs provider 和 RxM utility provider 贡献了新功能以支持 Slingshot 硬件。所有 HPC 流量都基于 RDMA over Converged Ethernet (RoCEv2) 分层，数据通过包含最多 4KiB 数据以及头部和尾部的数据包在网络上传输。头部和尾部包括以太网（26字节，含前导码）、IPv4（20字节）、UDP（8字节）、InfiniBand（14字节），以及一个额外的 RoCEv2 CRC（4字节），总共 62 字节。Cray MPI 源自 MPICH【索引33，MPICH - High-Performance Portable MPI】，并实现了 MPI-3.1 标准。Cray MPI 中加入了针对 Slingshot 硬件的专有优化和其他增强功能。任何支持 libfabric 的 MPI 实现都可以在 Slingshot 上即插即用。此外，一些特性（如流量类别）的标准 API 最近也被添加到了 libfabric 中，并且可以被利用。我们在图 5 中报告了不同消息大小和不同网络协议下的延迟。我们观察到，对于小消息，MPI 相对于 libfabric 只增加了微小的开销。

系统带宽性能。此外，我们在图 6 中展示了 SHANDY 系统（一个使用 1024 个节点的基于 Slingshot 的系统，详见第三节）的对剖带宽（即一半节点向另一半节点发送数据，反之亦然）和 MPI_Alltoall 带宽。我们报告了不同每节点进程数（PPN）和不同消息大小下的结果。该系统由八个组构成，所有的对剖切面都跨越相同数量的链路。在这个系统中，每个组有 56 条全局链路（总共 112 条中的一半，每个组向其他每个组有 8 条），以匹配注入带宽。一个分区中的 4 个组都连接到另一个分区中的 4 个组，跨越一个对剖切面的总链路数为 4·4·8 = 128。因为每条链路的带宽为 200Gb/s，并且我们在两个方向上发送流量，所以峰值对剖带宽为 128 · 200Gb/s · 2 = 6.4Tb/s。在 all-to-all 通信中，每个节点将 7/8 的流量发送到其他 7 个组中的节点，1/8 的流量发送到同一组中的节点。因为该系统有 56·8 = 448 条全局链路，所以 all-to-all 的最大带宽为 8/7 · 448 · 200Gb/s = 12.8Tb/s。请注意，MPI_Alltoall 可以达到对剖带宽的两倍，因为一半的连接终止于同一分区【索引34，B. Prisacari 等人，Bandwidth-optimal All-to-all Exchanges in Fat Tree Networks，2013】。该图显示 MPI_Alltoall 达到了理论峰值带宽的 90% 以上，且没有任何数据包丢失。我们观察到 256 字节消息的性能下降，这是因为为了减少内存使用，MPI 实现对于大于 256 字节的消息会切换到另一种算法【索引35，Rajeev Thakur 等人，Optimization of collective communication operations in mpich，2005】。

A4 实验环境

本研究的性能评估在以下三个系统上进行：
- 硬件配置:
- CRYSTAL: 一个基于 Cray ARIES 互连的系统，拥有 698 个节点，CPU 为 Intel Xeon E5-269x。系统由两个组构成。
- MALBEC: 一个拥有 484 个节点的 Slingshot 系统，CPU 为 Intel Xeon Gold 61xx 或 Platinum 81xx。系统由四个组构成，每组间通过 48 条 200Gb/s 的全局链路连接。每个节点配备一张 Mellanox ConnectX-5 EN 网卡。
- SHANDY: 一个拥有 1024 个节点的 Slingshot 系统，计算节点配备 AMD EPYC Rome 64 核 CPU。系统由八个组构成，每组间通过 56 条 200Gb/s 的全局链路连接。每个节点配备两张 Mellanox ConnectX-5 EN 网卡，分别连接到同一网络的不同交换机。
- 软件配置:
- 代码实现: 使用 GPCNet 代码【索引6】生成拥塞模式，使用 Tailbench 基准套件【索引47】中的延迟敏感数据中心应用，以及多个 HPC 应用和微基准测试（如 LAMMPS, MILC, HPCG, ember microbenchmarks）。
- 依赖库: 通信基于 MPI 标准，使用 Cray MPI (派生自 MPICH)。
- 数据集/应用:
- 拥塞测试中的受害者应用 (Victim Applications):
- HPC 应用: MILC, LAMMPS, HPCG, FFTW。
- 数据中心 (DC) 应用 (来自 Tailbench): Imgdnn, Xapian, Sphinx, Silo (均为单客户端-单服务器应用)。
- AI 应用: Resnet-proxy。
- 微基准测试: MPI 操作 (Allreduce, Alltoall), ember 微基准 (halo3d, sweep3d, incast)。
- 拥塞生成器 (Aggressor): 使用 GPCNet 生成两种拥塞模式：
- 端点拥塞: 通过多对一 (incast) 通信模式 (MPI_Put) 生成。
- 中间拥塞: 通过全到全 (all-to-all) 通信模式 (MPI_Sendrecv) 生成。
- 实验中所有 aggressor 均交换 128KiB 的消息。

所有实验均在独占使用的系统上进行，以确保受控的环境并避免其他用户的干扰。

A4 实验结果

拥塞控制

• 实验内容：评估 Slingshot 在不同拥塞场景下的响应能力。实验将被测节点分为“受害者”（victim）和“攻击者”（aggressor）两组。攻击者通过 incast（端点拥塞）或 all-to-all（中间拥塞）通信模式制造网络拥塞。评估了多种受害者/攻击者节点比例（90/10, 50/50, 10/90）、不同的节点分配策略（线性、交错、随机，如图7），以及不同系统规模和每节点进程数（PPN）下的性能影响。
  

  

• 实验结果与分析：
  1. 与 ARIES 的对比：
     • 对于数据中心应用（Tailbench），在 ARIES 上，拥塞导致了严重的性能下降和尾延迟增加（图8）。例如，Silo、Xapian 和 Img-dnn 性能严重恶化。而在 Slingshot 上，几乎没有观察到任何相关影响。
       

       

     • 综合热图（图9）显示，Slingshot 受拥塞的影响远小于 ARIES。在最坏情况下，Slingshot 上的应用 slowdown 为 1.3x，而 ARIES 上高达 93x。端点拥塞（incast）的影响远大于中间拥塞（all-to-all），后者由于自适应路由的存在而影响甚微。
       

       

  2. 不同分配策略、PPN 和规模的影响：
     • 如图 10 所示，交错和随机分配在 ARIES 上会产生比线性分配更严重的拥塞（最高 slowdown 达 150x）。在 Slingshot 上，虽然也观察到类似趋势，但影响程度小得多（slowdown < 2.3x），且分布更集中，表明其拥塞控制在各种场景下都表现稳定。
     • 增加攻击者的 PPN（负载）会加剧 ARIES 上的拥塞，但对 Slingshot 的影响微乎其微。
     • 在较小的系统规模（128节点）上，ARIES 的拥塞影响有所减轻，但 Slingshot 的最大拥塞影响也从 2.3x 降至 1.5x，再次证明其鲁棒性。
       

       

  3. 全系统规模测试：在 SHANDY 系统的全部 1024 个节点上进行的测试（图11）表明，即使在全系统规模下，Slingshot 的拥塞控制依然有效保护应用，最大 slowdown 仅为 3.55x（LAMMPS 应用，75% 节点为攻击者）。
     

     

  4. 突发性拥塞测试：实验（图12）表明，incast 攻击者在使用中等大小的消息时会产生一些拥塞（最高 1.21x slowdown），因为此时拥塞在控制算法完全介入前已经形成。但与其它系统相比，这种影响微不足道。这证明 Slingshot 对持续性拥塞和突发性、短时拥塞都具有很好的耐受性。
     

     

流量类别（Traffic Classes）

• 实验内容：评估 Slingshot 为不同作业提供性能保障的能力。实验在 MALBEC 系统上进行，并将网络带宽限制为可用带宽的 25%，以强制作业间产生干扰。
  1. 一个 8B MPI_Allreduce 作业与一个 256KiB MPI_Alltoall 作业同时运行。
  2. 两个 bisection bandwidth 测试作业先后启动，分别被分配到有不同带宽保证的流量类别中。
• 实验结果与分析：
  1. 如图 13 所示，当 MPI_Allreduce 和 MPI_Alltoall 运行在同一流量类别时，MPI_Allreduce 经历了 2.85x 的 slowdown。而当它们被分配到独立的流量类别时，MPI_Allreduce 的 slowdown 降至仅 1.15x，证明了流量类别能有效隔离性能。
     

     

  2. 如图 14 所示，当两个作业在同一流量类别运行时，它们公平共享可用带宽。当它们被分配到不同流量类别（TC1 保证 80%，TC2 保证 10%）时，Slingshot 严格执行了带宽保证：第一个作业的带宽降至 80%，而第二个作业获得了剩余的 20%（包括其 10% 的保证和 10% 的未分配带宽）。这表明 Slingshot 不仅能强制执行最小带宽保证，还能智能地分配剩余资源。
     

     

A5 结论

本文对 Cray 最新设计的 Slingshot 互连网络进行了描述和评估。研究详细介绍了 Slingshot 的核心特性，包括高基数以太网交换机、自适应路由、拥塞控制和服务质量（QoS）管理。通过在隔离环境和多工作负载并发环境下的性能评估，本研究得出以下结论：
1. 卓越的抗拥塞能力：实验结果表明，与上一代网络相比，运行在 Slingshot 上的应用受网络拥塞的影响显著减小。其拥塞控制算法在广泛的微基准测试、HPC 应用和数据中心应用中均表现出色且稳定。
2. 降低节点分配策略的敏感性：在 Slingshot 上，不同的节点分配策略对应用性能的影响远小于上一代网络，这简化了作业调度和资源管理。
3. 有效的服务质量保证：Slingshot 能够通过流量类别为不同作业提供明确的带宽保证，实现了有效的性能隔离。

本文提供的信息对于 HPC 和数据中心的系统操作员、管理员、用户和程序员在优化、部署和管理并行应用方面具有指导意义。深入理解互连网络的特性是确保计算资源在云和数据中心得到优化运行和利用的前提。

方法细节中的引用汇总

编号	引用内容	引用段落及原文描述
[5]	Daniele De Sensi, Salvatore Di Girolamo, and Torsten Hoefler. Mitigating network noise on dragonfly networks through application-aware routing. SC 19, 2019.	II-E - 描述流量类别的可调参数时引用："...priority, packets ordering required, minimum bandwidth guarantees, maximum bandwidth constraint, lossiness, and routing bias [5]."
[6]	Sudheer Chunduri et al. Gpcnet: Designing a benchmark suite for inducing and measuring contention in hpc networks. SC 19, 2019.	II-D - 区分两种拥塞类型时引用："Two types of congestion might affect an interconnection network: endpoint congestion, and intermediate congestion [6]."
[12]	J. Kim, W. J. Dally, S. Scott, and D. Abts. Technology-driven, highlyscalable dragonfly topology. ISCA 2008.	II-B - 介绍拓扑时引用："Dragonfly [12] is the default topology for SLINGSHOTbased systems..." II-C - 描述 Dragonfly 网络路径时引用："In Dragonfly networks (including SLINGSHOT), any pair of nodes is connected by multiple minimal and non-minimal paths [12], [18]."
[13]	W. H. Tranter et al. Input Versus Output Queueing on a SpaceDivision Packet Switch. 2007.	II-A - 解释避免线头阻塞的设计时引用："To avoid head-of-line blocking (HOL) [13], ROSETTA relies on a virtual output-queued architecture..."
[14]	Y. Tamir and G. L. Frazier. High-performance multiqueue buffers for vlsi communication switches. ISCA 1988.	II-A - 解释虚拟输出排队架构时引用："ROSETTA relies on a virtual output-queued architecture [14], [15] where the routing path is determined before sending the data."
[15]	Thomas E. Anderson et al. High-speed switch scheduling for local-area networks. ACM Trans. Comput. Syst. 1993.	II-A - 同上，与 [14] 一同被引用。
[16]	A Peek Inside Amazon’s Cloud. https://www.networkworld.com/article/3145731/a-peek-inside-amazon-s-cloud-from-global-scale-to-custom-hardware.html. 2016.	II-B - 讨论系统可扩展性时引用："Indeed, this is larger than the number of servers used in data centers [16]..."
[17]	Summit Supercomputer. https://www.olcf.ornl.gov/summit.	II-B - 同上，与 [16] 类似，用于对比系统规模："and much larger than the number of nodes used by Summit [17]..."
[18]	Maciej Besta et al. FatPaths: Routing in Supercomputers, Data Centers, and Clouds with Low-Diameter Networks when Shortest Paths Fall Short. CoRR, 2019.	II-C - 描述 Dragonfly 网络的多路径特性时引用："In Dragonfly networks (including SLINGSHOT), any pair of nodes is connected by multiple minimal and non-minimal paths [12], [18]."
[19]	Sally Floyd. Tcp and explicit congestion notification. SIGCOMM Comput. Commun. Rev. 1994.	II-D - 讨论传统拥塞控制机制时引用："However, existing congestion control mechanisms (like ECN [19] and QCN [20], [21]) are not suited for HPC scenarios." 和 "The approach to congestion control adopted by SLINGSHOT is fundamentally different from more traditional approaches such as ECN-based congestion control [19], [20]..."
[20]	IEEE 802.1Qau – Congestion Notification. https://1.ieee802.org/dcb/802-1qau/.	II-D - 同上，与 [19] 和 [21] 一同被引用。
[21]	Yibo Zhu et al. Congestion control for large-scale rdma deployments. SIGCOMM 2015.	II-D - 同上，与 [19] 和 [20] 一同被引用。
[22]	Yibo Zhu et al. Ecn or delay: Lessons learnt from analysis of dcqcn and timely. CoNEXT 16, 2016.	II-D - 描述传统拥塞控制机制的缺点时引用："but tend to be fragile, hard to tune [22], [23], and generally unsuitable for bursty HPC workloads."
[23]	Y. Gao et al. Dcqcn+: Taming large-scale incast congestion in rdma over ethernet networks. ICNP 2018.	II-D - 同上，与 [22] 一同被引用。
[24]	Differentiated Services Codepoint (DSCP) - RFC 3260. https://tools.ietf.org/html/rfc3260.	II-E - 解释 QoS 的硬件实现时引用："A switch determines the traffic class required for a specific packet by using the Differentiated Services Code Point (DSCP) tag in the packet header [24]."
[25]	25G Ethernet Consortium. Low-Latency FEC Specification. https://25gethernet.org/ll-fec-specification.	II-F - 描述弹性特性时引用："Lastly, SLINGSHOT provides resiliency at different levels by implementing low-latency Forward Error Correction (FEC) [25]..."
[26]	Lane error detection and lane removal mechanism to reduce the probability of data corruption. https://patents.google.com/patent/US9325449B2/en.	II-F - 描述弹性特性时引用："...Link-Level Reliability (LLR) to tolerate transient errors, and lanes degrade [26] to tolerate hard failures."
[27]	Message Passing Interface Forum. Mpi: A message-passing interface standard, version 3.0. 2012.	II-G - 列举高性能通信库时引用："Communication libraries can either use the standard TCP/IP stack or, in case of high-performance communication libraries such as MPI [27], [28]..."
[28]	Rajeev Thakur et al. MPI at Exascale. SciDAC 2010.	II-G - 同上，与 [27] 一同被引用。
[29]	Pavan Balaji. Programming Models for Parallel Computing. 2015.	II-G - 列举高性能通信库时引用：" ...Chapel [29]..."
[30]	George Almasi. PGAS (Partitioned Global Address Space) Languages. 2011.	II-G - 列举高性能通信库时引用：" ...PGAS [30]..."
[31]	Karl Feind. Shared Memory Access (SHMEM) Routines. 2012.	II-G - 列举高性能通信库时引用：" ...and SHMEM [31]..."
[32]	Libfabric Library. https://ofiwg.github.io/libfabric/.	II-G - 介绍 libfabric 接口时引用："...the libfabric interface [32]."
[33]	MPICH - High-Performance Portable MPI. https://www.mpich.org/.	II-G - 描述 Cray MPI 的来源时引用："Cray MPI is derived from MPICH [33]..."
[34]	B. Prisacari et al. Bandwidth-optimal All-to-all Exchanges in Fat Tree Networks. ICS 2013.	II-G - 解释 MPI_Alltoall 带宽为何能超过对剖带宽时引用："Note that MPI_Alltoall can achieve twice the bisection bandwidth because half of the connections terminate in the same partition [34]."
[35]	Rajeev Thakur, Rolf Rabenseifner, and William Gropp. Optimization of collective communication operations in mpich. Int. J. High Perform. Comput. Appl. 2005.	II-G - 解释 256 字节消息性能下降的原因时引用："...the MPI implementation switches to a different algorithm [35] for messages larger than 256 bytes."