擁塞控制演算法測試——Planetlab平臺實驗
****************************************************************************************************************
放在前面說明吧:
發了這篇部落格之後,陸續有人私信我問關於Planetlab的問題。
我平時不太看私信的,有些私信可能隔好幾天才看得到。
建議大家直接在評論區說就好,我回復的會及時一些。
2017.9.4
*****************************************************************************************************************
總結了一下之前做的一個實驗測試。
主要圍繞Planetlab平臺進行,遇到過不少磕磕絆絆的地方,也花了很多時間和精力去解決。下面進行一些總結,如果後期有同道們也接觸到這些問題,可以作為參考。
Planetlab:
1. 簡介:
Planetlab是一個分佈於全球的計算機群專案,始於2003年,對研究人員而言使用PlanetLab的好處是:他們能夠在真實世界條件下大規模地進行試驗測試,也是開發全新網際網路技術的開放式全球性測試平臺。本次我採用這個平臺是用來測試真實的網際網路條件下的網路頻寬。當然,為了保證其他使用者不受干擾,長時間對網路頻寬進行探測在Planetlab是被明令禁止的,所以測試的單位時間不能太大。
2. 從註冊開始:
Planetlab有自己的註冊頁面,直接在上面填上資訊註冊就好,運氣好的話你可能就一次成功了。我最開始的時候在Planetlab註冊賬號非常不順利(對於免費專案要求也不能太多),後來通過聯絡北大節點的管理員周老師進行了註冊,為保證個人隱私,不公佈周老師的聯絡方式,不過大家以後需要的話可以跟我要。
成功註冊賬號後,第一件要做的事情是建立公私鑰並上傳公鑰:在你本地的unix系統(一搬就用ubuntu就行了)中執行:
ssh-keygen -t rsa -f ~/.ssh/id_rsa
會在~/.ssh/id_rsa目錄下生成一個公鑰一個私鑰,在Planetlab網站的登陸賬號後的My Account目錄下點選上傳公鑰即可。注意公鑰的開頭格式必須是ssh-rsa AAAAB3Nza...否則需要自行轉換。公鑰中的最後的字串說明了需要的許可權!!!這點一定注意,會影響到你登陸是採用的賬號許可權限制。
成功上傳公鑰後,自行在node中新增slice,在這個過程中,節點狀態是紅色的boot...或者藍色的boot都是可以新增的,不要被紅色騙了。當然,新增的節點能否成功連線上需要自己挨個試,最後只要自己留下能夠成功連線的節點就好了。值得注意的是,有些節點的作業系統是Fedora 8的,還有些是CentOS 6,大家根據需求可以針對性的選取。連線節點的命令如下:
ssh -l princeton_test1 -i ~/.ssh/id_rsa planetlab-1.cs.princeton.edu
其中,用自己的slice名稱(在My Account裡可以查到)替換princeton_test1,用私鑰的路徑名替換~/.ssh/id_rsa(一般預設情況下就是這個),用你想連線的節點名稱或ip替換planetlab-1.cs.princeton.edu。記住,這個命令一定要在生成私鑰的相應的許可權使用者下操作,不然會連線失敗。
成功連線後命令行會顯示讓你再輸入一次建立金鑰時的密碼(這個密碼是針對私鑰訪問的密碼),才能成功登陸節點。如果嫌麻煩,可以進行如下操作取消輸入密碼的步驟:
#在終端下輸入
ssh-keygen -p。
#系統會提示選擇需要修改的私鑰,預設/home/username/.ssh/id_rsa。
#選好檔案後按回車,會提示你輸入舊密碼。
#輸入好後會提示輸入新密碼。
#直接回車,提示確認新密碼再直接回車,此時指定的私鑰的密碼就被清除了。
3. 連線之後:
完成了上述兩步後,你應該可以成功的連線到Planetlab的節點了,會進入到一個命令列作業系統。我們可以先檢視系統的版本和核心:
#檢視fedora版本:
cat /etc/issue
#檢視核心版本:
uname -r
Planetlab提供的初始系統非常乾淨,幾乎所有的東西都需要自己進行安裝。而且Planetlab還遮蔽了某些軟體,比如iperf,所以需要自己從上傳安裝包,再在節點的系統中進行本地安裝。
這裡提供幾個傳輸檔案的命令:
#本地傳輸到Planetlab:
scp -i ~/.ssh/id_rsa -r 路徑/檔名 slice名@節點名:
#Planetlab傳輸到本地:
scp -i ~/.ssh/id_rsa slice名@節點名:路徑/檔名 本地路徑
舉個栗子:將本地的iperf安裝包上傳到上交節點並安裝:
scp -i ~/.ssh/id_rsa -r /home/bert/Desktop/iperf-2.0.1-1.2.el4.rf.i386.rpm [email protected]:
#安裝執行(在遠端執行):
rpm -Uvh iperf-2.0.1-1.2.el4.rf.i386.rpm
此外,如果想在Planetlab的Fedora系統中直接通過yum安裝檔案,需要執行:yum --nogpgcheck install ...,否則會報gpg錯誤。
這些就是針對Planetlab的一些總結,這個平臺的相關資料網上其實很少,當時摸索的也比較辛苦。最重要的是,裡面的系統簡直是古董級,核心非常陳舊,很多東西都不太好操作。如果大家為了方便起見,直接把自己的演算法變成執行程式,這樣測試最好的。
相關推薦
擁塞控制演算法測試——Planetlab平臺實驗
**************************************************************************************************************** 放在前面說明吧: 發了這篇部落格之後,陸續有人私
小議WebRTC擁塞控制演算法:GCC介紹
網路擁塞是基於IP協議的資料報交換網路中常見的一種網路傳輸問題,它對網路傳輸的質量有嚴重的影響,網路擁塞是導致網路吞吐降低,網路丟包等的主要原因之一,這些問題使得上層應用無法有效的利用網路頻寬獲得高質量的網路傳輸效果。特別是在通訊領域,網路擁塞導致的丟包,延遲,抖動等問題,嚴重的影響了通訊質量,如果
來自Google的TCP BBR擁塞控制演算法解析
寫本文的初衷一部分來自於工作,更多的來自於發現國內幾乎還沒有中文版的關於TCP bbr演算法的文章,我想搶個沙發。本文寫於2016/10/15! 本文的寫作方式可能稍有不同,之前很多關於OpenVPN,Netfilt
Google's BBR擁塞控制演算法模型解析
在進入這篇文章的正文之前,我還是先交代一下背景。1.首先,我對這次海馬臺風對深圳的影響非常準確,看過我朋友圈的都知道,沒看過的也沒必要知道,白賺了一天”在家辦公“是收益,但在家辦公著實效率不高,效果不好。2.我為什麼可以在週五的早上連發3篇部落格,一方面為了彌補因為颱風造成”在
Ubuntu16.04 x64伺服器配置最新tcp擁塞控制演算法bbr
BBR原理 不多說了,請看這篇博文! 配置步驟 用uname檢視linux核心版本,只有4.9以上的才支援bbr這個演算法。 uname -ir # possible output 4
Linux Kernel 4.9中BBR擁塞控制演算法的優勢
本文轉載自《Linux Kernel 4.9 中的 BBR 演算法與之前的 TCP 擁塞控制相比有什麼優勢?》 中國科大 LUG 的 @高一凡 在 LUG HTTP 代理伺服器上部署了 Linux 4.9 的 TCP BBR 擁塞控制演算法。從科大的移動出口到新加坡 D
基於效能的擁塞控制演算法PCC
一次資料包的丟失,也許並不代表網路發生擁塞。但是在經典的tcp擁塞控制條件下,丟包作為網路擁塞訊號,tcp的視窗就要減半,傳送端就要減少向網路中傳送的資料包數量。 若是丟包是如下原因,降窗明顯不合理。 f might traverse a shallo
幾種TCP擁塞控制演算法的分析
幾種TCP擁塞控制演算法的分析擁塞控制演算法是實現TCP的重要元件,目前已有非常多的TCP Congestion Control Algorithm. 不同的演算法有自己的優化特性和工作區域。首先,本文簡單介紹一下TCP擁塞避免演算法的工作原理;其次,介紹Reno, Vega
TCP擁塞控制演算法BBR原始碼分析
BBR是谷歌與2016年提出的TCP擁塞控制演算法,在Linux4.9的patch中正式加入。該演算法一出,瞬間引起了極大的轟動。在CSDN上也有眾多大佬對此進行分析討論,褒貶不一。 本文首先對原始碼進行了分析,並在此基礎上對BBR演算法進行總結。 ##
tcp擁塞控制演算法
需要說明一下,如果你不瞭解TCP的滑動視窗這個事,你等於不瞭解TCP協議。我們都知道,TCP必需要解決的可靠傳輸以及包亂序(reordering)的問題,所以,TCP必需要知道網路實際的資料處理頻寬或是資料處理速度,這樣才不會引起網路擁塞,導致丟包。 所以,TCP引入了
TCP擁塞控制演算法 調整TCP擁塞控制演算法 TCP Congestion Avoidance Algorithm
中美之間的線路質量不是很好,rtt較長且時常丟包。TCP協議是成也丟包,敗也丟包;TCP的設計目的是解決不可靠線路上可靠傳輸的問題,即為了解決丟包,但丟包卻使TCP傳輸速度大幅下降。HTTP協議在傳輸層使用的是TCP協議,所以網頁下載的速度就取決於TCP單執行緒下載的速度(因為網頁就是單執行緒下載的)。丟包使
擁塞控制演算法
TCP超時重傳 原理是在傳送某一個數據以後就開啟一個計時器,在一定時間內如果沒有得到傳送的資料報的ACK報文,那麼就重新發送資料,直到傳送成功為止。 影響超時重傳機制協議效率的一個關鍵引數是重傳超時時間(RTO,Retransmission TimeOut)。RT
網路擁塞控制之TCP擁塞控制演算法
為了防止網路的擁塞現象,TCP提出了一系列的擁塞控制機制。最初由V. Jacobson在1988年的論文中提出的TCP的擁塞控制由“慢啟動(Slow start)”和“擁塞避免(Congestion avoidance)”組成,後來TCP Reno版本中又針
開啟TCP BBR擁塞控制演算法
什麼是BBR TCP BBR是谷歌出品的TCP擁塞控制演算法。TCP-BBR的目標就是最大化利用網路上瓶頸鍊路的頻寬,儘量跑滿頻寬,並且儘量不要有排隊的情況。BBR可以起到單邊加速TCP連線的效果。 BBR演算法,Google已經提交到Linux主線
Google BBR擁塞控制演算法模型初探
女主宣言 本文出自於ADDOPS團隊,該文章是一篇興趣觸發的探索性文章,作者是一名剛畢業的小鮮肉,買新系統,去自己探索bbr演算法,難能可貴,並且給出了詳細的部署步驟,也能讓大家在興趣之餘跟著步驟試一把,並且簡單描述了該演算法的使用場景和基本原理。bbr在劣質網路下能充分利用頻寬,並且也已經併入了新版本的
TCP協議滑動視窗協議以及擁塞控制演算法
http://blog.csdn.net/liuchen1206/article/details/8599542 什麼是滑動視窗協議? 一圖勝千言,看下面的圖。簡單解釋下,傳送和接受方都會維護一個數據幀的序列,這個序列被稱作視窗。傳送方的視窗大小由接受方確定,目
TCP擁塞控制演算法 — CUBIC的補丁(四)
描述 以下是提交者Stephen Hemminger對這個patch的描述: enable high resolution ack time if needed This is a refined version of an earlier patch by Lucas
tcp/ip下,擁塞控制演算法
TCP的RTT演算法 從前面的TCP重傳機制我們知道Timeout的設定對於重傳非常重要。 設長了,重發就慢,丟了老半天才重發,沒有效率,效能差;設短了,會導致可能並沒有丟就重發。於是重發的就快,會增加網路擁塞,導致更多的超時,更多的超時導致更多的重發。 而且,這個超時
TCP擁塞控制演算法 優缺點 適用環境 效能分析
【摘要】對多種TCP擁塞控制演算法進行簡要說明,指出它們的優缺點、以及它們的適用環境。 【關鍵字】TCP擁塞控制演算法 優點 缺點 適用環境公平性 公平性 公平性是在發生擁塞時各源端(
現代網際網路的TCP擁塞控制(CC)演算法評談
動機 寫這篇文章本質上的動機是因為前天發了一個朋友圈,見最後的寫在最後,但實際上,我早就想總結總結TCP擁塞控制演算法點點滴滴了,上週總結了一張圖,這周接著那些,寫點文字。 前些天,Linux中國微信公眾號推了一篇文章,上班路上仔細閱讀了一下,感受頗深,一方