分析核親和性對高吞吐量的流的影響
本文翻譯自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)。上數矩陣有兩個重要屬性：
- 圖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.