透視BT(三)­­──數字會說話, BT有什麼問題?

轉貼自http://mmdays.wordpress.com/2007/04/10/bt3/


Posted by Mr. Friday

首先要感謝一下各位讀者…前兩篇刊出後, 瀏覽人數直線上升, 兩天下來瀏覽人次直接衝過3000人…小弟還是第一次看到這麼多閱讀量, 著實高興了一下, 希望之後大家還會對我的其他文章捧場一下囉(偷打廣告XD), 在此先謝過大家囉. 不過有些讀者看完第二篇之後覺得太深奧了, 還有人說好像在看排隊理論的論文, 不太想看下去, 這這…好吧, 這第三篇我直接下猛藥. 本篇的重點在於

1. 數據顯示, (瞬間平均)下載速度最快是出現在BT檔發佈後的第50小時!!!

2. 數據顯示, 在BT中, 上傳的量越多, 下載速度反而比較慢!!!

3. 數據顯示, 同時開多個BT下載, 下載速度不會變慢!!!

有沒有比較想往下看了呢? XD

回到正題. 前面兩篇已經分別敘述過BT的基本原理BT隨機過程推導, 那麼這一篇還有什麼好寫的呢? 不曉得大家有沒有發現, 前面在數學論證部分只有純理論的推導. 胡適不是說過:”大膽假設, 小心求證”嗎? 沒有數據驗證, 純理論推導似乎也只是空談. 我們就來看看另外一篇paper, 根據它的數學模型與實際觀測出來的結果. 這篇paper是幾個大陸人聯合觀測與驗證的結果, 篇名叫 Measurements, Analysis, and Modeling of BitTorrent-like Systems. (註:該文圖表眾多, 本篇只取我感興趣的部分)

這篇paper首先觀察了使用者加入BT的狀況, 是一個標準的指數分配:

windowslivewriterbtbt-13b42napster1

綠色的線是實際觀測到的新加入者隨著時間遞減的情形, 藍色的直線是一個指數分配的走向, 可以視為預測值. 看起來預測的值相當接近實際值. 另外, 大家不要看那個好像是一直線, 注意一下y軸, 那個刻度可是10000, 1000, 100, 10, 1人喔, 所以遞減的速度是很驚人的.

把這個人數遞減預測值套到先前的公式, 可以預測到種子與下載者的人數變化

bt_count

黑色虛線是預測值, 紅色是實際觀測到的下載者人數變化,綠色則是觀測到的種子數變化.

從這幾個圖看來, 預測值跟實際觀測值都蠻接近的. 可以證明前一篇的理論大致上是正確的. 好了, 下載速率呢? 你說的數據顯示, (瞬間平均)下載速度最快是出現在BT檔發佈後的第50小時!!!在哪呢? 在這裡!

bt_download_speed

(在這裡先聲明, 本圖是計算”當下在系統內所有人瞬間下載速率的平均”, 而不是第二篇所計算的”對於指定的BT檔, 不論任何時間開啟下載, 所有人的總下載速率平均“, 兩者略微不同. 後者是不會隨時間而變的)

綠色的是實際觀測值, 藍色是預測值. 根據預測, BT大量湧進下載人潮的時候, 其實並不是瞬間速度最快的時候. 瞬間速率最高是種子比例高於下載者的時候…, 也就是說, 當前幾個小時加入下載的人都變成種子, 且新加入的人潮越來越少, 此時就是瞬間下載速率越來越快的時候. 根據實驗結果, 當最初加入者剛變成種子且還沒離開系統時, 下載速度簡直是爆衝. 大約是在BT檔發佈後第50個小時左右會達到爆衝高潮. 不過爆衝這一段時間, 也正好是一堆人下載完檔後一起離開系統的時間, 所以系統比較不穩定. 在第50小時之後, 就算爆衝消失, 由於系統中純分享的種子比率也比下載者高, 因此瞬間下載速度也比一開始快. (130~150, 160~200小時那段平均下載速率為0的原因是那時候根本沒人下載),

懂了嗎? 雖然BT是搶熱門檔的程式, 但是下載速度反而在”種子發佈後50小時”才會快!

這篇paper除了”驗算”上一篇的理論外, 還觀測 (配上他們自己的預測) 了許多其他的數據:

BT檔生命週期. 藍色是預測值, 綠色是觀測值

bt_lifespan

這裡要說明一下他們是怎麼預測的. 之前曾提過有群紐西蘭學生預測失敗對不對? 這篇看起來就預測得很成功啊! 嘖嘖, 這就是功力的差別囉!這群大陸人假設”最後一個種子離開後就會斷種”, 所以當

第n個人花在下載檔案的時間 + 第n個種子在系統中閒晃不離線的時間

小於

第n+1個人到來的時間+第n+1個人花再下載檔案的時間

就會斷種.

上面的圖就是根據這個推斷來的. 我們曾經在第一篇中有提到, 就算種子下線, 只要它曾經把手上的檔案片段都分散給其他下載者, 則該BT就還不會斷種. 所以我們應該會看到綠色的觀測值要比估計值活得久一點(換言之就是y軸的值高一點). 而時間結果也大致吻合.

BT人數預測, 綠色為觀測值, 藍色為預測值, 是根據下載者到達率與上圖生命週期來算的. 大部分的BT檔總人數(y軸)大概只有100人左右而已.

bt_population

好了, 接下來就是大家所關心的: 2. 數據顯示, 在BT中, 上傳的量越多, 下載速度反而比較慢!!!請看下圖.

bt_multiple_download_speed

左邊的y軸代表分享率. 分享率=上傳總量/下載總量. 由於下載總量不變, 所以這個數字意義就是上傳總量. 綠色的點位置越高, 代表上傳得越多. 右邊的y軸代表平均下載速度. x軸的每一個刻度代表一個下載者, 每個x座標上都會有兩個點: 綠色與藍色. 綠色代表該下載者的上傳總量. 藍色代表平均下載速度. 為了容易了解起見, 每個使用者(x軸)是根據下載速率(從高至慢)由左而右排列.(所以藍色的線一路往下).

看懂了沒? 這個圖的意義, 真的就是在BT中, 上傳的量越多, 下載速度反而比較慢!天呀!之前不是有提過, BT的設計理念就是, 越願意分享頻寬的人, 下載速度才會快嗎? 那怎麼數據出來會這樣子呢?

=====================(作用不明的分隔線)======================

在這裡, Mr. Friday要很誠摯的告訴你 : 這兩件事, 都是真的.

聰明的讀者動腦想一想, 相信原因不難推敲. 想不出來? 讓我舉一個常見的例子來說明:

假設今天有A, B兩個人. A的上傳頻寬為100kbps, B的上傳頻寬為50kbps, 今天兩人同時下載一個BT檔案. 兩人上傳速度全開. 由於A的上傳頻寬比較高, 所以下載速度也比較快, 花了20分鐘就下載完了. B的上傳就比較慢, 所以導致他花了1小時左右下載完畢. 兩人都在下載完畢之後立刻關掉BT, 因此A的上傳總量=100kbps * 20分鐘 = 120mb, 而B雖然上傳速度慢, 但上傳總量卻高達50kbps * 1小時 = 50*60*60 kb = 180mb !

這次應該看懂了吧! “上傳總量”不等於”上傳速度”! 由於在BT中, 上傳速度快的人下載得太快了, 反而導致總上傳量其實比那些上傳速度慢還要少. 這張圖凸顯出BT的一個缺點:下載速度並未反應出上傳速度的差異! 上傳速度只是比A慢1/2的B, 下載時間卻可能是A的3倍以上, 導致某種程度的不均衡. 不過在這裡大家也就不要心理不平衡了, 因為1:這個曲線相當平緩, 代表B就算吃虧, 平均來講虧的也不算太多, 而且 2. 還有另外一種的可能性, 那就是:

就是…

從上面那條作用不明的分隔線之後, 都是虎爛

喂喂!先別急著打我, 原文的確是有做出類似的推測, 它說”This indicates that peers with high speed finish downloading quickly and then quit the system soon(本圖暗示:速度快的人, 快速下載完後就速速離開BT了)”. 不過這句話我採保留意見, 因為這個圖表並沒有拿另外的數據(例如上傳速度快的人真的離線得早)來佐證, 雖然這個說法聽起來很合理, 但是沒有數據證實, 還是別輕易就此下定論的好.

好啦我們接著往下看. 接下來的圖表可就是有說服力的了.

bt_multiple_download_speed

這張圖畫法類似上一張圖. 左邊y軸(綠)是下載速度(越高越快), 右邊y軸(藍)是同時開啟的BT檔案數, x軸是每個使用者, 從左至右則依同時開啟的BT數(從高到低). 這張圖代表投藍又投綠的人嗎? 當然不是. 它是說同時開多個BT下載, 下載速度不會變慢. 瞧, 左半邊藍色線較高(開啟的BT數多), 下載速率(綠色點點)也沒有比右邊的人慢啊. 至於為什麼? 文章也不知道.

到這裡就結束了嗎?事實上paper到這裡還沒完. 這篇paper最後其實有個大章節在用數據建立理論模型, 再用模型推導”開啟多重BT檔, 將有助於減少斷種率“. 講實際一點, 就是弄成eMule那種行為模式: 每個人同時開啟好多BT下載, 抓一點點之後可能斷個線, 過個幾小時再回來繼續下載. 根據這篇paper推論, 如果一個BT檔案的下載失敗率是0.1(意即總共10個開啟下載的人中, 會有1個人因為檔案已斷種而下載失敗), 則上述同時開啟多個BT檔案的行為模式, 失敗率會降低到0.000001 . 這差不多也可以解釋為什麼大家都認為eMule上檔案可以留得比較久, 因為eMule上的行為模式就是這樣.

那麼BT可能變成這樣嗎 ? 理論上也許可以吧. 不過BT之所以像BT而不像eMule, 在於兩者的設計理念根本不一樣. BT就是為了大型檔案的快速發佈而生, 而eMule則是為了提供一個什麼都有而且什麼都留得很久的分享環境. 這個設計理念不僅深深影響了兩者的檔案傳輸效能, 也根本的影響了兩者的網路架構與程式介面. 因此BT的使用者有可能會出現eMule使用者那樣的行為嗎? Well, 話不能說死, 不過至少等到BT做出一個內建搜尋頁面出來再說吧!

最後做個總結. 這篇文章用數據驗證了之前提過的數學模型, 也同樣用數據顯示BT各方面的效能, 當中最突顯的是BT在公平性(fairness)上的問題. 最後它提出一個multiple torrents模型, 並推論這樣的行為模式將可大大降低BT的斷種率過高問題.

下一篇, 透視BT(四)­­──為什麼BT沒有內建搜尋功能? 待續….

 

參考資料

Measurement, Analysis, and Modeling of BitTorrent-like Systems by Lei Guo, Songqing Chen, Zhen Xiao, Enhua Tan, Xiaoning Ding, and Xiaodong Zhang

~ 由 壞孩子 於 四月 14, 2007.

發表迴響

在下方填入你的資料或按右方圖示以社群網站登入:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / 變更 )

Twitter picture

You are commenting using your Twitter account. Log Out / 變更 )

Facebook照片

You are commenting using your Facebook account. Log Out / 變更 )

Google+ photo

You are commenting using your Google+ account. Log Out / 變更 )

連結到 %s

 
%d 位部落客按了讚: