RDMA高速網絡狀態感知與度量指標體系研究

徐佳瑋 嚴 明 吳 杰

(復旦大學計算機科學技術學院 上海 200433)(復旦大學教育部網絡信息安全審計與監控工程研究中心 上海 200433)

0 引 言

近幾年來，數據呈爆炸式增長。根據國際超級計算機500強排名的數據，基于TCP/IP的傳統以太網是世界排名前500中最流行的互聯方式，隨著40 Gbit/s乃至100 Gbit/s網卡的出現，遠程直接內存訪問(Remote direct memory access,RDMA)技術已經在世界頂級超級計算領域獨領風騷[1]，成為目前主流的高性能計算機互連技術之一。RDMA技術將數據直接從一臺計算機的內存傳輸到另一臺計算機，它核心在于將網絡層和傳輸層下移到服務器的硬件網卡中，使得數據報文在網卡上完成四層解析后直接到達應用層軟件而無須CPU的干預。與傳統基于TCP/IP協議的網絡相比，RDMA網絡通過將大多網絡功能卸載到物理網卡上、繞開操作系統內核、零拷貝技術實現在提高吞吐量的同時降低時延和CPU占用率。

RDMA技術最早出現在IB(Infiniband)網絡中，用于高性能計算集群的互聯，后來業界廠商把RDMA移植到傳統以太網上，推動了RDMA技術的普及，這樣RDMA得以部署在目前使用最廣泛的數據中心網絡上。在以太網上RDMA又根據協議棧的不同，分為RoCE(RDMA over Converged Ethernet)和iWARP(RDMA over TCP/IP)兩種技術。根據相關的性能測試，RoCE相對于iWARP吞吐量更高、時延更低[2]。RoCE分為RoCE v1版本和RoCE v2版本，RoCE v2相對于v1來說支持了IP路由，因此現在RoCE網卡大多使用RoCE v2版本。隨著數據中心網絡轉發數據的增大，許多數據中心都在利用RoCE來加速網絡傳輸。現在許多的框架、人工智能分布式模型訓練場景、主流的數據庫系統、并行存儲文件系統的應用中，也廣泛使用了RDMA技術[3-4]。另外，隨著應用部署的復雜性增大，當出現故障時，非硬件故障性的網絡問題不容易輕易復現，因此數據中心非常需要對RoCE網絡進行實時度量。

然而，目前業界在針對RoCE網絡的狀態感知監控方案和TCP網絡相比還不成熟，度量指標體系不夠完善。首先，現有對RoCE網絡的度量更多地是以依靠在本地網卡軟件抓包之后離線分析或用昂貴的硬件設備分析為主，缺少針對RoCE深入到應用層業務流的基于軟件實時狀態感知系統。其次，從度量指標而言，目前RDMA還沒有成熟的多維度、多層次、完善的指標體系，RoCE廠商只給出了系統上硬件統計故障診斷信息，從單節點角度，憑借現有的網卡錯誤項的累計值不足以了解RDMA網絡狀態和定位問題。另外，根據實驗測試結果，采用本地抓包之后離線分析的方式，會對網卡的最大傳輸性能造成一定損耗。如圖1的測試結果所示，若在服務器節點本地用tcpdump之類的開源工具進行流量捕獲從而離線分析的方法，隨著消息長度不斷增大，當消息大小在256字節以上時，本地抓包使得單網卡的最大傳輸性能下降了10%～47%。且對于多節點的離線分析，需要匯總分析結果，二次分析的分析工作復雜。

圖1 未開啟抓包選項和tcpdump抓包時的網卡帶寬對比

傳統以太網對TCP流的分析可以幫助數據中心網絡管理員優化網絡管理，類似地，對RoCE網絡進行類似業務流的分析也可以對網絡中系統的服務調用和數據傳輸的流量分布有進一步的認識。隨著RoCE的普及，對數據包的進一步分析是很有必要的。對傳輸類型以及基于流等方面的統計度量，有利于進一步研究流控機制、擁塞控制、優化資源調度，也有助于數據中心的網絡管理員了解網絡情況，進行故障定位和網絡規劃，有助于指導應用服務的研發人員優化和加速應用。

針對上述問題，本文設計了一種基于軟件的RDMA網絡狀態感知與度量系統并針對RoCE網絡進行實現和實驗評估。本文的主要貢獻如下：

(1) 提出了一個多角度、多維度、多層次的RoCE網絡指標度量體系，全方位分析網絡狀態，彌補了現有工作只有硬件統計的錯誤累積數據、缺失應用層和業務流方面指標而無法全方位感知網絡狀態的不足；

(2) 設計了一種基于軟件的RDMA實時網絡狀態感知和度量系統，采取旁路分布式捕獲流量的方式并同時采用Sketch流抽樣算法對RDMA的業務流進一步分析，成本低，易于部署，可擴展性和靈活性高，且對原傳輸節點的影響較小；

(3) 針對RoCE網絡實現并模擬網絡場景進行實驗評估，實驗結果顯示，本文系統能夠在較低的誤差范圍對RoCE網絡進行客觀的度量，從多角度展現網絡狀態和問題，能夠對數據中心的故障定位和應用服務調度提供一定指導。

1 相關工作

目前工業界和學術界針對RDMA的度量主要有三種類型，分別是基于硬件的流量捕獲抓包方式、基于軟件的流量捕獲離線分析方式及針對鏈路的帶寬時延基準性能測試工具。

文獻[5]介紹了ibdump，它是Mellanox公司官方提供的OFED驅動的一個抓包組件，其缺陷是當流量速率很高時會丟包，只適用于Mellanox的硬件設備，只能作為軟件運行在傳輸節點上，它的最大捕獲能力依賴于主機上的RAM或者磁盤空間，且隨著流量增大會發生無意識無規律的丟包。另外，根據Mellanox最新的OFED驅動文檔，ibdump僅支持Connect-X3和Connect-X3 Pro[6]，不支持之后的網卡版本。ibdump只具有抓包功能，而不具有任何流量分析的功能。

文獻[7]的CatC是LecCroy公司的一個硬件分析器。它在部署時必須串聯在一條IB鏈路中，部署繁瑣，價格昂貴，并且它抓包存儲下來的.ibt文件只能通過本公司的專用IBTracer軟件打開，此外CatC只適用于SDR (8 Gbit/s) 的速率且只有2 GB的存儲容量。

文獻[8]的tcpdump是一個常用的流式網絡數據采集分析工具，從OFED3.2版本、Connect-X4網卡開始，配合libpcap 1.9.0-lp150.76.3[9]及以上版本，tcpdump可以支持捕獲RDMA數據包[10]，它對截獲的數據并沒有進行徹底解碼，更適合使用簡單的過濾規則保存到文件中，然后再使用其他程序進行離線解碼分析。tcpdump在大流量下受性能和存儲容量的影響不適合長期在線實時監測。

文獻[11]的Perftest和文獻[12]的qperf是用于各種RDMA通訊類型的性能測試應用程序。Perftest是Mellanox OFED驅動中的基準測試程序包，可以用于調優和功能測試。qperf由Linux操作系統默認自帶，以用來測試兩個節點之間的帶寬和延遲，可以用來測試RDMA傳輸的指標。它們都是基于單點的鏈路角度的測量帶寬時延的工具，不涉及對業務數據流的度量。

現有關于RoCE度量的研究工作和工具，在基于硬件的流量捕獲方面，雖然在性能和精度方面較有優勢，但是部署時需要在鏈路中部署專用硬件，成本較高，靈活性不強；在基于軟件的RoCE流量度量方面，廠商自產的抓包工具只有抓包功能，開源的抓包分析工具對業務維度方面沒有進一步的統計，只有簡單的帶寬時延測試，缺乏業務數據的分析。并且，基于軟件的工具在傳輸節點上捕獲流量時需要開啟RoCE網卡的sniffer模式，這會帶來性能損失[13]，影響原本的傳輸性能。另外，在RDMA度量體系來講，RoCE廠商除了一些基于硬件上統計信息外，并不關注傳輸內容和事務本身，RDMA還沒有完善的度量指標體系。

2 RDMA度量指標體系設計

度量指標體系的層次設計以面向應用業務需求為目的，主要關注應用層的指標，用以指導應用加速優化和網絡規劃調度，輔以部分網絡層面指標和硬件故障統計信息來展示RoCE網絡狀態，用以指導網絡問題和故障定位。

原有廠商提供的硬件統計指標只能從單個物理主機節點角度獲得某個RDMA網卡一些錯誤信息總體的累計統計值，未細分RDMA操作和連接。而當需要進行網絡狀態感知、服務故障定位，對采用RDMA加速的服務進行優化調度時，單從整體統計值上難以判定具體問題，需要分析RDMA數據包協議內容，結合應用層面的指標一起聯合分析。

如圖2所示，度量指標體系總體上從網絡狀態感知和業務應用狀態感知兩個大層面進行劃分。網絡狀態感知層包括針對節點可用性、連接可用性、網絡負載狀態。業務狀態感知層包括針對RDMA操作相關的指標和基于業務流的分析指標。各層次之后從表征的網絡模型角度再向下細分，分為鏈路層、系統層、網絡層、應用層。所有單項指標從指標意義角度，分為運行狀態指標和負指標。運行狀態指標指的是除負指標這類關于軟硬件錯誤和故障信息的指標的其他指標。負指標根據方向的不同，又分為作為發送端檢測到的和作為接收端檢測到的兩個角度。

圖2 度量指標體系層次圖

2.1 節點可用性指標

節點可用性考慮的是針對網絡和服務性能下降時，關于RDMA節點方面的狀態感知。

(1) 指標內容。節點可用性指標內容如表1所示。

(2) 指標來源。鏈路層指標通過讀取Linux系統下的/sys/class/infiniband/的統計文件獲取后計算得出[14]，連同系統資源統一在本地收集。

2.2 連接可用性指標

連接可用性指標從網絡層數據包角度表征網絡狀態。

(1) 指標內容。連接可用性指標內容如表2所示。

(2) 指標來源。負指標通過讀取Linux系統下的/sys/class/infiniband/的統計文件獲取后計算得出。

2.3 網絡負載指標

網絡負載指標主要針對網絡規劃和網絡擁塞發現兩個角度。

(1) 指標內容。網絡負載指標內容見表3。

表3 網絡負載指標

盡管傳統RDMA的應用場景多以高速傳輸為主，但隨著RDMA技術在企業應用服務中的應用，RDMA調用前的連接建立時間對于服務吞吐量也變得尤為重要，因此選用建立RDMA連接的TCP RTT作為指標，計算請求端進行握手時發出SYN包到發送ACK的多個連接的平均值作為該連接的RTT。

(2) 指標來源。RTT通過度量系統進行在線實時分析計算得出， RDMA操作時延通過在節點發送探測包計算得出。其余指標通過讀取Linux系統下的/sys/class/infiniband/的統計文件獲取后計算得出。

2.4 RDMA操作相關流量指標

RDMA操作相關指標旨在發現網絡中各種服務調用中RDMA操作類型的分布，從而了解網絡中真正關鍵操作，發現性能瓶頸，指導基于RDMA的應用的優化方向。RDMA各Opcode類型流量速率、RDMA消息吞吐量、Queue pairs的消耗量可以為研究時延敏感型、吞吐量敏感型、帶寬敏感型的應用之間的互相競爭分析提供依據。

(1) 指標內容。RDMA操作相關指標內容見表4。

表4 RDMA操作相關指標

(2) 指標來源。負指標通過讀取Linux系統下的/sys/class/infiniband/的統計文件獲取。

opcode流量速率指標通過度量系統Sketch算法進行在線實時分析計算得出。RDMA消息吞吐量通過系統解析opcode中的“LAST”來標記一條消息的結束，從而統計得出。其余指標通過讀取Linux系統下的/sys/class/infiniband/的統計文件獲取后計算得出。

本文目前針對RoCE使用最廣泛的Mellanox的RoCE v2協議，其支持ConnectX-3 Pro及以上版本的網卡。

如圖3所示，RoCE在以太網數據包中封裝了IB。RoCE v2(Layer 3)運作在UDP/IPv4或UDP/IPv6之上，采用專用端口4791。

圖3 RoCE v2 報文格式[16]

① 操作碼(8 bits)：該字段表示IBA數據包的類型。例如CNP數據包的操作碼是0x81(10000001b)，Reliable Connection(RC)-SEND First的操作碼是0x00。該字段可以從數據包角度將RDMA的操作類型的統計細化到消息和opcode層面。

② Solicited Event(SE)(1 bit)：該字段表示responder方是否應該產生一個事件。

③ Pad Count(PadCnt)(2 bits)：該字段表示將多少額外字節添加到有效負載以對齊4字節邊界。

④ 傳輸層報頭版本(TVer)(4 bits)：該字段表示IBA傳輸層報頭的版本。

⑤ 目的Queue Pair(DestQP)(24 bits)：該字段表示了目的方的Work Queue Pair(QP)的序號，例如0x0000d2=210。

⑥ 確認請求(A)(1 bit)：該字段用來表示需要responder回復一次確認。

2.5 業務流指標

網絡流量測量除了捕獲之外需要對流量進一步的解析和分析，從而掌握網絡運行狀態，提取行為特征。

Queue pairs可以唯一表示RDMA操作，因此定義RDMA的流是同一個Queue pairs的包序列號連續的所有RDMA消息，即SrcQP+DstQP或源IP+目的IP+UDP源端口的消息。RDMA流的大小的定義是一條流在時間窗口內的messages的字節長度總和。在TCP網絡中，基于流的分析是很有意義的，本文借鑒TCP網絡中的定義，對RDMA流的大小超過配置文件中設定的閾值的RDMA流稱為大流，小于閾值的為小流。大流一般對于帶寬較為敏感，小流一般對于時延較為敏感。

RDMA流維度的相關指標包括RDMA流總個數、RDMA流速率大小、RDMA大流個數、流抖動率、小流時延。

3 RDMA狀態感知度量系統總體架構

系統框架如圖4所示，系統總體分為度量系統和Agent。度量系統運行在網絡中獨立的一臺服務器上，網絡流量由交換機鏡像口鏡像，可經過分流器分流，連接到多個度量系統所在的服務器上，捕獲流量的網卡是以太網網卡。部署環境要求在被鏡像出的流量在進入服務器之前的鏈路不發生丟包且不存在重復流量。

圖4 系統架構圖

度量系統主要負責流量的旁路捕獲和分析。Agent作為度量系統的信息收集輔助工具運行在每個RDMA傳輸節點上，主要負責監聽傳輸節點的硬件網卡自帶的網卡、端口統計，輔助探測鏈路的時延，并發送給Controller，對本地節點的影響很小。對于需要測量時延的節點，Controller將指令發送給其上的Agent，之后Agent發送探測數據包得到節點之間的時延發送給Controller。

采用旁路分布式全量捕獲流量和Agent輔助收集基礎信息相結合的方式的優點是實現了在高流量場景下，在減輕觀察者效應的同時，可以從網絡和應用兩個角度，兼顧實現多維度指標的收集。

度量系統從架構上分為控制平面和數據平面。

1) 控制平面。控制平面是Controller控制模塊。Controller模塊主要負責配置相關元數據信息、添加度量處理任務、進行相關網絡狀態的查詢操作，它還負責和節點上的Agent交互，檢測Agent的心跳，接收Agent上報的節點上的RDMA端口、錯誤信息和時延相關數據。元數據包括服務器網卡IP端口、流處理的任務和類型、統計間隔，以及Agent采集信息的頻率和Sketch算法的參數如時間間隔、黑白名單、任務類型、大小流閾值等一系列可配置項。配置文件使用YAML格式進行描述。

2) 數據平面。數據平面分為流量捕獲解析模塊、度量任務處理模塊、整合模塊。

(1) 流量捕獲解析模塊。Collector從網卡中全量捕獲流量，Parser根據RDMA協議格式解析數據包各個字段，提取有效信息。服務器每個網卡對應一個Collector，之后由多個Parser并行進行數據包的解析處理。

(2) 度量任務處理模塊。根據配置中新建若干度量任務，每個任務都會利用流量捕獲解析模塊的輸出使用不同的Sketch算法進行統計，將統計結果輸入到整合模塊。

(3) 整合模塊。整合模塊匯總整合各個分布式度量節點處理的結果，對于某個指標，累計分流到的節點的計算數值，并提供給Controller查詢統計值的接口或者輸出成離線文件。

4 系統主要功能具體實現

4.1 流量捕獲方法

基于硬件的流量捕獲方式有精度和性能的優勢，但是不易部署且價格昂貴。本文采用軟件旁路方式進行分布式流量捕獲，采用軟件方式比較輕量，可以根據配置和網絡情況指定過濾規則，以插件方式添加流量分析處理任務，使得指標顯示可組合，分析更加靈活。

流量捕獲解析模塊中，Collector使用零拷貝技術，根據配置文件全量捕獲設定的時間窗口的數據包。度量系統根據流量大小和服務器資源情況可以是一個或多個，當需要處理的流量很大時，可將總流量分成交換機的多個端口鏡像再經過分流器基于IP規則、方向、RoCE中的序列號字段過濾出分散的無重復的流量，再輸入到分布式度量服務器的多個網卡中并行處理。采用多網卡分布式抓包后整合的方式實時分析流量，整合模塊匯總顯示各網卡的統計結果。

4.2 RDMA流維度的指標度量方法

在數據中心中，更關注流量的分布和趨勢，沒有必要使用hash table類型的計數器統計獲取非常精確的數值。采用基于概率統計理論的Sketch算法統計RDMA流維度指標雖然會產生一定誤差，但是其誤差在可以接受的范圍之內，足以獲取需要的流量分布和趨勢特征[17]。此外，sketch的內存占用更小，降低了設備的成本。

如圖5所示，度量任務類型根據Controller配置文件下發。流量捕獲分析模塊采用純軟件方法解析出發送端、接收端、操作碼、Queue Pair、數據包大小之后，判斷數據包所屬的流是否是新流，更新時間窗口內的流總個數和流大小。對于高于一定閾值的大流來講，判斷大流的抖動情況；對于小于一定閾值的流來講，進一步向Agent發送信號，示意Agent定期發送時延檢測數據包，最后Agent將結果返回給Controller。

圖5 RDMA流維度度量流程

(1) RDMA流總個數估計。流總數估計任務使用Linear Counting(LC)算法[18]估計一個時間窗口內不同的流的個數。LC算法是一種計數估計算法，假設一個哈希函數結果服從均勻分布，結果空間為{0,1,…,m-1}的m個值。再有一個長度為m的bitmap，每個比特都是初始化為0。對流式數據里每個元素，也就是RDMA流的標識，LC算法先通過哈希函數將標識映射到bitmap的某個比特x上，如果第x個比特為0，那么將第x個比特設置為1。查詢時，根據1的個數和比例得到關于RDMA流的總數的估計。

(2) RDMA流大小估計、RDMA opcode大小估計。流大小估計任務和RDMA opcode大小估計任務使用Count-Min(CM)算法[19]獲得任意流在某時間窗口內的大小估計值，即RDMA流速率，從而在下一階段針對不同類型的流進行進一步的分析。CM算法是一種概率數據結構，維護一個長度為i的數組，每個數組對應j個計數器和一個對應的哈希函數，初始化每個計數器為0。面對流式數據里每個新的事件元素，計算每個元素在每個數組中根據哈希得到的值，作為數組的位置索引，然后將數組對應位置索引下的計數器加一。當需要查詢某個元素時，返回這個元素在不同數組中計數值的最小值。

根據Controller的配置，判定RDMA流大小大于設定閾值的流為大流，小于設定閾值的流為小流，分情況進行下一步度量。

(3) 大流抖動檢測。抖動檢測是針對大流，估計在兩個相鄰的時間窗口內，流的大小變化是否超過一定的閾值。使用與Count-Min類似的數據結構，通過比較兩個時間窗口的值的偏差和上一個時間窗口的值的比值，檢測流量大小是否發生抖動。

(4) 小流檢測。對于網絡中大小超過一定閾值的小流，進一步探測傳輸節點之間的時延。Controller查詢當前時間窗口流大小前p小的流對應的傳輸節點，將信號發送給節點上的Agent，每個Agent都可以當做Server和Client。在下一個時間窗口內，Agent以一定頻率連續發送10個時延探測包。在時間窗口結束后，將時延探測平均值返回給Controller。

5 實 驗

5.1 物理實驗環境

本文使用了四臺服務器與一臺交換機，實驗環境如圖6所示，其中三臺服務器用于傳輸數據且部署Agent，另一臺服務器用作運行度量系統。

圖6 實驗環境拓撲圖

四臺服務器使用RoCE 100G ConnectX-5網卡，服務器系統上安裝的網卡OFED驅動版本為MLNX_OFED_LINUX-4.0-2.0.0.1，交換機型號為Mellanox SN2100，服務器具體規格如表5、表6所示。

表5 服務器操作系統和內核版本

表6 服務器CPU和內存

傳輸節點之間使用官方的Perftest基準性能測試工具，以及用RDMA ibverbs標準庫函數編寫的程序，模擬客戶端和服務端發送流量。

5.2 指標驗證

本節利用狀態感知度量系統指標討論不同網絡狀態下的指標特征變化情況。實驗過程中，單節點度量系統服務器CPU占用率平均約為64%，Agent對服務器的CPU占用率基本低于2%，對原傳輸節點的資源影響非常小。

(1) RDMA RC-Write/Send/Read操作時延隨流量變化情況。圖7顯示了單流情況下基于RDMA可靠傳輸Write/Send/Read操作隨流量增長的變化情況，Write操作的操作時延一般性低于Send和Read操作，符合RDMA的特征，并且度量系統分析的結果和通過tcpdump抓包后離線分析呈現同樣的結果。

圖7 負指標數值的增長情況

(2) 建立連接時TCP RTT隨流量變化情況。如圖8所示，實驗測量了兩個傳輸節點單流情況下隨著流量不斷增大，再次建立RDMA連接時的TCP RTT平均時間。當流量在10 Gbit/s以上時，建立連接時的網絡時延有明顯增大。度量系統分析的結果和通過tcpdump抓包后離線分析呈現同樣的結果。

圖8 建立連接時TCP RTT隨流量變化

(3) RoCE流個數與流大小指標驗證。本節測試多節點多流時的流大小和個數分布情況，在192.168.2.201服務器和192.168.2.20之間產生的10條速率小于5 Mbit/s的穩定RDMA背景流，另外在三臺服務器上產生四條速率分別為1/3/4/6 Gbit/s的流。多流分布情況如圖9所示，接近橫坐標軸的實線部分的流flow1-flow10是背景流。系統可以客觀顯示網絡中的流分布情況。

圖9 多流流大小分布情況

(4) RDMA 操作的相互影響。在192.168.2.206和192.168.2.202之間產生25個QP用來進行RC-Send/Write/Read、UD/UC-Send、UC Write操作傳輸流量，所有操作同時開始，模擬多操作并存時的流量相互影響情況，同時作為下一節網絡擁塞場景模擬的流量來源。

如圖10所示，在流量傳輸過程中，Read操作程序產生訪問遠程地址錯誤日志，而狀態感知系統可以客觀顯示由于流之間存在相互影響，Read操作先占用了大部分資源，導致其他操作在建立連接時略微滯后。

圖10 多流RDMA操作的流量大小分布情況

5.3 RDMA常見場景問題驗證

1) 場景一：當傳輸過程中接收端程序斷開導致連接斷開的情況模擬。模擬在進行RC-Send傳輸中接收端程序突然中止的情況，RDMA操作相關指標變化累計和如圖11所示。

圖11 場景一RDMA操作相關指標變化

發送端的Ack超時錯誤的次數、請求端檢測到CQE錯誤的次數、請求端檢測到CQE發生flush錯誤的次數都同時增長。但網卡與鏈路的狀態無任何異常，節點可用性指標、連接可用性指標、網絡負載指標正常，排除網絡擁塞造成的傳輸故障，表征了接收端的應用程序存在著故障。

(2) 場景二：網絡擁塞模擬。使用如圖10所示的同樣的流量生成方法，模擬單節點發送網絡擁塞的場景。如圖12、圖13所示，當Read操作程序產生訪問遠程地址錯誤日志時，RDMA操作時延較正常情況下增加了9.1%～87.7%，同時發送端和接收端的網絡負載相關指標同時變成非零，并且接收端的CNP信號(responder-rp_cnp_handled)數量較其他指標在傳輸時段的累積和更多，因此可以說明是發送端節點導致的網絡擁塞。

圖12 RDMA RC操作時延的前后對比

圖13 場景二網絡負載相關指標數值在傳輸階段的累計

(3) 場景三：大流抖動模擬。針對帶寬敏感的應用場景，模擬在大流出現抖動的情況，同樣產生如圖9中的10條背景RDMA流，另外產生流量趨勢隨機變化三條高速率的RDMA流，設定大流閾值為5 Gbit/s，抖動閾值為2.5 Gbit/s，抖動窗口為1秒。如圖14所示，度量系統可以準確識別出三條流的大小抖動變化。

圖14 場景三大流抖動檢測

5.4 誤差評估

本文選取識別、檢索、分類、翻譯等領域常用評估指標：平均絕對誤差、平均相對誤差和準確率。

(1) 平對絕對誤差。平均絕對誤差是所有流某個指標測量值和實際值偏差的絕對值和實際值的比值的平均。對于流的大小的估計和Opcode流量速率估計將使用平均絕對誤差來評估誤差。

(2) 相對誤差。相對誤差是絕對誤差和測量值的平均值的比值的平均值，通常用絕對值。對于總的流個數的估計使用相對誤差來評估誤差。

(3) 準確率。準確率是系統正確識別的指標項個數和應當被識別出的指標項個數的比值的平均值。

除從系統上收集的文件數據外，其余所有指標的真實值采用RoCE官方的Perftest基準性能測試工具以及用tcpdump同步抓包離線分析的結果，和系統計算出的各項指標進行誤差計算。

(1) RoCE流個數估計誤差。網絡中的總的RoCE流個數采用相對誤差驗證，在三個節點之間隨時間變化產生共1～72條流量速率范圍在0.5 Mbit/s～20 Gbit/s的流，估計值和真實值的相對誤差小于2.7%。

(2) 流大小估計和Opcode操作流量估計的誤差。流大小分布估計和RDMA操作流量估計采用平均絕對誤差，流量模擬分別采用5.2節(3)、(4)中的流量產生方法，測試時長為2分鐘，每兩秒計算一次，兩者的平均絕對誤差分別為4%和11.3%。

(3)大流和流抖動識別誤差。產生5條流量速率小于0.5 Gbit/s背景RDMA流，5條速率在1～5 Gbit/s的RC-send RDMA流，與離線文件對比，大流閾值設定梯度為1.5/2.5/3.5 Gbit/s，抖動閾值設置為2 Gbit/s，流量速率大小分別變化4次，測的大流和抖動識別準確率平均值為95%。

經過誤差分析，該狀態感知度量系統可以客觀地反映網絡狀態的變化趨勢。

6 結 語

本文設計、實驗并評估了一個可擴展、低成本、面向多點網絡的RDMA網絡在線實時狀態感知度量系統，設計了多維度多層次的RoCE網絡度量指標體系，在RoCE網絡中針對不同類型和大小的流量對RDMA的特征數據進行估計，由此給出一些可供參考的故障診斷意見。結果顯示，系統可以在較低誤差下多方位展現網絡狀態。

下一步工作將細化RDMA的操作，將更多的指標變化的含義和網絡錯誤匹配，另外考慮增加系統對iWARP和IB網絡場景下的適用支持。