基于網絡包延遲偏差的硬件動態擁塞控制機制

任秀江，斯添浩，周建毅，謝向輝

(1.江南計算技術研究所,江蘇 無錫 214083;2.數學工程與先進計算國家重點實驗室,江蘇 無錫 214125)

1 引言

隨著高性能計算機系統規模的快速增長，互連網絡已經成為提升現代高性能計算系統性能的技術瓶頸[1]。高性能互連網絡設計的目標是以盡量小的物理開銷獲得更低的報文傳輸延遲以及更高的網絡吞吐率。在一個拓撲結構和路由算法確定的互連網絡中，擁塞控制機制對提高網絡性能有著重要作用。現有的擁塞控制技術大多基于有損網絡，網絡擁塞形成后都是通過直接丟包的方式反饋擁塞信息[2,3]。傳統計算機網絡中的擁塞控制技術，大多在擁塞發生后才能啟動擁塞控制[4 - 6]，從擁塞形成到控制機制達成效果的延遲較大。這一點不適合應用于高性能互連網絡，因為在高性能計算系統中，持續的低延遲事件可能會因為一個小的長延遲操作導致的連鎖反應而降低應用的性能[7,8]。一個理想的擁塞控制機制能夠合理地分配網絡通信資源，避免資源的閑置浪費，同時通過合理的通信任務調度，及時避免通信熱點形成，減少因為資源競爭導致的通信等待，提高網絡整體通信性能。研究適合高性能互連網絡的擁塞控制技術，對提高高性能計算系統性能至關重要。

本文對高性能互連網絡中的擁塞過程進行研究，提出了一種基于網絡包延遲偏差的硬件動態擁塞控制機制CMDPD(Congestion-control Mechanism based-on Deflection of Packet Delay)，在通信源節點按目標節點統計記錄的網絡包平均傳輸延遲，基于實時網絡包傳輸延遲與已記錄的平均傳輸延遲偏移差值(即偏差)預判網絡擁塞狀態，通過切換通信目標等方式減少對擁塞目標注入量，降低對擁塞目標的通信競爭，達到擁塞避免的目的。通過網絡包級延遲的快速反饋機制預判擁塞，主動避免的方法減少網絡熱點的形成，減少網絡包等待，及時切換通信目標的方法能夠提高網絡吞吐量，平衡網絡整體性能。

2 相關研究

網絡擁塞是指通信請求對網絡資源的需求超過了網絡固有容量的一種持續過載的網絡狀態。互連網絡最重要的性能參數就是延遲和吞吐率[9]，發生擁塞后，網絡包傳輸延遲增加，網絡的吞吐率下降，網絡整體性能降低。

根據發生擁塞后網絡報文是否可以被丟棄，互連網絡分為有損網絡和無損網絡兩大類。有損網絡通過丟包、慢啟動等操作緩解擁塞[10]。無損網絡不會發生丟包，但當出現網絡資源競爭時，也會因為排隊發生網絡包延遲增加、網絡吞吐率降低的情況。當網絡通信熱點持續存在時，網絡性能也將大打折扣。高性能互連網絡屬于無損網絡，對延遲、吞吐率有更高的要求，解決高性能互連網絡中擁塞控制更具挑戰性。

2.1 被動擁塞控制技術

在擁塞發生后再采取控制的技術稱為被動擁塞控制技術。

比較成熟的被動擁塞控制技術有ECN(Explicit Congestion Notification)擁塞控制技術等。ECN擁塞控制技術最早于1994年基于TCP/IP被提出，能夠避免不必要的報文丟棄，減少了TCP連接中由于報文丟棄而增加的額外延遲[11]。2001年惠普實驗室提出了基于IB(InfiniBand)網絡的擁塞控制技術ECN[12]，利用ECN反饋機制對源節點進行報文注入抑制。文獻[13]提出了一種基于IB網絡的端到端的擁塞控制機制，利用消息層級的應答機制控制擁塞擴散。文獻[14]提出了一種基于標記的擁塞控制技術，由路由器打入擁塞標記。文獻[15]提出了結合分離擁塞流和非擁塞流的方法和基于ECN機制的網絡注入抑制策略。文獻[10]中重點對IB網絡中的擁塞控制進行了改進，將擁塞通知改為停止發包指令，源節點的發包重啟動操作由擁塞的目標節點通過特殊的喚醒包Guidance包進行。

文獻[16]注意到ECN無法避免擁塞的產生，結合未來高速互連網絡的發展趨勢，提出了一種基于預約的擁塞避免技術SRP(Speculative Reservation Protocol)，即通過提前預約目的節點的通信資源避免因資源競爭的網絡擁塞。這種方法能夠避免由于目的節點資源競爭引起的擁塞，卻不能解決由于路徑競爭引起的擁塞。文獻[10]則在SRP的基礎上提出了CRP(Channel Reservation Protocol)技術，在預約目的節點資源的同時將關鍵路徑上的路徑資源一起預約，預約的方法能夠避免熱點節點和熱點路徑上產生擁塞，較好地解決了樹飽和效應。

2.2 主動擁塞控制技術

網絡擁塞是一個整體、動態的問題，單純地通過增加硬件資源并不能從根本上解決擁塞問題，有時候增加的網絡資源反而會增加網絡的擁塞程度。主動擁塞控制技術就是基于采用動態方法解決網絡擁塞的思想，提前控制每個報文的傳輸，使得擁塞不可能發生，因此也叫做擁塞避免技術。早期的擁塞避免與應用的通信特征緊密結合，雖然能夠取得較好的優化效果，但針對性強，不是一種普適做法。近些年來，也有一些研究開始嘗試在網絡通信的底層進行主動擁塞控制。

文獻[17]針對胖樹網絡，從交換機的角度降低網絡擁塞，使用IB中的VL(Virtual Lane)降低由于頭堵塞和緩沖阻塞導致的擁塞。文獻[10]中采用了前瞻策略在數據傳輸開始前，將網絡資源規劃分配好，從根本上避免競爭擁塞的發生。這種技術很難適應現代并行計算系統，現在多用于QoS(Quality of Service)[18]。其他的一些可以減緩或推遲擁塞的策略，例如全自適應路由[19]和負載平衡技術[20]，它們根據網絡狀態動態調整路由策略。這些技術能夠推后、延緩擁塞的發生，但不能從根本上避免擁塞發生后的網絡性能下降。

文獻[21]中認為，網絡包的通信環回延遲RTT(Round-Trip Time)的變化非常適合作為網絡擁塞狀態變化的反饋信息，使用RTT作為網絡擁塞狀態的反饋信息具有充分的合理性。基于此理論，研究人員提出了大量基于RTT的擁塞控制協議。TCP Vegas[22]可以根據RTT的變化來判斷網絡的擁塞狀態，受其啟發其他一些基于延遲的擁塞控制算法也相繼被提出來，如FAST TCP[23]、Compound TCP[24]等。文獻[25]中認為如果RTT的反饋時間小于控制執行的延遲，則不可能實現擁塞控制。文獻[7]提出的TIMELY(Transport Informaed by MEasurement of Latenc Y)機制，將長消息進行細粒度分段傳輸，根據每段傳輸延遲對數據注入進行控制，通過分段將通信過程細粒度化。

2.3 擁塞控制技術小結

擁塞的本質是競爭，解決競爭的主要方法是減少對通信熱點的注入，控制擁塞擴散。被動的擁塞控制技術都是基于擁塞已經發生后的補償操作，雖然能夠緩解擁塞程度，但不能避免擁塞的發生。主動擁塞控制技術理論上能夠防止擁塞的發生，但由于網絡擁塞的整體性和動態性的特征，基于資源預分配的技術很難取得預期的效果；一些研究已經表明，RTT能夠反映網絡擁塞狀態，如何能夠根據RTT實時判定網絡狀態還受到一些條件限制，例如RTT的精確性、RTT反饋的粒度以及擁塞控制執行的反應時間等。主動擁塞控制技術的難點和挑戰在于預先發現網絡擁塞狀態，及時啟動擁塞控制措施，解決這兩點對實現高性能互連網絡的擁塞控制具有重要意義。

3 網絡擁塞的模擬與分析

高性能互連網絡屬于無損網絡，沒有復雜的網絡丟包機制，網絡擁塞的發生主要是形成通信熱點導致的。對高性能互連網絡中的通信熱點的形成過程可以推測為：初始時，網絡中路徑空閑，通信資源充足，網絡包傳輸過程中的沖突較少，網絡包傳輸延遲低；隨著網絡注入量的增加，通信競爭增加，資源排隊增多，網絡包傳輸延遲會逐漸遞增，此過程中網絡吞吐率也是處于逐漸遞增的過程；在通信熱點形成后，網絡包的傳輸延遲會繼續增大為一個極大值，網絡吞吐量會下降為一個近似穩定值，這個穩定值的大小取決于通信熱點的處理能力。

本節中，將采用網絡模擬器對無損網絡中通信熱點的通信模式進行模擬，通過對網絡包延遲、網絡吞吐量的變化進行跟蹤記錄，分析網絡擁塞的形成過程。

3.1 網絡拓撲和模擬環境說明

拓撲結構是互連網絡的基礎，直接影響著網絡的性能。文獻[26]中對近些年Top500前10名系統的網絡拓撲結構的統計，高性能計算領域最主要應用的網絡拓撲結構為Torus、Fat-tree、Dragonfly及其變形網絡等。例如，日本的Tofu網絡可以看作是Torus網絡的變形結構，天河一號采用的是Fat-tree網絡的變形網絡[27]，Cray公司的XC30系統采用了Dragonfly網絡結構[28]。按照傳統的計算機網絡分類，Torus和Dragonfly屬于直接網絡，Fat-tree屬于間接網絡[20]。我們選擇Dragonfly作為直接網絡代表，Fat-tree作為間接網絡代表，建立模擬環境進行模擬實驗。

OMNeT++(Objective Modular Network TestBed in C++)是一種優秀的離散事件模擬平臺，近年在學術界和工業領域應用廣泛。OMNeT++具備強大完善的圖形界面接口和可嵌入式模擬內核，可以在多種操作系統上運行，支持層次式開發，可以方便地定義互連網絡拓撲結構和各個模塊的功能。圖1所示為OMNeT++的建模流程示意圖。

Figure 1 Modeling process of OMNeT++圖1 OMNeT++的建模流程

基于OMNeT++4.6版本，開發了一個周期精度的模擬器MESim(Message Engine Simulator with cycle-level accuracy)，MESim中實現了可配置的節點消息引擎模塊MEU(Message Engine Unit)，可以通過參數配置選擇實現不同通信模式的消息，配合網絡拓撲結構配置，實現不同消息機制在不同拓撲結構互連網絡中的模擬。

3.2 傳輸延遲精確測量

傳統基于延遲反饋的擁塞控制機制對網絡包傳輸延遲的精度要求高。TCP協議中網絡包傳輸延遲RTT采用源方軟件時間戳[29]的方式實現，這種方法得到的測量值中包含了很多其他因素，還包含了主機處理的等待時間，某些情況下這些額外的延遲會對延遲測量值產生較大影響，造成不必要的網絡狀態反復誤判。

為了保證網絡包傳輸延遲測量的準確性，一些研究中提出采用硬件精確測量技術。文獻[8,30]中給出了基于網絡接口芯片支持的網絡包傳輸延遲測量方法，不需要軟件的參與。采用硬件時間戳的方法，能夠去除軟件的影響，可以提高延遲測量精度，但測量值中還是包含了響應包的傳輸延遲。

在MESim模擬器中，網絡包控制信息中添加網絡延遲字段。如圖2所示，對路由器模塊進行修改，在路由器的輸入端口和輸出端口之間進行延遲計時，網絡包每經過一級路由器，由路由器將延遲累加到網絡延遲字段中，這樣在目標節點接收到網絡包時，網絡延遲字段中記錄的就是精確的網絡包傳輸延遲。

Figure 2 Structure of router with accumulative transmission delay圖2 累計傳輸延遲的路由器模塊結構

3.3 模擬結果分析

模擬實驗中定義了一種熱點消息模式(hot_node)，即網絡中所有節點集中向網絡中10%的節點發起通信。模擬過程中設定每個網絡包到達目標節點后都能被接收處理，網絡包傳輸延遲定義為從源節點發出網絡包到網絡包到達目標節點的延遲，由3.2節中所述的路由器累計延遲獲得。實驗過程中，MESim按時間段統計每個節點發出的網絡包平均傳輸延遲(avg_delay)、最大傳輸延遲(max_delay)和網絡吞吐量。模擬器的其他配置參數，網絡數據通路位寬32字節，網絡包最大長度2 048字節。

Table 1 Network structure simulation list

圖3為兩種網絡結構、不同網絡規模下熱點通信模擬結果，橫坐標為模擬過程中20個等時間間隔的數據統計時間。左圖為模擬各階段中網絡包最大傳輸延遲與平均傳輸延遲的曲線，中間圖為網絡包最大傳輸延遲對平均傳輸延遲的偏移比例曲線，右圖為各統計時間段內的網絡包吞吐量曲線。

從左側的四個模擬曲線可以看到，隨著網絡通信熱點的逐漸形成，網絡包最大傳輸延遲和平均傳輸延遲都在增加，最大傳輸延遲近似線性的規律逐漸增大，平均傳輸延遲增長速度緩慢一些。右側的吞吐率曲線增長一段時間后基本維持在一個較為穩定的區間范圍，這符合熱點通信形成過程的預期。

中間圖是網絡包最大傳輸延遲相對平均傳輸延遲的偏移量(Deflection)從四個模擬結果圖中都可以發現其曲線走勢與網絡吞吐率非常相似，而且四個曲線都在Deflection曲線達到2之后逐漸趨于穩定。利用這一特征，可以使用網絡包傳輸延遲偏移來預測網絡狀態。

Figure 3 Throughput and delay curves for the four interconnection networks in hot spot communication mode圖3 四種互連網絡熱點通信模式下吞吐率、延遲曲線

4 基于延遲偏移的擁塞控制CMDPD

很多研究都表明，精確的網絡延遲能夠反映出網絡擁塞狀態。從上一小節中的熱點通信模擬結果可以看到，網絡包最大傳輸延遲的偏移曲線Deflection走勢與網絡吞吐量近似。基于這些分析和模擬實驗結果，在通信端的數據傳輸引擎中加入網絡包延遲記錄模塊PDRU(Packet Delay Recoding Unit)，累計網絡包平均傳輸延遲，并計算傳輸延遲偏移量，通過偏移量判定通信目標的擁塞狀態，對網絡注入進行控制，達到網絡擁塞避免的目的。

4.1 數據傳輸引擎結構修改

圖4所示為MESim模擬器中的數據傳輸引擎結構。數據傳輸引擎由發送部件、接收部件兩大部分構成。發送部件將產生、提交的消息拆分為網絡包，提交注入互連網絡；接收部件從互連網絡接收網絡包，然后產生相應的響應包，發送給網絡包來源節點。

對接收部件進行修改，增加網絡包延遲記錄模塊PDRU，PDRU內設置與發送部件內網絡包懸掛個數相同的延遲懸掛，延遲懸掛以全相連方式進行組織管理，每個條目記錄一個目標節點的累計網絡包傳輸延遲。

修改后的數據傳輸引擎工作過程如下:

(1)網絡包發送過程：

①接收到消息傳輸請求，分配網絡包懸掛；

②網絡包懸掛查詢PDRU，獲得發送許可后，提交發包請求；

③網絡包仲裁部件選擇允許發送的網絡包，提交互連網絡。

(2)網絡包接收過程：

①接收部件從互連網絡接收到網絡包；

②產生響應包，攜帶網絡包中的傳輸延遲Tdelay，發送回來源節點。

(3)響應包接收過程：

①從互連網絡接收響應包；

②將響應包中的來源節點號、攜帶的Tdelay提交給PDRU。

Figure 4 Structure of data transmission engine圖4 數據傳輸引擎結構框圖

4.2 網絡注入控制

PDRU接收響應包反饋，對發送部件更新網絡包發送許可信號，通過發送許可信號完成對網絡注入的控制。PDRU內每個延遲懸掛條目的內容如表2所示。

PDRU的核心功能是利用最近返回的網絡包傳輸延遲和已記錄的平均傳輸延遲計算延遲偏移Deflection，根據Deflection更新網絡包發送控制參數，由發送控制參數控制對目標節點的網絡包注入頻率。Loop_cunter是一個循環計數器，每個時鐘節拍累加1，當累加值等于Average_delay*Send_ctrl_para時恢復為0，只有當Loop_cunter為0時才允許向目標節點發送網絡包。

Table 2 Content of delay buffer within PDRU

當PDRU接收一個新的響應包時，其處理過程如下：

(1)根據響應包的來源節點，查找延遲懸掛中的匹配條目；

(2)使用當前響應包中攜帶的傳輸延遲Tdelay和條目中保存的Average_delay計算延遲偏移Deflection；

(3)根據延遲偏移Deflection更新條目Send_ctrl_para；

(4)根據Deflection值，更新All_delay、Packet_num。

第3、4步中兩個內容的更新分離，是考慮到出現個別網絡包的傳輸延遲突然增大的情況，這種突增的延遲值如果不加區分地更新到條目中，對平均傳輸延遲的影響會比較大。因此，PDRU在接收到Deflection值較大的網絡包延遲時，只更新發送控制參數，這樣能夠減少偶發的異常網絡傳輸延遲值的影響范圍。

5 CMDPD的模擬實驗與分析

5.1 模擬實驗說明

如上一節所述原理和結構修改，在MESim模擬器中實現了CMDPD機制。在模擬器中設置了兩個參數init0和init1，參數組合init0-init1作為PDRU對Send_ctrl_para和All_delay、Packet_num內容的更新條件。

(1)當Deflection>init1時，允許更新Send_ctrl_para為Deflection值；

(2)當Deflection

(3)當init0

依然選擇Fat-tree和Dragonfly兩種網絡結構進行模擬。在第3節中的模擬實驗中發現3種規模的Fat-tree的實驗結果趨勢相近，因此實驗中只對256個節點的Fat-tree結構進行模擬。為了更真實地模擬高性能互連網絡的擁塞狀態，除了熱點通信模式外，還選擇all-to-all通信模式和隨機通信模式生成測試激勵，其中all-to-all通信模式采用了兩種算法實現。具體測試激勵說明如表3所示。

5.2 模擬結果與分析

根據前面熱點通信模擬結果，選擇了整數集合{6,8,10,15}和{10,12,14,16,18,20,25,30,35,40}作為init0和init1的實驗參數，對不同的參數組合init0-init1進行實驗。實驗中固定運行100萬拍，MESim模擬器記錄網絡整體的網絡包吞吐量，并統計網絡包的最大傳輸延遲和平均傳輸延遲，最后通過比較不同參數組合下的統計數據分析實驗結果。

Table 3 Description of the test items for the simulation

Figure 5 Throughput comparison for CMDPD圖5 CMDPD模擬吞吐量對比

圖5所示為CMDPD不同init0-init1參數下的吞吐量模擬結果柱形圖，“基準”內容為沒有采用CMDPD的對比模擬結果。

在Fat-tree網絡中，除了hot_node模式外，其他通信模式下采用CMDPD之后，網絡的吞吐量都有提高，其中alltoall_round_robin通信模式的吞吐量提高10%～12%，uniform_random平均提高5.5%，uniform_random_seq_gen平均提高6%。在hot_node模式下，由于通信目標點較為集中，CMDPD的控制機制雖然反映時間短，但盡管采用了切換通信目標的流控方式，還是不能對這種過于集中的通信發揮有效控制，反映在模擬結果中，則表現為不同參數組合下的吞吐量變化較大。

Figure 6 Comparison of average delay of network packets for CMDPD圖6 CMDPD模擬網絡包平均延遲結果對比

在Dragonfly網絡中，hot_node和uniform_random兩種通信模式中，有組合參數下出現了吞吐量降低的情況，uniform_random_seq_gen通信模式下結果基本沒有變化，alltoall_round_robin通信模式的網絡吞吐量提高比例在4%以內。這個結果反映了CMDPD機制對不同網絡拓撲的適應性是不同的，與Fat-tree網絡相比，Dragonfly網絡利用高階路由器的多端口降低了網絡直徑，網絡路徑上跳步減少，排隊競爭引起的網絡傳輸延遲偏移相對較小，CMDPD機制發揮作用的余地較小。

除了統計網絡的吞吐量，模擬過程中以時間段為單位，對網絡包的平均傳輸延遲進行了統計。如圖6所示為模擬實驗中對網絡包平均傳輸延遲的結果對比曲線，其中橫坐標為模擬過程中10個等時間間隔的統計時機。

在Fat-tree網絡中，hot_node和alltoall_round_robin通信模式下，采用CMDPD控制機制后，網絡包平均傳輸延遲變化幅度較大；uniform_random和uniform_random_seq_gen通信模式中，采用CMDPD后平均網絡傳輸延遲相比“基準”降低10%～20%。

在Dragonfly網絡中，四種通信模式下，采用CMDPD后的網絡包平均傳輸延遲沒有較大變化，走向趨勢也基本相同。這個結果可以與上面的吞吐率測試結果相互印證，即CMDPD對Dragonfly網絡結構適應性不如對Fat-tree網絡，但測試結果表明CMDPD機制沒有對網絡包的傳輸延遲產生負面影響。

6 結束語

本文對高性能互連網絡中的擁塞控制進行了研究，針對高性能互連網絡中的通信熱點問題，提出了一種基于網絡包延遲偏差的硬件擁塞控制機制CMDPD，在通信端進行注入控制。基于OMNet++平臺構建網絡模擬器，在Fat-tree網絡和Dragonfly網絡中對CMDPD進行了模擬。實驗結果表明，Fat-tree網絡中CMDPD的網絡吞吐量提高5%～12%，在Dragonfly網絡中CMDPD的效果不明顯；兩種網絡結構下，采用CMDPD后的網絡包平均傳輸延遲沒有明顯增加。實驗結果表明，CMDPD在網絡包級進行網絡狀態判斷和擁塞控制，對提高網絡吞吐率有一定效果，沒有對網絡延遲造成負面影響。

本文實現的CMDPD擁塞控制機制，首次在網絡包級由硬件進行注入控制，機制反饋迅速，不會影響更高層級的擁塞控制實現，但延遲偏差控制還是基于外部配置，未來研究工作可向自動控制方向做擴展研究。

[1] Lucas R, Ang J,Bergman K,et al.DOE advanced scientific computing advisory subcommittee (ASCAC) report:Top ten exascale research challenges[R].United States:ASCA,2014-02-10.

[2] Association I B T.InfiniBand architecture specification:Release 1.0[EB/OL].[2000-12-10]. http://www.infinibandta.com/.

[3] InfiniBand Trade Association Std.:InfiniBand architecture specification,Vol.1:Rel.1.2.1[S].InfiniBand Trade Association Std,2007.

[4] Thottethodi M,Lebeck A R,Mukherjee S S.Self-tuned congestion control for multiprocessor networks[C]∥Proc of International Symposium on High-Performance Computer Architecture,2001:107.

[5] Baydal E,López P,Duato J.A congestion control mechanism for wormhole networks[C]∥Proc of the 9th Euromicro Workshop on Parallel and Distributed Processing,2001:19-26.

[6] Baydal E,López P.A robust mechanism for congestion control:INC[C]∥Proc of European Conference on Parallel Processing,2003:958-968.

[7] Mittal R,Lam V T,Dukkipati N,et al.TIMELY:RTT-based congestion control for the datacenter [J].ACM SIGCOMM Computer Communication Review,2015,45(5):537-550.

[8] Using hardware timestamps with PF RING[EB/OL].[2011-11-16].http://goo.gl/oJtHCe.

[9] Wei X,Cheng J,Li H.Latency-balanced optimization of MPI collective communication across multi-clusters[C]∥Proc of Chinagrid Conference,2013:9-13.

[10] Michelogiannakis G,Jiang N,Becker D,et al.Channel reservation protocol for over-subscribed channels and destinations[C]∥Proc of the International Conference on High Performance Computing,Networking,Storage and Analysis,2013:52.

[11] Floyd S.TCP and explicit congestion notification [J].ACM SIGCOMM Computer Communication Review,1994,24(5):8-23.

[12] Turner Y, Santos J R,Janakiraman G J.An approach for congestion control in InfiniBand:HPL-2001-277R1[J].Palo Alto:HP Laboratories Palo Alto,Internet Systems and Storage Laboratory,2001.

[13] Santos J R,Turner Y,Janakiraman G.End-to-end congestion control for Infiniband[C]∥Proc of the 22nd Annual Joint Conference of the IEEE Computer and Communications,2003:1123-1133.

[14] Ferrer J L L,Baydal E,Robles A,et al.Congestion management in mins through marked and validated packets[C]∥Proc of the 15th Euromicro International Conference on Parallel,Distributed and Network-Based,2007:254-261.

[15] Duato J,Johnson I,Flich J,et al.A new scalable and cost-effective congestion management strategy for lossless multistage interconnection networks[C]∥Proc of the 11th International Conference on High-Performance Computer Architecture,2005:108-119.

[16] Jiang N, Becker D U,Michelogiannakis G,et al.Network congestion avoidance through speculative reservation[C]∥Proc of 2012 IEEE 18th International Symposium on High Performance Computer Architecture,2012:1-12.

[17] Escudero-Sahuquillo J,Garcia P J,Quiles F J,et al.A new proposal to deal with congestion in InfiniBand-based fat-trees[J].Journal of Parallel & Distributed Computing,2014,74(1):1802-1819.

[18] Kandula S,Padhye J,Bahl V.Flyways to DeCongest data center networks[C]∥Proc of the 8th ACM Workshop on Hot Topics in Networks,2009:1.

[19] Kim J,Dally W J,Abts D.Flattened butterfly:A cost-efficient topology for high-radix networks[J].ACM SIGARCH Computer Architecture News,2007,35(2):126-137.

[20] Kim J,Dally W J,Towles B,et al.Microarchitecture of a high-radix router[J].ACM SIGARCH Computer Architecture News,2005,33(2):420-431.

[21] Grigorik I. Optimizing the critical rendering[EB/OL].[2013-11-16].http://goo.gl/DvFfGo.

[22] Gran E G,Reinemo S A,Lysne O,et al.Exploring the scope of the InfiniBand congestion control mechanism[C]∥Proc of Parallel & Distributed Processing Symposium,2012:1131-1143.

[23] Jin C,Wei D X,Low S H.FAST TCP:Motivation,architecture,algorithms,performance[C]∥Proc of Joint Conference of the IEEE Computer and Communications Societies,2004:2490-2501.

[24] Tan K,Song J,Zhang Q,et al.A compound TCP approach for high-speed and long distance networks[C]∥Proc of IEEE International Conference on Computer Communications,2006:1-12.

[25] Kelly F,Raina G,Voice T.Stability and fairness of explicit congestion control with small buffers[J].ACM SIGCOMM Computer Communication Review,2008,38(3):51-62.

[26] Trobec R,Vasiljevic R,Tomasevic M,et al.Interconnection networks in petascale computer systems:A Survey[J].ACM Computing Surveys (CSUR),2016,49(3):Article 44.

[27] Yang X,Liao X,Lu K,et al.The Tianhe-1A supercomputer：Its hardware and software [J]．Journal of Computer Science and Technology,2011,26(3)：344-351．

[28] Dally W J,Towles B.Principles and practices of interconnection networks[M].San Mato:Morgan Kaufmann Publishers,2004.

[29] Dual port 10 gigabit server adapter with precision time stamping[EB/OL].[2016-10-15].http://goo.gl/VtL5oO.

[30] Mellanox for Linux[EB/OL].[2016-10-15].http://goo.gl/u44Xea.