推理性能提升30%？RoCE vs InfiniBand实测数据大揭秘！

近期文章

随着现代企业园区网络和运营商级基础设施的不断发展，多协议标签交换（MPLS）已成为一项基础技术，这要归功于其高效的数据包转发、高级流量工程功能以及对多租户环境的强大支持。

什么是MPLS？

MPLS（多协议标签交换，Multiprotocol Label Switching）是一种基于标签的转发技术，结合了二层交换的简捷性与三层路由的灵活性。通过预分配的标签（Label）替代传统IP路由的逐跳查表，提升转发效率。

MPLS起源于IPv4（Internet Protocol version 4），其核心技术可扩展到多种网络协议，包括IPv6（Internet Protocol version 6）、IPX（Internet Packet Exchange）和CLNP（Connectionless Network Protocol）等。MPLS中的“Multiprotocol”指的就是支持多种网络协议。

由此可见，MPLS并不是一种业务或者应用，它实际上是一种隧道技术。这种技术不仅支持多种高层协议与业务，而且在一定程度上可以保证信息传输的安全性。

核心组件：LER（标签边缘路由器）、LSR（标签交换路由器）、FEC（转发等价类）。

工作原理

标签分配：入口路由器（LER）为数据包分配标签，标签对应转发路径（LSP）。
标签交换：中间路由器（LSR）根据标签转发表（LFIB）快速转发，无需解析IP头部。
标签移除：出口路由器（LER）剥离标签，恢复原始IP数据包。

标签结构

MPLS 标签是一个紧凑的 32 位报头，包含四个关键字段：

标签（20 位） — 标识通过 MPLS 网络的路径（LSP）
EXP（3 位）— 用于 QoS（服务质量）标记或流量优先级
S （1 bit） – 堆栈标志的底部;指示这是否是堆栈中的最后一个标签
TTL（8 位）– 生存时间;通过限制数据包的生命周期来防止路由循环

为什么需要MPLS？

在传统IP网络架构中，基于三层路由的转发机制逐渐暴露很多问题。

首先，转发效率低下的问题尤为突出，由于每台路由器都需要逐跳解析IP报文头部并查询路由表，这种反复查表的机制在大流量场景下会产生显著延迟，难以满足数据中心或运营商核心网的高吞吐需求。

其次，传统路由技术对路径控制能力薄弱，完全依赖OSPF、BGP等动态路由协议自动选路，既无法主动规避拥塞链路，也无法为特定业务指定优化路径，导致网络资源利用率低下。

更棘手的是多业务隔离难题，VLAN受限于4096个ID的规模上限，ACL策略管理复杂度随业务增长呈指数级上升，这种基于二层的隔离方案难以支撑跨地域、多租户的现代组网需求。

MPLS技术的核心功能

服务质量（QoS）

MPLS在QoS中的应用主要体现在其对网络流量优先级管理的精细化能力上，而EXP字段（Experimental Bits，后更名为Traffic Class字段）是两者结合的核心纽带。MPLS如何实现QoS保障？在MPLS网络入口（LER），根据业务类型（如语音、视频、普通数据）为流量分配EXP值，可通过手动配置或自动映射（如将IP层的DSCP值转换为EXP值）。LSR根据EXP值分为不同优先级队列，优先转发低延迟流量（SP）和按比例分配剩余带宽（WFQ）。当链路拥塞时，低EXP值的流量可能被丢弃（如TCP流量），而高EXP值的流量（如VoIP）始终保障带宽，此外，再结合RSVP-TE等协议实现关键业务（如语音、实时视频）的带宽保障和低抖动传输，构建起从转发效率到业务体验的全方位优化体系。

流量工程（TE）

TE通过MPLS技术解决了传统IP网络无法实现的精细化流量控制需求，通过显式路径（Explicit Path）手动或策略驱动流量走向，均衡负载或避开瓶颈链路，从而优化网络性能。

业务隔离与VPN

传统VPN一般是通过GRE（Generic Routing Encapsulation）、L2TP（Layer 2 Tunneling Protocol）、PPTP（Point to Point Tunneling Protocol）等隧道协议来实现私有网络间数据在公网上的传送，而MPLS LSP是通过标签交换形成的隧道，数据报文不再经过封装或者加密，因此，用MPLS实现VPN具有天然的优势。

基于MPLS的VPN通过LSP将私有网络的不同分支联结起来，形成一个统一的网络，如图所示。基于MPLS的VPN还支持对不同VPN间的互通控制。这对于企业和运营商网络至关重要。

CE（Customer Edge）是用户边缘设备，可以是路由器，也可以是交换机或主机。
PE（Provider Edge）是IP/MPLS骨干网的边缘设备。
P（Provider）是IP/MPLS骨干网的骨干设备，不与CE直接相连。P设备只需要具备基本MPLS转发能力，不维护VPN信息。

如何基于业务场景与技术特性选择最优网络方案？

对比维度	MPLS	传统IP路由	SD-WAN	Segment Routing
转发效率	高（标签快速交换）	低（逐跳查表）	中（依赖隧道封装）	高（类似MPLS）
路径控制	支持显式路径和流量工程	依赖动态路由协议	动态智能选路	灵活源路由
多业务隔离	通过VPN实现逻辑隔离	VLAN/ACL，扩展性差	有限（依赖Overlay）	需结合其他技术（如VXLAN）
部署成本	高（依赖专用设备和运营商专线）	低	低（利用互联网链路）	中（需升级硬件支持）
适用场景	企业专网、运营商核心网	中小型园区网络	跨地域互联、云访问优化	数据中心、大规模骨干网
服务质量（QoS）	强（基于EXP/DSCP优先级标记）	弱	中（依赖链路质量监测）	中（需策略配合）

AsterNOS：软件定义架构下的MPLS转发技术革新

SONiC（Software for Open Networking in the Cloud）是开源社区的网络操作系统，其核心目标是构建开放、解耦的云数据中心网络架构。作为全球首个完全开源的网络操作系统，SONiC基于Linux内核设计，支持标准化硬件（如白盒交换机）与容器化微服务架构，通过模块化组件（如SAI——交换机抽象接口）实现灵活的功能扩展。其开源特性吸引了全球云服务商、运营商及企业的广泛参与，逐步成为云原生网络的事实标准。

尽管社区版 SONiC 通过模块化设计为云数据中心提供了开放灵活的基础架构，但其在复杂协议支持上的短板始终制约着企业级场景的深度应用。以MPLS为例，社区版本需依赖第三方扩展或定制化开发，导致功能碎片化、性能不稳定，难以满足金融专网、跨云互联等高可靠性需求。

AsterNOS基于 SONiC 的开放式园区交换机的完整产品组合现在完全支持 MPLS，它提高了数据包转发速度，支持精细的流量控制，并支持多协议环境，使其成为电信、企业 WAN 和云数据中心中的大规模网络不可或缺的工具。

这种“开源基因+商业级能力”的融合，使得AsterNOS既能继承开源生态的灵活性，又能以超前技术布局填补开源生态与商业需求间的鸿沟。

【参考文献】

https://www.fnetlink.com/hyzx/32732.html

https://wiki.mbalib.com/wiki/MPLS

https://info.support.huawei.com/info-finder/encyclopedia/zh/SR-MPLS.html

返回资源中心

近期文章

从WiFi 6到WiFi 7：技术升级的核心突破

WiFi7（IEEE 802.11be）作为新一代无线通信标准，在WiFi 6的基础上实现了多维度的技术跃迁，主要体现在以下4个方面：

带宽与速率的指数级提升

WiFi7的最大理论速率达到46Gbps，是WiFi6（9.6Gbps）的5倍。这一飞跃得益于320MHz信道带宽的引入（WiFi6为160MHz），相当于将数据传输的“高速公路”拓宽至双车道。

此外，4096-QAM调制技术的应用使单符号数据承载量从WiFi6的10比特提升至12比特，传输效率提高20%。例如，下载一部50GB电影，WiFi7仅需8秒，而WiFi6需42秒。

多链路操作（MLO）的革命性突破

WiFi7支持跨频段（2.4GHz、5GHz、6GHz）的多链路聚合传输，既可提升速率（如双频叠加实现翻倍带宽），又能增强抗干扰能力。例如，当某一频段受阻时，数据可自动切换至其他频段，显著降低断连风险。相比之下，WiFi6仅支持单频段传输，灵活性受限。

空间流与MIMO技术的扩展

WiFi7的16×16 MIMO（多输入多输出）技术可同时处理16条数据流，是WiFi6（8条）的两倍，大幅提升了高密度场景下的设备容量。这一特性尤其适用于机场、体育场馆等万人级并发场景。结合多链路操作（MLO），可跨2.4GHz/5GHz/6GHz频段同时调度16条空间流，理论容量翻倍。

标准	最大空间流数	典型MIMO配置	关键技术突破
WiFi6 (802.11ax)	8	8×8	OFDMA+MU-MIMO协同调度
WiFi7 (802.11be)	16	16×16	多频段协同MIMO

频谱利用与抗干扰优化

新增的6GHz频段与动态频谱分配技术，缓解了2.4GHz/5GHz频段的拥堵问题。同时，Multi-RU（资源单元聚合）技术允许将多个RU（如小规格RU或大规格RU）组合分配给同一用户，支持非连续频谱聚合，例如将两个80MHz频段合并为160MHz，或在复杂干扰环境中动态调整RU分配，以进一步提升频谱效率。

尽管WiFi 7的技术指标令人振奋，但其在国内的落地进程却面临多重现实挑战，需结合技术优势与市场环境探索破局路径。

国内WiFi7发展的困境

当前实际应用中，6GHz优先用于移动通信，WiFi 7 AP 无法使用该频段（国内仅限5GHz），导致其 320MHz 超宽频带、4096QAM 等技术优势难以完全发挥？

支持 WiFi 7 的手机、电脑等终端设备不足 10%，企业和家庭用户担心部署后因设备兼容性差，无法实现预期的高速体验，造成资源浪费？

破局之道：立足现有优势，挖掘场景化潜力

在当前的无线网络环境中，频段资源受限已成为制约性能提升的重要瓶颈，尤其在新建或扩容场景下，传统WiFi技术难以满足高密度接入和低时延的严苛需求。然而，随着WiFi 7技术的推出，这一问题得到了革命性突破——即便不依赖尚未全面开放的6GHz频段，其性能表现也已远超WiFi 6，为用户提供了更优的解决方案。

多链路操作（MLO），通过同时利用2.4GHz和5GHz双频段传输数据，WiFi 7实现了链路聚合与动态调度，大幅提升网络稳定性和抗干扰能力。这一技术尤其适用于复杂电磁环境，确保用户在多设备并发时仍能获得流畅体验。
增强TWT+节能调度，相比WiFi 6的固定时隙分配（如“定时闹钟”），WiFi 7的智能节能调度可根据设备需求动态调整唤醒时间，显著降低多设备场景下的功耗，同时保持更稳定的时延控制。这种优化对智能家居、物联网设备等高密度部署场景尤为重要。
4096QAM高密度传输，在现有5GHz频段中，WiFi 7通过更高阶的调制技术（4096QAM）实现数据密度提升，单链路速率较WiFi 6增加20%以上。这意味着无需依赖新频段，用户即可享受更快的传输速度和更高效的频谱利用率。
预支持6GHz频段，WiFi 7硬件已提前兼容6GHz频段，一旦政策开放，用户无需更换设备即可直接扩展至更宽裕的频谱资源。这种“一步到位”的设计既降低了未来升级成本，又为超高速、低延迟应用（如8K流媒体、元宇宙交互）提供了技术储备。

功能/型号	CAP7020-Z（双频）	CAP7030-Z（三频）产品链接
接口	1个10/100/1000/2500Mbps 自适应WAN 口	1个10/100/1000/2500Mbps 自适应WAN 口1个10/100/1000/2500Mbps自适应LAN 口1个10Gpbs的SFP+光口
存储	512M RAM + 128M NAND	1024M RAM + 128M NAND
频段	2.4GHz（688Mbps ）和 5GHz （2882Mbps）	2.4GHz（688Mbps ）和 5.1GHz （2882Mbps）和5.8Ghz（2882Mbps）
吞吐	3.6Gbps	6.4Gbps
用户数	128+	192+
SSID数量	8（2.4G）+8（5G）	8（2.4G）+8（5.1G）+8（5.8G）
天线	2 x 2	2 x 2 x 2
天线增益	2.4GHz：2×4dBi5GHz：2×4dBi	2.4GHz：2×1.7dBi5.1GHz：2×4dBi5.8Ghz：2x4dBi
功耗	< 20W	< 36W
供电	PoE 802.3at，DC2.0 12V/2A	PoE 802.3bt，DC2.0 12V/3A

云化园区无线接入点：新一代云化园区网络无线控制器

优先购买支持三频（含6GHz）的WiFi 7路由器，为未来政策开放预留升级空间。
在6GHz未开放地区，利用5.8GHz高频段低干扰特性优化现有网络。

【参考文献】

返回资源中心

近期文章

在人工智能迅速发展的今天，大模型训练已成为推动技术进步的核心动力。然而，随着大模型规模的不断扩大和训练需求的增加，智算网络面临的挑战也日益严峻。网络作为连接计算集群的重要基础设施，其性能直接影响着AI训练的效率和效果。

智算网络的主流架构

目前智算网络的领域的两大主流架构：InfiniBand 和RoCEv2 在性能、成本、通用性等多个关键维度上展现出各自的优势，相互竞争。我们将细致分析这两种架构的技术特性、它们在 AI 智算网络中的应用场景，以及各自的优势和局限性。

InfiniBand

InfiniBand 网络主要通过子网管理器（Subnet Manager，简称 SM）来进行集中管理。SM 通常部署在子网内的某台服务器上，充当网络核心控制器。通过 SM 的集中控制，InfiniBand网络实现了拓扑发现、路径优化、故障恢复等功能的自动化，保障高性能与高可靠性。

InfiniBand网络架构示意图（来源：2023智算中心网络架构白皮书）

RoCEv2

RoCE（RDMA over Converged Ethernet）协议是一种能在以太网上进行 RDMA（Remote Direct Memory Access 远程内存直接访问）的集群网络通信协议。RoCEv1作为链路协议层，要求通信双方位于同一二层网络内。而RoCEv2 则为网络层协议，它采用以太网网络层和 UDP 传输层，取代了 InfiniBand 的网络层，从而提供了更为优秀的可扩展性。与 InfiniBand 网络的集中管理方式不同，RoCEv2 采用的是纯分布式架构，通常由两层构成，在扩展性和部署灵活性方面具有显著优势。

RoCEv2网络架构示意图（来源：2023智算中心网络架构白皮书）

智算网络中的负载均衡与流量控制

AI大模型时代下，数据中心与智算网络，如Spine-Leaf架构，拓扑规整，选路简易。就网络流量模式而言，GPU服务器间常存在多条并行路径，如Fat tree网络中会有数十条。

如何在这些路径中实现负载均衡路由，成为智算中心路由设计的核心挑战。

InfiniBand网络的负载均衡和流控机制

InfiniBand网络通过多层次技术协同，实现了高效的数据传输与资源管理。在负载均衡方面，子网管理器（SM）作为核心调度者，首先基于最短路径算法构建初始路由表，为流量分布奠定基础。尽管SM的动态路径优化能根据链路负载实时调整路径，但其对控制带宽和计算资源的消耗不容忽视。为进一步提升灵活性，自适应路由（AR）技术应运而生，允许交换机基于队列深度、拥塞情况等实时状态独立选择路径，既降低了延迟，又增强了网络可靠性。

然而，AR的动态特性可能导致数据包乱序，这需要上层协议或应用进行额外处理。为弥补单一路径的局限性，应用程序还可通过创建多个队列对（QP），利用硬件队列的并行传输能力分散流量，例如MPI库或Lustre存储中间件通过任务分配避免路径瓶颈，形成应用层与网络层的双重负载均衡。

负载均衡机制的高效运行，离不开底层流控机制的强力支撑。InfiniBand采用信用令牌（credit）系统，在每条链路上预设缓冲区，确保发送端仅在确认接收端资源充足时传输数据，从根本上避免了缓冲区溢出或丢包问题。与此同时，网络还结合逐包自适应路由技术，为每个数据包独立选择传输路径，实时响应拥塞、延迟等状态变化。这种细粒度的动态调整能力，不仅与信用令牌机制形成互补，更在超大规模网络中实现了资源的实时优化配置，使负载均衡从局部扩展到全局。

由此可见，InfiniBand通过负载均衡与流控机制的深度耦合，构建了一个兼具敏捷性、可靠性与扩展性的高性能网络架构。

RoCE网络的负载均衡和流控机制

图片引用自：公众号西北吹风

负载均衡技术

1、基于流（Flow-based）ECMP（Equal Cost Multi Path）是一种路由技术，用于在IP交换网络中实现负载均衡。即等价多路径路由，当存在多条到达同一个目的地址的相同开销的路径，网络设备按照自有的Hash根据流量N元组计算多路径下一跳。由于通用计算以“多流”、“小流”为主，能够实现较好的负载均衡效果。

当AIDC中的大象流连续到达交换机，传统Hash通常会将大象流集中在少数链路上传输，庞大的数据流占用相当大的带宽资源，导致传输链路发生拥塞，而其他链路上则处于空闲。这种Hash不均导致了链路负载不均，进而出现拥塞和时延加剧。

2、基于包（Packet based）随机包喷洒（Random Packet Spraying，RPS）是一种基于包级别的负载均衡策略。当交换机发现有多条等价路径指向同一目的地址时，RPS会将数据包以单个包为单位分散到这些路径上。与ECMP不同，RPS以数据包为单位进行操作，将同一流中的不同数据包转发到不同的等价路径上。

RPS的优点在于简单易实施，通过细粒度的负载均衡，可以在多条并行路径之间实现较为均衡的路由选择，提升端到端的网络吞吐率，可以将并行链路利用率提高到90%以上。缺点在于可能会造成同一个流的包乱序问题，所以这种方式必须要解决乱序问题。

3、基于流片（Flowlet）Flowlet是根据流中的“空闲”时间间隔将一个流划分为若干片段。在一个flowlet内，数据包在时间上紧密连续；而两个flowlet之间，存在较大的时间间隔。这一间隔远大于同一流分片内数据包之间的时间间隔，足以使两个流分片通过不同的网络路径传输而不发生乱序。

4、基于遥测的路由 为了将包、flowlet或整个流调度到不同的路径上，需要路由协议的控制。传统的路由协议，基于静态的网络信息来计算最优路径，如OSPF基于网络带宽计算最短路径，BGP根据AS-PATH长度计算ECMP等。这种控制与网络实际负载脱节，需要加以改进，星融元提出的基于遥测的路由（Int-based Routing）技术结合OSPF、BGP和在网遥测（INT）技术，为网络中任意一对节点之间计算多条路径，每个路径的开销是动态测量的延迟，从而能够根据实时的网络负载进行路由，从而充分利用每个路径的带宽。

流控机制

1、优先流控制（PFC）是一种逐跳流控策略，通过合理配置水位标记来充分利用交换机的缓存，以实现以太网络中的无丢包传输。当下游交换机端口的缓存过载时，该交换机就会向上游设备请求停止传输。已发送的数据则会存储在下游交换机的缓存中，等到缓存恢复正常，端口将会请求恢复数据包的发送，从而维持网络的流畅运行。

【参考白皮书：https://asterfusion.com/priority-based_flow_control_pfc/ 】

2、显式拥塞通知（ECN）定义了一种基于 IP 层和传输层的流量控制和端到端拥塞通知机制。通过在交换机上向服务器端传递特定拥塞信息，然后服务器端再发送至客户端通知源端降速从而实现拥塞控制的目的。

【参考技术手册：https://asterfusion.com/t20250416-ecn/ 】

3、数据中心量化拥塞通知（DCQCN）是显式拥塞通知（ECN）和优先流控制（PFC）两种机制的结合，旨在支持端到端的无损以太网通信。

对比项	InfiniBand	RoCEv2
流控机制	基于Credit的流控机制	PFC/ECN，DCQCN等
转发模式	基于Local ID转发	基于IP转发
负载均衡模式	逐包的自适应路由	ECMP方式路由、基于包（Packet based）、基于流片（Flowlet）、基于遥测的路由
故障恢复	Self-Healing Interconnect Enhancement for Intelligent Datacenters	路由收敛
网络配置	通过UFM实现零配置（按端口收费）	手工配置、或基于开放网络技术实现的 EasyRoCE

技术选型

根据前文我们了解到，InfiniBand和RoCEv2是两种支持RDMA的高性能网络协议，但其负载均衡机制在实现方式、性能和应用场景上存在显著差异：

InfiniBand依赖专用硬件和动态自适应路由，通过子网管理器实时优化路径，实现超低延迟和高吞吐，但成本高且扩展受限，适合HPC/AI等极致性能场景

RoCEv2基于以太网，采用静态ECMP哈希多路径分发，成本低、扩展性强，但依赖无损网络配置（如PFC/ECN），易受哈希不均影响，适合云数据中心等性价比优先场景。虽然RoCE还是很难应对大象流/老鼠流分布不均的影响，但是各厂家也在做各种努力尝试：

WCMP

结合前文，ECMP技术将包、Flowlet或整个流均匀的分布到多个路径上，很大程度上忽略了不同路径上的实际负载。为了进一步提升网络利用率。星融元采用加权代价多路径（Weighted Cost Multiple Path）算法，基于遥测获取的时延等信息，在时延更低的路径上调度更多的流量，在时延更高的路径上调度更少的流量，从而实现所有路径的公平利用。在理想情况下，流量经过不同路径的总时延是相等的，可充分利用所有可用带宽。

星融元CX864E等超级以太网交换机通过支持Flowlet、基于遥测的路由以及WCMP（加权代价多路径）三大创新技术，将AI训练和推理网络的利用率提升至90%以上，从而加速AI训练和推理过程，为AI数据中心进一步节省建设成本和运营成本。

【参考文档】

返回资源中心

近期文章

园区交换机运行起了 SONiC，是在卷生卷死的大环境下“杀鸡用牛刀”，还是引入了一场对园区传统建设运营范式的“降维打击”？与其猜测，不如亲自体验一番这款面向园区场景的 SONiC NOS —— AsterNOS Campus，一切自有答案。

当前，vAsterNOS Campus v6.0（GNS3/EVE-NG设备模拟器）已支持下载，全功能版本的试用/演示名额现正开放申请中。

下载和申请演示：https://asterfusion.com/d-vasternos/
技术交流支持：加入官方QQ群（群号：801700146），获取用户手册、配置案例及技术答疑服务。

AsterNOS 是星融元 Asterfusion 面向AI智算、通算云和企业园区等场景的一站式 SONiC 交钥匙解决方案的核心技术。其中 AsterNOS Campus v6.0是专为企业、校园及各类园区网络打造的企业级SONiC解决方案，具备丰富的L2/L3功能，如ACL、MSTP、QinQ、IGMP Snooping，OSPF/BGP等。

此外，AsterNOS Campus v6.0 还具备增强的MPLS L2VPN / L3VPN，PTP等高级功能，帮助企业和园区构建高效的多业务承载网络，实现跨域互联，并提供纳秒级别的时间同步，适用于对时间精度要求极高的业务场景。

星融元园区交换机及vAsterNOS虚拟化平台的开放生态中，PTP作为关键功能之一，为园区网络、工业自动化及AI算力场景提供了精准的时间同步能力，成为构建高可靠、低时延基础设施的核心支撑。

什么是PTP？

PTP（精确时间协议，Precision Time Protocol）是一种基于IEEE 1588标准的网络时间同步协议，旨在为分布式系统中的设备提供亚微秒级（甚至纳秒级）的高精度时钟同步。其核心目标是通过消除网络传输延迟的不确定性，确保跨设备的动作、数据采集或控制指令在严格统一的时间基准下执行。

什么领域需要PTP？

在园区网络中，随着物联网、工业自动化、金融交易和高清视频协作等应用的普及，设备间对高精度时间同步的需求日益增强。

传统网络时间协议（NTP）仅能提供毫秒级同步精度，难以满足微秒甚至纳秒级场景（如传感器协同、5G基站调度、分布式系统事务一致性）的严苛要求。

IEEE 1588定义的精确时间协议（PTP）通过硬件时间戳消除网络传输延迟误差，结合主从时钟架构动态补偿链路不对称性，可为园区内的摄像头、工业控制器、服务器集群等设备提供亚微秒级同步，保障实时业务时序精准性、故障诊断准确性及系统协同效率，成为智能园区低时延、高可靠组网的核心基础。

PTP的核心优势（对比NTP）

维度	PTP	NTP
同步精度	微秒/纳秒级（硬件支持）	毫秒级（软件实现）
延迟抖动	通过硬件时间戳和TC/BC消除抖动	受操作系统和网络波动影响
适用场景	工业控制、5G、金融高频交易等	办公、IT系统、通用服务
部署成本	高（需专用硬件）	低（纯软件）

PTP实现时间同步的核心机制

实现时间同步的两种核心机制：一步模式（单步模式）与两步模式（双步模式），主要区别在于时间戳的嵌入方式、网络开销及硬件依赖。以下是两者的对比解析：

两步模式（Two-Step）

兼容性高：适用于不支持硬件时间戳的设备，依赖软件处理。
网络开销大：需额外传输Follow_Up报文，增加带宽占用。
抗干扰性弱：在高负载网络中，Sync与Follow_Up报文可能因拥塞失序，导致同步误差。

PTP

主时钟先发送 Sync报文，记录其发送时刻 t1 ，随后通过 Follow_Up报文将 t1 传递给从时钟。从时钟接收Sync报文时记录接收时刻 t2 ，再发送 Delay_Req报文记录发送时刻 t3 ，主时钟响应 Delay_Resp报文返回接收时刻 t4。

在这些交换结束后，从属时钟拥有所有四个时间戳。因此，它可以计算出它的时钟相对于主时钟的偏移量为：偏移 = (t2 + t3 – t1 – t4) /2

一步模式（One-Step）

高精度：硬件级时间戳消除协议栈处理延迟，同步精度可达纳秒级。
低网络开销：减少50%的PTP报文数量，降低网络负载。
硬件依赖性强：需PHY/MAC芯片支持硬件时间戳嵌入功能，成本较高。

PTP

单步模式将时间戳直接嵌入Sync报文，无需Follow_Up报文：主时钟在发送Sync报文时，硬件芯片实时标记 t1 并写入报文字段。从时钟接收Sync报文后，直接提取 t1 与本地记录的 t2 计算偏移和延迟。

特性	一步模式	两步模式
同步精度	纳秒级（硬件时间戳）	微秒级（软件时间戳）
报文数量	少（无Follow_Up）	多（需Follow_Up）
硬件要求	需专用PHY/MAC芯片	通用网络设备兼容
适用场景	工业实时控制、高频交易	普通办公网络、传统音视频传输

星融元园区交换机多款产品支持PTP功能，同步精度可达20ns？！

作为新一代开放网络解决方案提供商，其多款园区级交换机深度集成 IEEE 1588 PTP（精确时间协议）功能，结合硬件加速、高精度时钟设计及基于SONIC自研AsterNOS网络操作系统，可为工业控制、金融交易、5G基站等场景提供纳秒级时间同步能力，最高精度可达 20ns，助力企业构建高可靠、低时延的智能网络底座。

园区产品

通过硬件与软件协同设计，星融元突破传统同步瓶颈：

基于SONiC生态的PTP协议：基于SONiC的企业级发行版AsterNOS，结合开源linuxPTP项目（遵循IEEE 1588标准的PTP协议实现），通过自主研发的PTP功能与SONiC深度集成，拥有高精度、高可靠的时间同步能力。
通过标准化接口实现灵活配置：AsterNOS提供丰富的RESTful API，用户可通过编程接口直接配置PTP参数（如主从时钟选择、同步间隔调整等），实现自动化运维。
面向超低时延场景的优化：硬件平台（如CX854E-N）采用的Marvell TL10支持PTP的芯片，结合AsterNOS的软件优化，可实现纳秒级时间同步精度。通过内存数据库Redis实现模块间状态同步，可能用于实时记录和分发PTP时间戳数据，提升同步效率和系统可靠性。
定制化开发与生态兼容性：支持多厂商芯片（如Marvell Teralynx（部分）、Prestera等），确保PTP在不同硬件平台上的兼容性，满足异构网络部署需求。

如需完整方案（含园区控制器）演示，欢迎拨打官方热线 400-098-9811 转产品咨询。

返回资源中心

近期文章

RDMA 网络技术是什么？

RDMA（远程直接内存访问）是一种网络通信技术，允许计算机直接访问远端主机内存，绕过操作系统内核和CPU干预，实现超低延迟、高吞吐量的数据传输。其核心机制包括零拷贝（消除数据缓冲复制）、内核旁路（减少软件栈开销）及网络协议卸载（由网卡硬件处理通信协议）。该技术最初用于高性能计算（HPC）和存储网络，后扩展至云计算、AI训练等场景。

主流协议

图1 RDMA网络技术原理

（RDMA）技术允许设备直接读/写应用程序的内存，而无需与 CPU 或作系统交互，从而实现更高的吞吐量和更低的延迟。应用程序可以直接对网络设备进行编程，以对应用程序内存执行 DMA。

RDMA

图中，PoD1网络设备直接通过HCA（是RDMA专用的硬件组件）访问PoD2网络设备，绕过内核协议栈，实现零拷贝和低延迟。以下是RDMA三种主流协议：

InfiniBand（IB）：

原生支持RDMA，需专用InfiniBand网络设备和交换机。
提供物理层到传输层的完整协议栈。

RoCE（RDMA over Converged Ethernet）：

在以太网上运行RDMA，分为RoCEv1（基于以太网链路层（不支持3层转发）和RoCEv2（基于UDP/IP）。
依赖无损网络（通过PFC和ECN实现流量控制）。

iWARP（Internet Wide-Area RDMA Protocol）：

基于TCP/IP协议栈，支持广域网环境。
通过TOE（TCP Offload Engine）将TCP处理卸载到网卡。

三种网络传输协议的优势和劣势对比表：

协议	优势	劣势
InfiniBand	1.超低延迟：原生支持RDMA，延迟极低。 2. 高吞吐量：支持超高速传输（如EDR/HDR速率）。 3. 无损网络：基于Credit机制，无需额外流控。 4. 高扩展性：专为高性能计算（HPC）优化。	1.成本高：需专用硬件（网卡、交换机）。 2. 兼容性差：与现有以太网设施不互通。 3. 部署复杂：需独立网络架构。
RoCE	1.基于以太网：兼容现有以太网基础设施，降低成本。 2. 支持RDMA：在以太网上实现低延迟传输。 3. 灵活路由：RoCEv2支持IP层路由。	1.依赖无损网络：需PFC、ECN等流控，配置复杂。 2. 拥塞敏感：网络拥塞时性能下降明显。 3. 硬件要求：需支持RoCE的专用网卡。
iWARP	1.基于TCP/IP：兼容传统TCP网络，无需改造基础设施。 2. 抗拥塞：利用TCP可靠性机制，适应复杂网络环境。 3. 部署灵活：支持标准以太网交换机。	1.性能较低：TCP协议栈引入额外延迟和开销。 2. 吞吐量限制：相比InfiniBand和RoCE，带宽利用率较低。 3. 生态支持弱：硬件和软件支持较少。

RoCE基于以太网实现远程直接内存访问（RDMA），旨在通过绕行内核协议栈提升数据传输效率，成为高性能计算、分布式存储和AI训练场景的热门选择。然而，其核心设计依赖无损网络和特定硬件支持，导致实际部署面临显著挑战：

配置复杂性：需手动协调PFC（流量控制）、ECN（拥塞通知）和QoS策略，跨厂商设备兼容性差，运维门槛高；
网络僵化风险：PFC的逐跳反压机制可能引发广播风暴或死锁，大规模组网时稳定性存疑；
扩展性限制：RoCEv1局限于二层网络，RoCEv2虽支持三层但受限于UDP/IP的封装开销和路由延迟，跨数据中心场景性能易波动。

这些劣势促使业界探索自动化配置工具（如星融元“一键RoCE”）和软硬件协同优化方案，以平衡性能与部署成本。

星融元RoCE无损以太网

星融元通过其创新的一键RoCE功能和智能拥塞管理方案，显著简化了RoCEv2网络的配置流程并有效解决了网络拥塞导致的性能下降问题。以下是具体实现方式和优化策略：

如何通过一键RoCE简化配置流程？

1. 一键式命令封装：传统RoCEv2网络需手动配置PFC（基于优先级的流量控制）和ECN（显式拥塞通知）等复杂参数，涉及多步骤QoS策略调整。星融元的AsterNOS操作系统通过业务级命令行封装，将原子级配置整合为单条命令（如show roce），实现一键启用或关闭无损网络功能，极大降低工程师的操作复杂度。

2. 集中化配置与状态展示

全局视图管理：通过show roce命令，可集中查看全网的RoCE配置状态、队列映射、Buffer使用情况、PFC/ECN触发次数等，无需逐台设备执行多个命令。
业务级参数调优：针对不同业务场景（如HPC或存储），提供默认模板配置，同时也支持通过QoS命令行精细调整PFC和ECN参数，满足定制化需求。

3. 兼容性与易用性增强

思科风格命令行（KLISH）：AsterNOS支持传统CLI操作习惯，降低学习成本。
自动化部署工具：结合RESTful API和零接触部署（ZTP），实现网络快速上线，减少人工干预。

如何解决网络拥塞时的性能下降？

PFC工作流程

1. PFC+ECN的无损保障机制

PFC（优先级流量控制）：为存储等高优先级流量划分独立队列，当检测到队列拥塞时，触发暂停帧（Pause Frame）避免丢包。
ECN（显式拥塞通知）：在IP头部标记拥塞状态，通过CNP（拥塞通知包）反馈至发送端，动态调整流量注入速率，防止拥塞扩散。

2. 硬件与架构优化

超低时延交换机（CX-N系列）：Port-to-Port转发时延低至400ns，支持高密100G/400G端口，减少存储集群内部通信跳数（不超过3跳），降低端到端时延。
Spine-Leaf架构设计：通过扁平化组网优化流量路径，避免传统多层架构的瓶颈。

3. 可视化监控与快速排障

Prometheus集成：通过容器化监控工具roce_exporter，实时采集RoCE网络指标（如拥塞次数、CNP触发频率），实现可视化分析。
故障集中定位：使用show roce命令聚合关键调试信息，快速定位拥塞源或配置错误，缩短排障时间。

应用场景与效果

分布式存储网络：在存算分离场景中，通过RoCEv2+PFC+ECN构建零丢包、低时延的后端存储网络，加速多副本同步与数据重建。
高性能计算（HPC）：支持大规模并行计算任务，通过无损网络减少通信延迟，提升算力集群效率。
云数据中心：在混合业务负载下（存储、计算、AI），通过优先级隔离和动态拥塞控制，保障关键业务SLA。

性能测试：https://asterfusion.com/blog20241011-roce-test-report/

【参考文献】

返回资源中心

最新动态

SONiC交换机 PK IB交换机，是“越级碰瓷”还是“有点东西”？

关注星融元

聊起AI、HPC或其他无损传输网络场景，RoCE or IB 无疑是个老生常谈的话题了。关于两种协议栈的区别和联系，我们之前有写过一篇详尽的文章（请参阅：RoCE与IB协议栈对比解析）。简言之：RoCE 实际上只是将成熟的IB传输层和RDMA移植到了同样成熟的以太网和IP网络上。

IB因其是最早支持RDMA的协议，起步早，技术成熟，在一整套专用软硬件体系加持下，可提供极致的低时延传输性能，但同时也因供应商唯一，导致整体TCO较高。

与之相对的，RoCEv2在互操作性和成本上的显著优势被认为更适合大规模部署，例如今年xAI公司在美国孟菲斯建设的十万卡AI集群，便是使用400GbE以太网构建的无损高速网络。

开放网络能否平替IB？

援引Amazon高级首席工程师Brian Barret的话，AWS之所以放弃IB方案主要是因为：

“要满足资源调度和共享等一系列弹性部署的需求，专用的IB网络集群如同汪洋大海中的孤岛”

既然追求标准开放与多厂商兼容已是业界共识，以SONiC为代表的开放网络在顶级大厂云的商业化部署也有目共睹了，我们不禁要问：到了性能要求更苛刻的AI/HPC场景，支持RoCE的开放网络能否担得起 “IB平替” 的期待？

或者再进一步，开放架构的力量能否赋能更广大的数据中心建设运营者？ 比如简化受人诟病的RoCE网络部署调优，提高运维诊断能力等等…或者更多可能？

铺垫有点多了，上干货！

测试背景

我们挑选了三大典型场景下的SONiC交换机（RoCE）和IB的现场实测对比结果，涉及AI训练，HPC和分布式存储环境。测试结果保真保鲜，同时也会简要附上方法步骤，希望能对各位读者有所参考价值。

AI智算场景：E2E转发测试、NCCL-TEST、大模型训练网络测试
HPC场景：E2E转发性能、MPI、Linpack、HPC应用（WRF、LAMMPS、VASP）
分布式存储：FIO工具压测读写性能

当然，正经搞对比测试不能不讲武德，跟IB正面对垒的选手绝不能是随便淘个白盒跑跑社区版软件的野生玩家。被测RoCE交换机为星融元CX-N系列，产品采用超低时延硬件平台，搭载企业级SONiC发行版AsterNOS，全端口标配支持RoCEv2，以及EasyRoCE Toolkit。

EasyRoCE 是星融元依托开源、开放的网络架构与技术提供的一系列实用特性和小工具。从前期规划实施到日常运维监控，EasyRoCE 简化了各环节的复杂度并改善了操作体验，更提供二次开发和集成空间，供网络架构师充分利用开放网络最新技术成果。

Toolkit 更新传送门：官网详情页 | 统一监控面板（UG） | 高精度流量监控（RTR）| 一键RoCE部署（ORD）

CX-N系列型号规格如下表所示：

星融元产品

测试结论

先说结论，开放架构的星融元CX-N系列交换机（RoCE）与IB交换机的端到端性能基本持平，局部超越。

AI智算场景

1、E2E转发带宽达到网卡直连速率上限，单机转发时延低至560ns

2、双机16卡运行NCCL-test （ring算法），通过两台被测交换机测得最大总线带宽与IB交换机基本一致（约195GBps），且带宽使用率与网卡直连情况一致，已达到服务器Scale-out网络传输速率上限。

3、轨道优化拓扑下，双机16卡 Llama2-7B（样本序列长度2048）的单次训练用时与网卡直连以及IB组网的测试结果一致。

HPC 场景

1、E2E时延表现与IB交换机基本持平，差异保持在纳秒级。

2、MPI基准测试，E2E表现与IB交换机基本持平，时延差异保持在纳秒级。

3、Linpack效率与使用同规格IB交换机组网结果基本相当，差异约在0.2%。

4、HPC集群内并行运行WRF、LAMMPS和VASP应用，RoCE交换机完成一次相同计算任务的平均用时与使用IB交换机组网的用时基本相当，两者差异在0.5%~3%之内。

LAMMPS WRF

VASP

分布式存储场景

采用RoCE组网的分布式存储系统读写性能（IOPS）与采用同规格IB组网持平，部分条件下优于IB。

IOPS

HPC集群网络测试和IB/RoCE交换机性能对比

HPC集群架构和通信流量特征

HPC 集群由多个联网的高速算力服务器组成，广泛使用CPU-CPU的多节点并行计算，并结合GPU、FPGA加速器的异构计算进一步提升性能。节点之间通过高速网络互联完成实时通信，并有一个集中式的管理节点来管理并行计算工作负载。HPC领域专注于解决复杂的科学问题、完成各类场景模拟等任务，与之相关的仿真和模拟技术对计算精度要求极高，通常采用双精度浮点运算（FP64）。

从方法论的角度来看，AI和HPC都是借助并行计算提高运算效率，并通过可扩展设计（Scale-up或Scale-out方向）来适应不断增加的工作负载。但对比AI集群中的大规模集合通信，HPC流量模型多为点对点的局部通信或邻居通信，传递64B-128MB的小消息，主要是对时延极其敏感——例如电磁仿真、流体动力学和汽车碰撞等计算场景高度依赖各节点间的工作协调、计算同步以及信息高速传输。

当然也有相对数据密集型的场景，如气象预报、基因测序、图形渲染和能源勘探等，计算节点在处理大量数据的同时又产生了大量中间数据，虽然也需要较高的网络吞吐量，但与AI训练不在一个量级。（🔗一文揭秘AI智算中心网络流量 – 大模型训练篇）

下表简单总结了HPC集群与AI智算集群的的联系与区别：

	HPC	AI 训练
相似点	采用并行计算和可扩展的集群设计提高效率，要求大存储和大内存资源处理数据集，计算和存储节点使用高速网络（IB/RoCE）实现互联，资源分配和作业管理系统都依赖复杂的软件栈实现
算力硬件	主要是CPU、可能包括GPU或FPGA，但使用频率低于AI训练	GPU，以及专为AI优化的TPU
运算精度	FP64高精度计算	FP32、FP16，概率性的近似计算
流量模型	点对点的局部通信或邻居通信，多传递64B-16MB的小消息	大多是大规模集合通信，传递128MB以上大消息
数据管理	结构化的、模拟数据	非结构化数据
软件栈	MPI、OpenMP、科学计算数值库	TensorFlow、PyTorch
工作负载	紧密耦合的、同步的	迭代的、异步的

无论是在AI智算还是HPC，或是二者的融合，业界已普遍采用RDMA技术的内核旁路机制大幅降低了服务器侧的I/O时延。而为了切实提高集群生产效率，应用RDMA需同时建立端到端的超低时延无损网络，目前两大主流路线是Infiniband与RoCEv2。前者为专有协议，需要专用硬件搭建专网，后者则在IB基础上改进了报文格式，使其支持在以太网上传输，关于两种协议栈的详细对比可参考（RoCE与IB对比分析（一）：协议栈层级篇）

选择IB还是RoCEv2已是老生常谈的话题了，IB因其属于是RDMA原生的协议，由Mellanox/NVIDIA独家供应的IB交换机可提供极致性能，但RoCEv2在互操作性和带宽成本上优势明显，且随着开放网络技术的快速迭代，基于SONiC的高性能以太网交换机的端到端通信效率也可做到IB相当，甚至局部超越。

HPC网络性能测试方案设计

围绕HPC业务的实际要求和当前市场关注的IB替代问题，我们构建了面向典型HPC场景的网络测试，在同一测试环境下，部署同等规格速率的Mellanox IB和星融元的RoCE交换机（32 x 100G）互为对照。测试项目包括转发测试、MPI基准测试、Linpack基准测试和HPC应用测试。

完成基础环境部署后（步骤见附录），我们在服务器Centos7.8系统下切换Mellanox InfiniBand卡的工作模式，确保两台服务器上的网卡工作模式正确对应被测交换机（IB或RoCE）

端到端转发时延测试

测试两款交换机在相同拓扑E2E（End to End）场景下的转发时延和带宽。采用Mellanox IB发包工具进行发包，测试遍历2~8388608字节。星融元交换机的E2E表现与IB交换机基本持平，带宽利用率与IB同为96%左右，两者时延差异保持在纳秒级。

MPI基准测试

MPI是一种消息传递接口，用于实现在多个计算节点之间进行并行计算和数据通信。MPI的核心思想是通过发送和接收消息进行节点间的数据交换，实现分布式计算的目标。

MPI提供了一系列的并行计算函数，如任务分发、结果收集和同步操作等，以及消息传递函数，如发送消息、接收消息和广播以实现高效的数据通信。通过合理地设计数据通信模式，可以避免数据冗余和通信瓶颈，提高计算效率。此外，MPI还提供进程管理函数来控制进程的创建、销毁、通信等。

MPI基准测试使用OSU Micro-Benchmark工具MPI run方式测试网卡直连和通过两台交换机的端到端时延。星融元RoCE交换机与IB交换机的端到端性能基本一致，时延差异保持在纳秒级。

LinPack基准测试

Linpack现在在国际上已经成为最流行的用于测试高性能计算机系统浮点性能的Benchmark，通过高斯消元法求解N元一次稠密线性代数方程组，评价HPC的浮点运算性能。算力使用效率=实际峰值/理论峰值*100%，其中理论峰值来自于服务器的规格参数，即主频率*核心数*每周期浮点运算次数。在测试环境下，星融元RoCE交换机与IB交换机的LinPack效率基本一致。

HPC 应用测试

WRF（天气研究和预报模型）、LAMMPS（大尺度原子/分子并行模拟工具）和VASP（维也纳全始计算模拟包）分别是气象预报、分子动力学、量子化学领域的专用工具。测试结果为被测设备和对照组完成一次相同计算任务所需时间，最终结果取连续进行三次测试的平均用时。

星融元RoCE交换机组网条件下完成一次相同计算任务的平均用时与使用IB交换机组网的用时基本相当，两者差异在0.5%~3%之内。

附录：基础环境配置

网卡MLNX_OFED驱动程序安装

[root@Server ~]# wget \
https://content.mellanox.com/ofed/MLNX_OFED-5.0-1.0.0.0/MLNX_OFED_LINUX-5.0-1.0.0.0-rhel7.8-x86_64.tgz
[root@Server ~]# tar -zxvf \
MLNX_OFED_LINUX-5.0-1.0.0.0-rhel7.8-x86_64.tgz
[root@Server ~]# cd MLNX_OFED_LINUX-5.0-1.0.0.0-rhel7.8-x86_64
[root@Server ~]# ./mlnx_add_kernel_support.sh -m \
/root/MLNX_OFED_LINUX-5.0-1.0.0.0-rhel7.8-x86_64 -v
[root@Server ~]# tar xzvf \
MLNX_OFED_LINUX-5.0-1.0.0.0-rhel7.8-x86_64-ext.tgz
[root@Server ~]# cd MLNX_OFED_LINUX-5.0-1.0.0.0-rhel7.8-x86_64-ext
[root@Server ~]# ./mlnxofedinstall

检查网卡及网卡驱动状态

[root@Server ~]# /etc/init.d/openibd start
[root@Server ~]# ibstatus
[root@Server ~]# systemctl start mst
[root@Server ~]# mst status

HPC基础环境



[root@Server ~]# cat /etc/hosts

[root@Server ~]# systemctl stop firewalld && systemctl disable firewalld
[root@Server ~]# iptables -F
[root@Server ~]# setenforce 0 
[root@Server ~]# ssh-keygen
[root@Server1 ~]# ssh-copy-id -i id_rsa.pub root@192.168.4.145
[root@Server2 ~]# ssh-copy-id -i id_rsa.pub root@192.168.4.144
[root@Server1 ~]# yum -y install rpcbind nfs-utils
[root@Server1 ~]# mkdir -p /data/share/
[root@Server1 ~]# chmod 755 -R /data/share/
[root@Server1 ~]# cat /etc/exports
/data/share/ *(rw,no_root_squash,no_all_squash,sync) 
[root@Server1 ~]# systemctl start rpcbind
[root@Server1 ~]# systemctl start nfs 
[root@Server2 ~]# yum -y install rpcbind
[root@Server2 ~]# showmount -e Server1
[root@Server2 ~]# mkdir /data/share  
[root@Server2 ~]# mount -t nfs Server1:/data/share /data/share

MPI Benchamarks工具安装

[root@Server ~]# yum -y install openmpi3 openmpi3-devel -y
[root@Server ~]# wget \
http://mvapich.cse.ohio-state.edu/download/mvapich/osu-micro-benchmarks-5.6.3.tar.gz
[root@Server ~]# tar zxvf osu-micro-benchmarks-5.6.3.tar.gz
[root@Server ~]# cd osu-micro-benchmarks-5.6.3
[root@Server ~]# ./configure
[root@Server ~]# make -j
[root@Server ~]# make install
[root@Server ~]# mkdir /osu
[root@Server ~]# cp -rf \
/usr/mpi/gcc/openmpi-4.0.3rc4/tests/osu-micro-benchmarks-5.3.2/* /osu

HPC 应用测试的基础环境需要在Server服务器上完成编译器的安装以及基础环境变量的配置，在Server服务器上安装第三方库以及完成zlib、libpng、mpich、jasper和netcdf软件的编译，并对依赖库进行测试。具体参考各类工具官方文档。

交换机和服务器上的配置参考

# 星融元CX-N交换机A
admin@sonic:~$sudo config vlan add 100
admin@sonic:~$sudo config vlan add 100
admin@sonic:~$sudo config vlan member add 100 Ethernet8
admin@sonic:~$sudo config interface ip add Vlan100 1.1.3.1/24
admin@sonic:~$sudo config interface ip add Ethernet0 1.1.1.1/24
admin@sonic:~$sudo config route add prefix 1.1.2.0/24 nexthop  1.1.1.2

# 星融元CX-N交换机B
admin@sonic:~$sudo config vlan add 100
admin@sonic:~$sudo config vlan member add 100 Ethernet8
admin@sonic:~$sudo config interface ip add Vlan100 1.1.2.1/24
admin@sonic:~$sudo config interface ip add Ethernet0 1.1.1.2/24
admin@sonic:~$sudo config route add prefix 1.1.3.0/24 nexthop  1.1.1.1

# Server1
[root@Server1 ~]# modprobe 8021q
[root@Server1 ~]# vconfig add ens1f0 100
[root@Server1 ~]# ifconfig ens1f0.100 1.1.3.2/24 up
[root@Server1 ~]# ifconfig ens1f1 1.1.9.9/24 up
[root@Server1 ~]# route add -net 1.1.0.0 netmask 255.255.0.0 \
gw 1.1.3.1

# Server2
[root@Server1 ~]# modprobe 8021q
[root@Server1 ~]# vconfig add ens1f0 100
[root@Server1 ~]# ifconfig ens1f0.100 1.1.3.2/24 up
[root@Server1 ~]# ifconfig ens1f1 1.1.9.9/24 up
[root@Server1 ~]# route add -net 1.1.0.0 netmask 255.255.0.0 \
gw 1.1.3.1

揭秘超以太网联盟（UEC）1.0 规范最新进展（2024Q4）

关注星融元

近期，由博通、思科、Arista、微软、Meta等国际顶级半导体、设备和云厂商牵头成立的超以太网联盟（UEC）在OCP Global Summit上对外公布其最新进展——UEC规范1.0的预览版本。让我们一睹为快吧！

UEC 1

UEC 旨在提出一种“升级版”的以太网通信协议栈用以应对AI智算、HPC等领域对RDMA网络的性能挑战——当前大规模计算节点互联场景下主要有InfiniBand和基于以太网协议的RoCE两大技术路线。有关IB和RoCE协议栈的详尽对比可参阅：

高性能网络传输：RoCE与IB协议栈对比解析

相比较为封闭的IB架构，以太网在互操作性和带宽成本上的优势已在市场层面得到了广泛认可，尤其是大规模的AI算力中心场景。当前全球TOP500的超级计算机中RoCE和IB的占比相当，以端口带宽总量计算，IB占比为39.2%，RoCE已达48.5%。

尽管IB和RoCE在高性能传输的拥塞控制、QoS皆有应对设计，但也暴露出一些缺陷。例如乱序需要重传、不够完美的负载分担、Go-back-N问题，DCQCN 部署调优复杂等等。

面向GPU Scale-out网络的UEC 1.0 规范从软件API、运输层到链路层以及网络安全和拥塞控制皆有涉及，较传统RDMA网络有了大量改进，我们将挑出重点介绍。 UEC2

什么是超级以太网系统

一个超级以太网系统的组成如下。一个集群（Cluster）由节点（Node）和网络（Fabric）组成，节点通过网卡（Fabric Interface）连接到网卡，一个网卡中可以有多个逻辑的网络端点（Fabric End Point，FEP）。网络由若干平面（Plane）组成，每个平面是多个FEP的集合，通常通过交换机互联。

UEC 3

超以太网协议栈概览

UEC4

▣ 物理层与传统以太网完全兼容，可选支持FEC（前向纠错）统计功能

▣ 链路层可选支持链路层重传（LLR），并支持包头压缩，为此扩展了LLDP的协商能力

▣ 网络层依然是IP协议，没有变化

▣ 传输层是全新的，作为UEC协议栈的核心数据包传输子层（Packet Delivery）和消息语义子层（Message Semantics）。包传输子层实现新一代拥塞控制、灵活的包顺序等功能，消息语义子层支持xCCL和MPI等消息。可选支持安全传输。另外，在网集合通信（In Network Collective，INC）也在这一层实现

▣ 软件API层。提供UEC扩展的Libfabrics 2.0

物理层

UEC 1.0规范下的物理层与传统以太网（符合IEEE802.3标准）完全兼容，支持每通道100Gbps和200Gbps速率，在此基础上实现800Gbps和更高的端口速率。

另外可选支持物理层性能指标统计功能（PHY metrics）。这些指标基于 FEC 码字进行计算，不受流量模式和链路利用率的影响。估计算法基于FEC错误计数器的数据，从而得出不可纠正错误率（UCR ）和数据包错误平均间隔（MTBPE）。这些指标衡量了物理层的传输性能和可靠性，用于上层的遥测和拥塞控制等。为了支持新的 UEC 链路层功能，UEC规范中也对协调子层（RS）进行了相应的修改。

链路层

UEC链路层最大的变化是引入了LLR（Link Level Retry）协议。它可以让以太网不依赖PFC，实现无损传输。

LLR 机制是基于帧的。每个帧都分配了一个序列号，接收端成功接收这一帧后，检查帧的序列号是否符合预期，如果正确，发送确认消息（ACK），如果发现帧乱序或者丢失，则发送否定确认消息（NACK）。发送端具有超时机制，用于保证在 NACK 丢失时重传。

传输层：UET，新一代协议栈的核心

前文提过，传统的RDMA网络传输层（包括IB和RoCE）在多路径传输、负载分担、拥塞控制以及参数调优等方面存在着不足之处。随着AI/HPC集群规模增长，网络的确定性和可预测性越来越困难，需要全新的方法来解决。

UEC传输层（UEC Transport Layer，简称UET）运行在IP和UDP协议之上, 支持实现以下几大技术目标：

▣ 支持高达 100 万个 GPU/TPU 的算力集群

▣ 往返时间低于 10μs

▣ 单接口带宽800Gbps及以上

▣ 网络利用率超过85%

选择性重传（Selective Retransmit）

传统传输协议，如TCP需要严格的传输顺序，并采用了Go-Back-N机制。而一个RDMA消息通常包含多个数据包，只要有一个数据包错误，则从这个数据包起的所有数据包都要重传。这让偶尔的传输错误被放大，加剧了网络拥塞。UEC采用选择性重传机制，仅传输错误的数据包。

乱序交付（Out-of-Order Delivery）

UET不仅支持有序传输，也支持无序传输。这是因为现代网络中通常有多路径存在，同一个流的数据包经过不同路径传输，就可能造成乱序。如果还要求严格的顺序传输，就无法利用多路径来实现负载分担。此外，选择性重传也需要无序传输的支持。为了实现无序传输，需要接收方有更大的数据包缓冲区，从而将乱序的数据包组成一个完整的RDMA消息。

UET支持四种传输方式：

▣ ROD (Reliable Ordered Delivery)

– 需要拥塞控制、有序、可靠、无重传（依旧采用Go-Back-N）

▣ RUD (Reliable Unordered Delivery)

– 需要拥塞控制、无序、可靠、无重传

▣ RUDI (RUD for Idempotent Operations)

– 可选拥塞控制、无序、可靠、重传

▣ UUD (Unreliable Unordered Delivery)

– 可选拥塞控制、无序、不可靠、重传

包喷洒（Packet Spraying）

包喷洒是一种基于包的多路径传输。由于传统传输协议不支持无序传输，同一个数据流必须按照同一个路径传输，否则就会造成乱序，引发重传。而在AI/HPC应用中，存在大量的“大象流”，它们数据量大、持续时间长，如果能使用多路径传输一个流，将显著提高整个网络的利用率。

由于支持了RUD，UET就可以将同一个流的不同包分散到多个路径上同时传输，实现包喷洒功能。这让交换机可以充分发挥ECMP甚至WCMP（Weighted Cost Multi- Pathing）路由能力，将去往同一目的地的数据包通过多条路径发送，大幅度提高网络利用率。

拥塞控制（Congestion Control）

UET 拥塞控制包含以下重要特性，由端侧硬件和交换机配合完成，有效减小了尾部延迟。

▣ Incast管理。它用于解决集合通信（Collective）中下行链路上的扇入问题。AI和HPC应用经常采用集合通信在多个节点之间同步信息，当多个发送者同时向一个接收者发送流量，就会产生Incast拥塞。

▣ 速率调整加速。现有的拥塞控制算法，在发生网络拥塞后调整速率的过程较长，而 UET 可以快速上升到线速。方法是测量端到端延迟来调节发送速率，以及根据接收方的能力通知发送方调整速率。

▣ 基于遥测。源自网络的拥塞信息可以通告拥塞的位置和原因，缩短拥塞信令路径并向终端节点提供更多信息，从而实现响应速度更快的拥塞控制。

▣ 基于包喷洒的自适应路由。当拥塞发生时，通过包喷洒技术将流量重新路由到其它路径上，绕过拥塞点。

端到端的安全

UEC在传输层内置安全。它是基于作业（Job）的，可以对整个作业的流量进行端到端的AES加密，充分利用 IPSec 和PSP（Packet Security Protocol）的能力，减小安全加密的开销，提供可扩展安全域，并且可以由硬件卸载。

在网计算（In Network Collectives）

在网计算最早应用在HPC集群，业界主要有两个思路，一是基于网卡的，二是基于交换机。

UEC V1.0 的目标是后者，即将集合操作卸载到各级交换机上完成，避免过多的收发次数，降低节点交互频率和处理时延开销，减少约一半数据传输量，从而加速All-Reduce操作。

在部署实现上，目前AI智算领域唯一大规模商用的案例仅有英伟达的SHARP（在ASIC层面实现的硬件加速），以太网设备厂家仍处在探索阶段，例如将算力内置于交换机或外接，甚至P4可编程都是可能的思路方向。

软件层：Extended Libfabrics 2.0

硬件升级：支持UEC的交换机和网卡

UEC在规范中定义了支持超级以太网交换机的架构，可以看到大体是继承了SONiC的架构。这部分的主要关注在于控制平面上支持INC和SDN控制器；数据平面升级了SAI（Switch Abstraction Interface）API调用硬件提供的INC等能力。

UEC 6

UEC同样定义了网络端点（Fabric End Point）的软硬件架构。在硬件层，网卡升级支持UEC功能。在操作系统内核态，实现网卡驱动。在用户态，基于libfabric扩展实现INC管理等功能，支持上层的xCCL/MPI/SHMEM等应用。

UEC 7

总的来说，UEC v1.0规范重构了数据中心以太网以完全替代传统的RDMA网络，用更高的性能、更低的成本实现稳定可靠、具有百万节点的AI/HPC集群。

星融元RoCE交换机与UEC

作为UEC成员单位，星融元提供的超低时延RoCE交换机（CX-N系列）全系采用高性能的标准白盒网络硬件，搭载为生产环境深度调优的企业级SONiC发行版——多项 Easy RoCE 特性，全面兼容现有规范并提供灵活、广大的升级空间，未来将平滑演进与新一代以太网标准保持同步。

RoCE与IB对比分析（二）：功能应用篇

近期文章

在上一篇中，我们对RoCE、IB的协议栈层级进行了详细的对比分析，二者本质没有不同，但基于实际应用的考量，RoCE在开放性、成本方面更胜一筹。本文我们将继续分析RoCE和IB在拥塞控制、QoS、ECMP三个关键功能中的性能表现。

拥塞控制

拥塞控制即用来减少丢包或者拥塞传播，是传输层的主要功能，但需要借助链路层和网络层的帮助。

RoCEv2 的拥塞控制机制

RoCEv2通过链路层PFC、网络层ECN、传输层DCQCN三者协同配合，实现更高效的拥塞管理，可见，RoCEv2虽然使用了IB的传输层协议，但在拥塞控制方面有所不同。

基于优先级的流量控制（PFC）

PFC在RoCEv2中被用于创建无损的以太网环境，确保RDMA流量不因链路层拥塞而丢失。核心原理是下游控制上游某个通道开启和停止发送数据包，控制方式是发送PFC Pause和Resume帧，触发时机是根据下游SW的ingress的队列数量是否达到某个阈值。

而PFC允许在一条以太网链路上创建8个虚拟通道，并为每条虚拟通道指定一个优先等级，允许单独暂停和重启其中任意一条虚拟通道，同时允许其它虚拟通道的流量无中断通过。这一方法使网络能够为单个虚拟链路创建无丢包类别的服务，使其能够与同一接口上的其它流量类型共存。

如图1所示，DeviceA发送接口分成了8个优先级队列，DeviceB接收接口有8个接收缓存（buffer），两者一一对应（报文优先级和接口队列存在着一一对应的映射关系），形成了网络中 8 个虚拟化通道，缓存大小不同使得各队列有不同的数据缓存能力。

当DeviceB的接口上某个接收缓存产生拥塞时，超过一定阈值（可设定为端口队列缓存的 1/2、3/4 等比例），DeviceB即向数据进入的方向（上游设备DeviceA）发送反压信号“STOP”，如图中第7个队列。

DeviceA接收到反压信号，会根据反压信号指示停止发送对应优先级队列的报文，并将数据存储在本地接口缓存。如果DeviceA本地接口缓存消耗超过阈值，则继续向上游反压，如此一级级反压，直到网络终端设备，从而消除网络节点因拥塞造成的丢包。

显式拥塞通知（ECN）

ECN（Explicit Congestion Notification）是一种IP头部用于的拥塞控制的标记位，允许网络设备在发生拥塞时标记数据包，而不是丢弃它们。

RoCEv2利用ECN位来标记发生拥塞的数据包，接收方在检测到ECN标记后，发送CNP（Congestion Notification Packet）给发送方，后者通过拥塞控制算法（如DCQCN）调整发送速率。

数据中心量化拥塞通知（DCQCN）

DCQCN（Data Center Quantized Congestion Notification）是一种适用于RoCEv2的拥塞控制算法，是数据中心TCP(DCTCP)和量化通知算法的结合，最初在SIGCOMM’15论文”Congestion control for large scale RDMA deployments”中提出。DC-QCN算法依赖于交换机端的ECN标记。结合了ECN和速率限制机制，工作在传输层。当接收方检测到ECN标记时，触发CNP发送给发送方，发送方根据反馈调整发送速率，从而缓解拥塞。

综上，PFC、ECN、DCQCN分别工作在链路层、网络层和传输层。在RoCEv2中，它们被组合使用，以实现更高效的拥塞管理。

PFC：防止数据包在链路层被丢弃，提供无损传输，解决一段链路的问题。
ECN/DCQCN：发送方根据拥塞标记主动调整发送速率，减轻网络负载。解决端到端网络的问题。

InfiniBand 的拥塞控制机制

InfiniBand 的拥塞控制机制可分为三个主要部分：

基于信用的流量控制

IB在链路层实现基于信用的流量控制（Credit-based Flow Control），该机制实现了无损传输，是 InfiniBand 高性能的基础。发送方根据接收方提供的信用（表示可用缓冲区空间）来控制数据包的发送，接收方在处理完数据包后发送信用给发送方，以允许继续发送新的数据包，从而避免网络拥塞和数据包丢失。

如下图所示，发送方当前可用信用值2，通过流水线传输（pipelined transfer）连续向接收方发送数据包，但此时接收方缓冲区已满，发送方会暂停发送新的数据包，直到接收方发送新的信用。

ECN机制

当网络中的交换机或其他设备检测到拥塞时，会在数据包的 IP 头中标记 ECN（Explicit Congestion Notification）。接收方的 CA（Channel Adapter）接收到带有 ECN 标记的数据包后，会生成拥塞通知包（CNP），并将其反馈给发送方，通知其网络出现拥塞需要降低传输速率。

端到端拥塞控制

发送方的 CA 在收到 CNP 后，根据 InfiniBand 拥塞控制算法调整发送速率。发送方首先降低数据发送速率以缓解拥塞，之后逐步恢复发送速率，直到再次检测到拥塞信号。这个动态调整过程帮助维持网络的稳定性和高效性。IBA没有具体定义特定的拥塞控制算法，通常由厂商定制实现。（HCA，Host Channel Adapters，or IB NIC）

RoCEv2与IB拥塞控制机制比较

两者的拥塞控制机制比较如下：

可见，RoCE与IB的拥塞控制机制基本相同，区别在于IB的拥塞控制机制集成度较高，通常由单个厂家提供从网卡到交换机的全套产品，由于厂商锁定，价格高昂。而RoCE的拥塞控制机制基于开放协议，可以由不同厂家的网卡和交换机来配合完成。

随着大规模AI训练和推理集群的扩展，集合通信流量导致了日益严重的拥塞控制问题，由此出现了一些新的拥塞控制技术，如基于In-band Network Telemetry (INT)的HPCC（High Precision Congestion Control），即通过精确的网络遥测来控制流量，以及基于Clear-to-Send (CTS)的Receiver-driven traffic admission，即通过接收方的流量准入控制来管理网络拥塞等。这些新技术在开放的以太网/IP网络上更容易实现。

QoS

在RDMA网络中，不光RDMA流量要获得优先保证。一些控制报文，如CNP、INT、CTS，也需要特别对待，以便将这些控制信号无损、优先的传输。

RoCEv2的QoS

在链路层，RoCEv2采用ETS机制，为不同的流量分配不同的优先级，为每个优先级提供带宽保证。

在网络层，RoCEv2则使用DSCP，结合PQ、WFQ等队列机制，为不同的流量分配不同的优先级和带宽，实现更精细的QoS。

InfiniBand的QoS

在链路层，IB采用SL、VL及它们之间的映射机制，将高优先级的流量分配到专门的VL，优先传输。虽然VL仲裁表 (VL Arbitration Table)能够通过分配不同的权重来影响和控制带宽的分配，但这种方式不能保证每个VL的带宽。

在网络层，IB的GRH支持8个bit的Traffic Class字段，用于在跨子网的时候提供不同的优先级，但同样无法保证带宽。

由此可见，RoCE能够为不同的流量类型提供更精细的QoS 保证和带宽控制，而 InfiniBand 只能提供优先级调度，而非带宽的明确保障。

ECMP

RoCE的ECMP

数据中心IP网络为了高可靠和可扩展性，通常采用Spine-Leaf等网络架构。它们通常在一对RoCE网卡之间提供了多条等价路径，为了实现负载平衡和提高网络拓扑的利用率，采用ECMP（Equal Cost Multiple Paths）技术。对于给定的数据包，RoCE交换机使用某些数据包字段上的哈希（Hash）值在可能的多条等价路径中进行选择。由于可靠传输的要求，同一个RDMA操作应当保持在同一个路径中，以避免由于不同路径造成的乱序问题。

在IP网络中，BGP/OSPF等协议均可以在任意拓扑上计算出等价路径，然后由交换机数据平面基于IP/UDP/TCP等头部字段（如五元组）计算哈希值并轮流转发到不同路径上。在RoCE网络中，为了进一步细分RDMA操作，可以进一步识别BTH头部中的目的QP信息，从而实施更细粒度的ECMP。

InfiniBand的ECMP

在控制平面，IB的路由基于子网管理器，在拓扑发现的基础上实现ECMP，但由于集中式的子网管理器与网络设备分离，可能无法及时感知网络拓扑的变化，进而实现动态的负载均衡。

在数据平面，IB的ECMP同样基于哈希计算和轮转机制。

总结

在拥塞控制方面，RoCE结合了PFC, ECN和DCQCN提供了一套开放的方案，IB则拥有基于Credit的一套高度集成的方案，但在应对大规模集合通信流量时均有所不足。
在QoS方面，RoCE可以实现每个优先级的带宽保证，而IB仅能实现高等级的优先转发。
在ECMP方面，两者均实现了基于Hash的负载分担。

总结来看，IB具备已验证的高性能和低延时优势，RoCEv2则在互操作性、开放性、成本效益方面更胜一筹，且从市场占比及认可度来看，RoCEv2逐渐比肩IB；但不得不承认的是，RoCE和IB在应对大规模AI训练和推理中高带宽、突发式和广播型的集合通信流量时，均有所不足，而RoCE基于其广泛的以太网生态系统，能够更快速地拥抱新技术新协议，其潜力和可塑性更胜一筹，未来有望在网络格局中扮演更重要的角色。

星融元提供一系列基于RoCE的开放网络产品与解决方案：

10G-800G的全场景互联：星融元CX-N数据中心交换机的单机转发时延（400ns）低至业界平均水平的1/4~1/5；采用BGP-EVPN、VXLAN、MC-LAG等技术构建可靠的大二层网络满足生产网络稳定性需求。
搭载开放网络操作系统：星融元AsterNOS以SONiC为内核、依托容器化的系统架构，并提供RESTful API支持第三方应用快速集成，或对接上层管理调度平台，例如OpenStack，K8s等。
EasyRoCE极简运维：支持无损网络一键部署，Prometheus + Grafana 可视化监控大屏配合专用命令行，问题快速定位解决。

参考文档：

https://zhuanlan.zhihu.com/p/643007675

https://blog.csdn.net/essencelite/article/details/135492115

https://support.huawei.com/enterprise/zh/doc/EDOC1100075566/d1e17776

https://www.researchgate.net/publication/4195833_Congestion_Control_in_InfiniBand_Networks

返回资源中心

云化园区

网络操作系统（SONiC）

可视交换机

开放硬件平台

近期文章

算力基础设施—AI 智算RoCE网络交换机

外观展示

内部架构

AI RoCE 交换机操作系统（AsterNOS）

基于企业级SONiC的增强特性

企业版 SONiC vs 社区版

800G 数据中心交换机（TL10平台）实测数据

DeepSeek模型推理指标对比：IB vs RoCE

最新动态

近期文章

什么是MPLS？

工作原理

标签结构

为什么需要MPLS？

服务质量（QoS）

流量工程（TE）

业务隔离与VPN

最新动态

近期文章

从WiFi 6到WiFi 7：技术升级的核心突破

带宽与速率的指数级提升

多链路操作（MLO）的革命性突破

空间流与MIMO技术的扩展

频谱利用与抗干扰优化

国内WiFi7发展的困境

破局之道：立足现有优势，挖掘场景化潜力

最新动态

近期文章

智算网络的主流架构

InfiniBand

InfiniBand网络架构示意图（来源：2023智算中心网络架构白皮书）

RoCEv2

RoCEv2网络架构示意图（来源：2023智算中心网络架构白皮书）

智算网络中的负载均衡与流量控制

InfiniBand网络的负载均衡和流控机制

RoCE网络的负载均衡和流控机制

图片引用自：公众号西北吹风

负载均衡技术

流控机制

技术选型

WCMP

最新动态

近期文章

什么是PTP？

什么领域需要PTP？

PTP实现时间同步的核心机制

两步模式（Two-Step）

一步模式（One-Step）

星融元园区交换机多款产品支持PTP功能，同步精度可达20ns？！

最新动态

近期文章

RDMA 网络技术是什么？

主流协议

星融元RoCE无损以太网

如何通过一键RoCE简化配置流程？

如何解决网络拥塞时的性能下降？

应用场景与效果

最新动态

关注星融元

开放网络能否平替IB？

测试背景

测试结论

AI智算场景

HPC 场景

分布式存储场景

HPC集群架构和通信流量特征

HPC网络性能测试方案设计

端到端转发时延测试

MPI基准测试

LinPack基准测试

HPC 应用测试

附录：基础环境配置

关注星融元

什么是超级以太网系统

超以太网协议栈概览