分析核親和性對高吞吐量的流的影響

分析核親和性對高吞吐量的流的影響

本文翻譯自Analysis of the Effect of Core Affinity on High-Throughput Flows

簡介

網絡吞吐量正在朝更高的數據傳輸率發展，與此同時，終端系統的處理器也在朝着多核發展。爲了在多核終端系統上優化高速數據傳輸，像網絡適配器卸載以及性能調優等技術已經受到了普遍的關注。此外，已經出現了一些多線程網絡接收處理的方法。但對於如何調參，以及使用哪一個卸載才能達到更高的性能的關注度遠遠不夠，並且對於爲何這麼設定的理解也遠遠不足。本論文會結合前人的研究成果來跟蹤高速TCP流下，終端系統出現性能瓶頸的源頭。 出於本論文的目的，咱們認爲協議處理效率是指實現每單位(以Gbps爲單位)吞吐量所消耗的系統資源(例如CPU和緩存)，並使用低級系統事件計數器測量消耗的各類系統資源的總量。親和性或核綁定用於決定終端系統上負責處理中斷，網絡和應用的處理核。咱們得出親和性對協議處理的效率會產生相當重要的影響，三種不一樣的親和性方案下網絡接收處理的性能瓶頸會發生急劇變化。

介紹

因爲多種物理限制，處理器內核達到了時鐘速度的「極限」，此時CPU時鐘頻率將沒法增長。而另外一方面，光纖網絡中的數據速率卻在不斷提升，更好的光學和精密設備改善了散射，吸取和離散的物理事實[1]。儘管物理層取得了這些進步，但咱們仍然受到用於協議處理的系統軟件層面的限制。所以，爲了提升應用層的網絡吞吐量，高效的協議處理和適當的系統層面的調優是必要的。

TCP是一種可靠的，面向鏈接的協議，它會保證發送者到接收者之間的數據的順序，這樣作會將大部分協議處理推到終端系統上。實現TCP協議的功能須要必定程度的複雜性，由於它是一個端到端協議，所以全部功能都須要在端系統中進行檢測。這樣，提高現有TCP實現效率的途徑分爲兩類：首先，使用卸載嘗試將TCP功能放到協議棧之下，以此來達到更好的傳輸層效率；其次，經過調參，但這些參數會給上層(軟件，系統和系統管理)帶來複雜性。

調參主要關注親和性。親和性(或核綁定)從根本上說是關於在網絡多處理器系統中的哪一個處理器上使用哪些資源的決定。Linux網絡接收處理消息在現代系統上主要有兩種實現方式：首先經過中斷處理(一般會聯合處理)，一旦NIC接收到特定數量的報文後，就會向處理器發起中斷，而後NIC會經過DMA將報文傳輸處處理器(應該是先將報文放到DMA，而後再向處理器發起中斷)，隨後NIC驅動核OS內核會繼續協議處理，直到給應用準備好數據；其次，經過NIC輪詢(在Linux中稱爲NEW API，NAPI)，這種方式下，內核會輪詢NIC來檢查是否有須要接收的網絡數據，若是存在，則內核將根據傳輸層協議處理數據，以便根據socketAPI將數據將數據傳遞給應用程序。不論哪一種方式，都存在兩類親和性：1)流親和性，用於肯定那個核將會中斷處理網絡流；2)應用親和性，用於肯定哪一個核會執行接收網絡數據的應用進程。流親和性經過/proc/irq//smp affinity中的十六進制核描述符進行設置，而應用親和性能夠經過taskset或相似的工具進行設置。所以一個12核的終端系統，存在144種(12^2)可能的流和應用親和性。

在本論文中，咱們將經過詳細的實驗擴展先前的工做[3]，[4]，使用單個高速TCP流對每一個親和性組合進行壓力測試。咱們會使用終端系統的性能內省來理解選擇的親和性對接收系統效率的影響。咱們能夠得出有三種不一樣的親和性場景，且每種場景下的性能瓶頸差別很大。

相關工做

目前已有多項研究評估了多核系統中的網絡I/O性能[5]–[8]。當前內核中一個主要的提高是默認啓用NAPI [9]。NAPI用於解決接收活鎖問題[8]，即CPU消耗大量週期來處理中斷。當一個機器進入活鎖狀態時，因爲大部分的CPU週期用於處理硬中斷和軟中斷上下文，它會丟棄報文。啓用了NAPI的內核會在高速率下切換到輪詢模式來節省CPU週期，而不依賴純中斷驅動模式。10 Gbps WAN上的報文丟失和性能說明能夠參見[10],[11]。[12]更多關注延遲的架構來源，而不是基礎數據中心的連接。改善終端系統瓶頸不利影響的另外一個方面涉及從新考慮終端系統的硬件架構。傳輸友好的NIC，以及新的服務器架構能夠參見[12]，[14]。不幸的是，這些戲劇性的變化不多能用於已部署的、用於測試目的的商品終端系統類型。

Linux網絡性能調優選項

現代NIC支持多接收和傳輸描述符隊列。NIC使用過濾器將報文發送到不一樣的隊列，以此來在多個核上分擔負載。啓用Receive-Side Scaling (RSS) [15]後，不一樣流的報文會發送到不一樣的接收隊列，並由不一樣的CPU處理。RSS須要NIC的支持。Receive Packet Steering (RPS) [16]是RSS的內核軟件版本。它會爲接收的報文集選擇CPU核來執行協議處理。Receive Flow Steering (RFS) [17]與RPS相似，但它會使用TCP四元組來保證一條流上全部的報文會進行相同的隊列和核。全部這些擴展技術目的都是爲了提高多核系統的總體性能。

當執行網絡處理[6]時，一般明智的作法是選擇共享相同的最低緩存結構的核[18]。例如，當一個給定的核(如核A)被選擇來執行協議/中斷處理時，與核A共享L2緩存的核應該執行相應的用戶應用程序。這樣作會減小上下文切換，提高緩存性能，最終增長整體吞吐量。

Irqbalance守護進程會執行輪詢調度來在多核上進行中斷的負載均衡。但它也會形成負面影響，見[19], [20]。咱們須要更明智的方法，並且須要控制選擇處理中斷的核。在咱們的實驗中禁用了irqbalance守護進程。

暫停幀[21]能夠容許以太網經過流控制阻止TCP，所以，當僅須要在路由器或交換機上進行臨時緩衝時，能夠避免TCP窗口的倍數減少(避免)。爲了實現該功能，支持暫停幀的以太網設備會在每一個鏈路中使用閉環過程，在這種鏈路中，發送設備知道須要緩衝幀的傳輸，直到接收器可以處理它們爲止。

巨幀(Jumbo Frames)僅僅是個以太幀，但它的長度遠大於IEEE標準的1500字節的MTU。在大多數場景下，當使用Gigabit以太網時，幀的大小能夠達到9000字節，這樣作能夠經過增長增長有效負載與幀頭大小的比率來得到更好的協議效率。雖然以太速度從40Gbps提高到了100Gbps，但9000字節的幀大小的標準並無發送變化 [22]。緣由是因爲存在各類分段卸載(segmentation offloads)。Large/Generic Segment Offload (LSO/GSO) 和Large/Generic Receive Offload (LRO/GRO)與當代路由器和交換機中的以太網實現相結合，來在當條TCP流上發送和接收很是大的幀，這種方式下惟一的限制因素是協商的傳輸速率和錯誤率。

數據轉移技術

本研究不會直接關注如何在長距離上移動大量數據，一些終端系統應用程序已經實現了多種方式，這些方式有助於有效地利用TCP [23]–[26]。這些成熟應用背後的整體思路是使用多條TCP流來處理應用層的傳輸，並將這些流的處理和重組分配給多個處理器[27]–[29]。大部分這些應用一樣可以利用基於UDP的傳輸層協議，如RBUDP [30] 和UDT [31]。

目前已經有不少協議專門用於在封閉的網絡(在數據中心內或數據中心之間)中快速可靠地轉移大量數據。最近，這些協議專一於如何將數據從一個系統的一塊內存直接轉移到另外一塊內存中，兩個例子是RDMA [32] 和 InfiniBand [33]。這些協議的共同點是它們依賴於終端系統之間相對複雜，健壯和可靠的中間網絡設備。

之前，咱們研究了親和性對終端系統性能瓶頸的影響 [3]，並得出親和性對端到端系統的高速流的影響巨大。此研究並無深究不一樣親和性場景下終端性能瓶頸發生的位置，目標是肯定這些親和性場景下的性能瓶頸發生在哪裏，並評估新的Linux內核(前面使用的是Linux 2.6版本的內核)是否解決了這些問題。

實驗設置

各類NIC卸載提供了不少有用的參數。NIC廠商一般會提供一些建議來指導用戶如何調節系統，以充分利用其高性能硬件。[34]提供了寶貴的Linux調參資源，這些資源是經過在ESnet的100 Gbps測試平臺上進行仔細的實驗得到的。ESnet提供了不少演示文稿，詳細介紹了實驗中得到的調優建議，但不多有經驗證實這些調優建議和卸載的原理。

本論文中，咱們將提供多線程協議處理，或將協議處理推送到協議棧的不一樣組件中。咱們將努力證實參考空間局部性在終端系統中跨多條流的數據流處理中的重要性。所以，這些實驗中引入了iperf3 [35] 來經過單條高速TCP流來進行壓力測試，該測試會使流量達到終端系統的網絡I/O上限。注意，這並非一個實際案例，實踐中，如GridFTP [23] 這樣的應用會經過多條流來達到更快的傳輸速率，性能也更加可預測，但在實踐中應謹慎使用這種工具(尤爲使在長距離移動大量數據時)。但理解終端系統中數據傳輸的限制很是重要(最好只用一個流便可完成)。

爲此，咱們引入了兩臺服務器，鏈接延遲< 1ms RTT，與咱們以前使用ESnet Testbed的95ms RTT光纖環路進行的實驗[3]相反。循環測試能夠有效地觀測長距離下TCP帶寬的行爲，咱們的目標是進行壓力測試，而後分析接收端的性能效率。

本實驗中的系統都運行在Fedora Core 20上，內核爲3.13。使用最新內核的緣由是，假設該內核已經引入了最新的網絡設計。

用於生成TCP流的應用爲iperf3。爲了確保將壓力施加在終端系統上，傳輸使用了零拷貝模式(使用TCP sendfile系統調用來避免沒必要要的拷貝以及防止耗盡發送端系統的內存)。

被測試的系統是根據ESnet數據傳輸節點（DTN）的原型建模的。這類系統的目的是做爲一箇中間人，將大量數據從高性能計算機(HPCs)傳輸到消耗數據的中的終端系統上。實踐中，這類系統必須可以經過InfiniBand主機總線適配器儘量快地接收大量數據，而後將數據傳輸到本地磁盤或大規格的本地內存中，而後在高速(100 Gbps)WAN上向接收系統提供數據。它們使用了鏈接到Intel Sandy Bridge處理器的PCI-Express Generation 3。每一個終端系統有兩個六核處理器。因爲Sandy Bridge的設計，特定的PCI-Express槽會在物理上直接鏈接到一個單獨的socket(即CPU插槽，可使用lscpu命令查看)。能夠經過Quick Path Interconnect（QPI）提供的低級socket間的通訊來克服此限制。圖1站展現了該架構：

測試平臺選用的是ESnet 100 Gbps 測試平臺[37]，它鏈接了(專門用於跨洲的)100 Gbps網絡上的各類基於商用硬件的終端系統。該測試平臺開放給了全部研究員，並提供了除了產生重複結果外的其餘好處，由於整個測試牀都是可保留的。這樣就保證了不會存在競爭的流量。出於實驗目的，須要在終端系統上測試性能瓶頸，而不是網絡上。

Linux下圖分析器使用的是Oprofile。Oprofile爲Linux提供了輕量且高度內省的對系統硬件計數器[38]的監控功能。Oprofile的新工具ocount 和operf用於監控接收系統上的各類事件的計數器。在這些實驗中，因爲須要監視的接收者可能會超額，所以Oprofile的低開銷和詳細的Linux內核自檢的能力是相當重要的。經過自省能夠有效地測量operf的開銷，而且發現該開銷始終比受監視過程的計數結果至少小一個數量級。因爲可用的計數器數量和自省功能，在這些實驗中，Oprofile被選爲英特爾的性能計數器監視器(PCM)。PCM還能夠報告功耗，在將來的測試中可能會有用。

下面是實驗中使用的自變量：

• 流親和性：0~11核
• 應用親和性：0~11核
• 測試總次數：12x12=144

下面是實驗中使用的因變量：

• 吞吐量
• 指令退出數(系統範圍以及內核和用戶進程的自省)
• 最後一級緩存引用(系統範圍以及自省)
• L2緩存訪問
• 重試的內存事務
• 脫機請求

表1展現了實驗環境的概況。發送和接收端系統的配置相同。

實驗方法

在執行144次實驗前，都會運行一個腳原本檢查系統的網絡設定和調參，保證後續的實驗的一致性。系統使用了ESnet的調參建議，保證TCP的高性能。而後進行初步測試，以確保沒有異常會致使可變的帶寬結果。發送系統設置爲最佳親和配置，且不會更改其親和設置。在發送端會啓動一個iperf3服務器，並放在那裏運行。而後在接收端，使用嵌套的for循環shell腳本修改了設置全部rx隊列的中斷(/proc/irq/<irq#)設置到對應的/smp_affinity配置文件中，這樣全部接收隊列中的報文都會發往相同的核。內部for循環會在執行iperf3反向TCP零拷貝測試時運行operf，將接收者綁定到一個給定的核，並報告結果。經過這種方式來測試流和應用親和性的全部組合。屢次運行實驗來保證結果的一致性。

結果

咱們如今核以前的工做[3]得出存在三種不一樣的性能類型，對應以下親和性場景：1）相同的socket，相同的核(即流和應用都綁定到相同的核)，這種狀況下，吞吐量能夠達到20Gbps；2）不一樣的socket(不一樣的核)能夠達到的吞吐量爲28Gbps；3）相同的socket，不一樣的核，吞吐量能夠達到39Gbps。雖然變動了OS(從運行2.6內核的CentOS換到了運行3.13內核的Fedora)，並更新了NIC驅動後的總體性能獲得了提高，但三種親和性設定下的相對性能並無變化。

能夠看到相同的socket，不一樣的核的吞吐量最大，緣由是相同的socket使得緩存查詢效率比較高，不一樣的核減小了中斷上下文切換形成的性能損耗。所以將處理報文和應用放到相同的核上並不老是正確的，雖然提升緩存命中率，但有可能增長了中斷上下文形成的損耗。

咱們之前的工做代表，在系統級上超額的接收者的低吞吐量與緩存未命中之間存在關聯。本次實驗也會採納這種觀點，使用ocount來監控系統級別的硬件計數器，並使用operf來進行內核自省，以仔細檢查接收者的性能瓶頸的根源。

上圖展現了144次實驗結果，空心圓表示NIC給出的速率(見表1)，填充的藍色表示實際測量到的吞吐量，填充越多，表示實際吞吐量越大。

這個結論與上面給出的相同，左下角和右上角象限中的吞吐量最大，此時應用和流的親和到相同的socket，但不一樣的核。

結果分析

爲了高效地傳達144個測試的結果，咱們使用了圖2中的矩陣。Y軸表示應用親和的核，數字0到11表示物理核。所以核0到5位於socket0，核6到11位於socket1(見圖1)。上數矩陣有兩個重要屬性：

1. 圖2中的對角線表示應用和流使用親和到相同的核
2. 圖表能夠按象限查看，每一個象限表明與兩個socket相關的可能的親和性組合之一。即，全部大於5的應用親和核，且小於6的流親和核表示應用親和到socket1，流親和到socket0，等。

總體的流和應用的處理效率

在後面的圖中咱們引入了Oprofile硬件計數器結果。當解釋結果時，須要注意硬件計數器自己攜帶了一些信息。例如，能夠簡單地查看iperf3傳輸過程當中退出的指令總數，但這並不包含實際傳輸的數據量。這樣作的目的是爲了查看效率，所以使用退出的指令數除以傳輸吞吐量(Gbps)做爲結果。 因爲每一個測試的長度是相同，所以能夠對結果進行歸一化。

圖3展現了每秒每GB的數據傳輸下退出的指令數。本圖中的對角線展現了(當流和應用都親和到相同的核時)處理效率低下。這種場景下，不只僅吞吐量很低(見圖2)，並且處理效率也遠遠低於其餘場景。在流親和到socket0，應用親和到socket1的狀況下，須要在socket0和socket1之間經過更多的指令來移動數據。

144次測試的處理效率，圓越大表示處理效率越低。

從圖3能夠看出緩存位置對緩存指令數的影響。距離越遠，命中率約低，搜索量越大，致使須要的指令越多。

存儲層次結構

在上面提到的對角線場景中，用戶的副本數決定了終端系統消耗的資源。從系統角度看，大量用於訪問內存層次結構的指令偏偏證實了這一點(見圖4，5，6)。主要注意的是這些圖的標題進行了簡化(具體意義參看法析)。此外，因爲原始的計數器輸出在此處的意義不大，所以使用了計數器的數據除以指令退出/吞吐量做爲結果(圖3)。

在應用和流親和到不一樣核但相同socket的場景下，內存層級結構的事務彷佛主導了主要的退出指令數。但這種狀況下的傳輸接近線性，所以內存層次結構並不像是真正的瓶頸。通過初步分析，發現對於流和應用位於不一樣socket的場景，瓶頸多是因爲LOCK前綴引發的，由於使用方正在等待緩存一致性。

然而，對於應用和流親和到不一樣socket的場景，只有很是少的一部分指令會用於內存層次結構的事務，儘管事實上用戶副本會繼續主導CPU消耗。這種狀況下使用了不少計數器來監控並分析可能的瓶頸，包括硬件中斷和因爲LOCK前綴形成的CPU週期浪費，但都沒有展示出與該親和場景的關聯性。

用於L2高速緩存事務中的已退出指令/吞吐量的比例，能夠看出相同socket，但不一樣core的緩存命中率相對較高。

用最後一級高速緩存事務中的已退出指令/吞吐量的比例

NIC驅動的CPU利用率瓶頸

有趣的是，在本對角線場景下，與內存層次結構相關的事務僅佔了總體退出指令數的很小一部分。這種狀況下，內省顯示NIC驅動(mlx4 en)是主要的系統資源消耗者。未來會使用驅動程序自省調查這種狀況下瓶頸的確切來源。

用於內存事務處理中的已退出指令/吞吐量的比例

結論和後續工做

本論文最重要的結論之一是系統內和系統間通訊間的時鐘速度壁壘的界線正在迅速模糊。當一個處理器核和另一個核進行通訊時，數據須要在系統(芯片)網絡間進行傳輸。爲了實現大規模數據複製和一致性，必須在WAN上進行數據的傳輸。那麼這些網絡有什麼不一樣？WAN上對數據傳輸性能的影響正在持續變小，且網絡也正在變得愈來愈可靠，愈來愈可重配置。同時，系統間的網絡也變得愈來愈複雜(因爲橫向擴展系統和虛擬化)，且有可能下降了可靠性(如因爲節能有時須要下降芯片的某些部分或徹底關閉它們的部分)。當討論到親和性，除了這些變化外，仍然須要關注其距離，本地性(不管網絡的大小)。將來，最有效的解決方案可能不只僅是將NIC集成處處理器芯片上[14]，甚至有可能集成現有的I/O結構的功能，如北向橋。然而，這些可行性可能須要不少年纔可以實現。

本研究給出了更確切的結論，即須要謹慎往一個芯片上添加更多的組件，這樣有可能致使跨socket的性能變低。這些結論爲以終端系統爲主的吞吐量和延遲測試提供了重要的背景：在高吞吐量，高性能硬件上，端到端的TCP流的體系結構延遲源可能會發生巨大變化。

同時，也可使用相同的方式來測試其餘NIC和其餘NIC驅動，看是否可以得出相似的結論。最近，中斷合併和在NAPI之間自動切換的NIC驅動程序也正在研究中。此外，也在調研多流TCP和UDT GridFTP傳輸。將來的目標是實現一個輕量級中間件工具，該工具能夠在更大程度上優化親和性，並擴展已在緩存感知的親和性守護程序[18]上的工做。

引用

[1] G. Keiser, Optical Fiber Communications. John Wiley & Sons, Inc., 2003.

[2] C. Benvenuti, Understanding Linux Network Internals. O’Reilly Media, 2005.

[3] N. Hanford, V. Ahuja, M. Balman, M. K. Farrens, D. Ghosal, E. Pouyoul, and B. Tierney, 「Characterizing the impact of end-system affinities on the end-to-end performance of high-speed flows,」 in Proceedings of the Third International Workshop on Network-Aware Data Management, NDM ’13, (New York, NY, USA), pp. 1:1–1:10, ACM, 2013.

[4] N. Hanford, V. Ahuja, M. Balman, M. K. Farrens, D. Ghosal, E. Pouyoul, and B. Tierney, 「Impact of the end-system and affinities on the throughput of high-speed flows.」 poster - Proceedings of The Tenth ACM/IEEE Symposium on Architectures for Networking and Communications Systems (ANCS) ANCS14, 2014.

[5] A. Pande and J. Zambreno, 「Efficient translation of algorithmic kernels on large-scale multi-cores,」 in Computational Science and Engineering, 2009. CSE’09. International Conference on, vol. 2, pp. 915–920, IEEE, 2009.

[6] A. Foong, J. Fung, and D. Newell, 「An in-depth analysis of the impact of processor affinity on network performance,」 in Networks, 2004. (ICON 2004). Proceedings. 12th IEEE International Conference on, vol. 1, pp. 244–250 vol.1, Nov 2004.

[7] M. Faulkner, A. Brampton, and S. Pink, 「Evaluating the performance of network protocol processing on multi-core systems,」 in Advanced Information Networking and Applications, 2009. AINA ’09. International Conference on, pp. 16–23, May 2009.

[8] J. Mogul and K. Ramakrishnan, 「Eliminating receive livelock in an interrupt-driven kernel,」 ACM Transactions on Computer Systems (TOCS), vol. 15, no. 3, pp. 217–252, 1997.

[9] J. Salim, 「When napi comes to town,」 in Linux 2005 Conf, 2005.

[10] T. Marian, D. Freedman, K. Birman, and H. Weatherspoon, 「Empirical characterization of uncongested optical lambda networks and 10gbe commodity endpoints,」 in Dependable Systems and Networks (DSN), 2010 IEEE/IFIP International Conference on, pp. 575–584, IEEE, 2010.

[11] T. Marian, Operating systems abstractions for software packet processing in datacenters. PhD thesis, Cornell University, 2011.

[12] S. Larsen, P. Sarangam, R. Huggahalli, and S. Kulkarni, 「Architectural breakdown of end-to-end latency in a tcp/ip network,」 International Journal of Parallel Programming, vol. 37, no. 6, pp. 556–571, 2009.

[13] W. Wu, P. DeMar, and M. Crawford, 「A transport-friendly nic for multicore/multiprocessor systems,」 Parallel and Distributed Systems, IEEE Transactions on, vol. 23, no. 4, pp. 607–615, 2012.

[14] G. Liao, X. Zhu, and L. Bhuyan, 「A new server i/o architecture for high speed networks,」 in High Performance Computer Architecture (HPCA), 2011 IEEE 17th International Symposium on, pp. 255–265, IEEE, 2011.

[15] S. Networking, 「Eliminating the receive processing bottleneckintroducing rss,」 Microsoft WinHEC (April 2004), 2004.

[16] T. Herbert, 「rps: receive packet steering, september 2010.」 http://lwn. net/Articles/361440/. [17] T. Herbert, 「rfs: receive flow steering, september 2010.」 http://lwn.net/ Articles/381955/. [18] V. Ahuja, M. Farrens, and D. Ghosal, 「Cache-aware affinitization on commodity multicores for high-speed network flows,」 in Proceedings of the eighth ACM/IEEE symposium on Architectures for networking and communications systems, pp. 39–48, ACM, 2012.

[19] A. Foong, J. Fung, D. Newell, S. Abraham, P. Irelan, and A. LopezEstrada, 「Architectural characterization of processor affinity in network processing,」 in Performance Analysis of Systems and Software, 2005. ISPASS 2005. IEEE International Symposium on, pp. 207–218, IEEE, 2005.

[20] G. Narayanaswamy, P. Balaji, and W. Feng, 「Impact of network sharing in multi-core architectures,」 in Computer Communications and Networks, 2008. ICCCN’08. Proceedings of 17th International Conference on, pp. 1–6, IEEE, 2008.

[21] B. Weller and S. Simon, 「Closed loop method and apparatus for throttling the transmit rate of an ethernet media access controller,」 Aug. 26 2008. US Patent 7,417,949.

[22] M. Mathis, 「Raising the internet mtu,」 http://www.psc.edu/mathis/MTU, 2009.

[23] W. Allcock, J. Bresnahan, R. Kettimuthu, M. Link, C. Dumitrescu, I. Raicu, and I. Foster, 「The globus striped gridftp framework and server,」 in Proceedings of the 2005 ACM/IEEE conference on Supercomputing, p. 54, IEEE Computer Society, 2005.

[24] S. Han, S. Marshall, B.-G. Chun, and S. Ratnasamy, 「Megapipe: A new programming interface for scalable network i/o.,」 in OSDI, pp. 135–148, 2012.

[25] M. Balman and T. Kosar, 「Data scheduling for large scale distributed applications,」 in Proceedings of the 9th International Conference on Enterprise Information Systems Doctoral Symposium (DCEIS 2007), DCEIS 2007, 2007.

[26] M. Balman, Data Placement in Distributed Systems: Failure Awareness and Dynamic Adaptation in Data Scheduling. VDM Verlag, 2009.

[27] M. Balman and T. Kosar, 「Dynamic adaptation of parallelism level in data transfer scheduling,」 in Complex, Intelligent and Software Intensive Systems, 2009. CISIS ’09. International Conference on, pp. 872–877, March 2009.

[28] M. Balman, E. Pouyoul, Y. Yao, E. W. Bethel, B. Loring, M. Prabhat, J. Shalf, A. Sim, and B. L. Tierney, 「Experiences with 100gbps network applications,」 in Proceedings of the Fifth International Workshop on Data-Intensive Distributed Computing, DIDC ’12, (New York, NY, USA), pp. 33–42, ACM, 2012.

[29] M. Balman, 「Memznet: Memory-mapped zero-copy network channel for moving large datasets over 100gbps network,」 in Proceedings of the 2012 SC Companion: High Performance Computing, Networking Storage and Analysis, SCC ’12, IEEE Computer Society, 2012.

[30] E. He, J. Leigh, O. Yu, and T. Defanti, 「Reliable blast udp : predictable high performance bulk data transfer,」 in Cluster Computing, 2002. Proceedings. 2002 IEEE International Conference on, pp. 317 – 324, 2002.

[31] Y. Gu and R. L. Grossman, 「Udt: Udp-based data transfer for high-speed wide area networks,」 Computer Networks, vol. 51, no. 7, pp. 1777 – 1799, 2007. Protocols for Fast, Long-Distance Networks.

[32] R. Recio, P. Culley, D. Garcia, J. Hilland, and B. Metzler, 「An rdma protocol specification,」 tech. rep., IETF Internet-draft draft-ietf-rddprdmap-03. txt (work in progress), 2005.

[33] I. T. Association et al., InfiniBand Architecture Specification: Release 1.0. InfiniBand Trade Association, 2000.

[34] ESnet, 「Linux tuning, http://fasterdata.es.net/host-tuning/linux.」

[35] ESnet, 「iperf3, http://fasterdata.es.net/performance-testing/ network-troubleshooting-tools/iperf-and-iperf3/.」

[36] E. Dart, L. Rotman, B. Tierney, M. Hester, and J. Zurawski, 「The science dmz: A network design pattern for data-intensive science,」 in Proceedings of the International Conference on High Performance Computing, Networking, Storage and Analysis, SC ’13, (New York, NY, USA), pp. 85:1–85:10, ACM, 2013.

[37] 「Esnet 100gbps testbed.」 http://www.es.net/RandD/100g-testbed.

[38] J. Levon and P. Elie, 「Oprofile: A system profiler for linux.」 http:// oprofile.sf.net, 2004.