BLACE 與 CBCC 的結合效能測試

在 這 一 節 中 ， 我 們 會 將 BLACE 與 CBCC 結 合 ， 測 試 它 的 效 能 ， 並 與 Coolstreaming 和 Prime 做比較。在我們的方法中，每個節點會使用 BLACE 估計接 收者的貢獻，並使用 CBCC 根據不同接收者的貢獻來分配到它們的傳輸速率。

5.3.1 模擬環境設定

在這部分的實驗，我們使用了比較複雜的網路拓樸，如圖 28 所示。

圖 28 CBCC 與 BLACE 結合測試使用的網路拓樸

34

中間的路由器並不會執行同儕網路的程式，而只是負責封包繞送。路由器彼 此之間有隨機的連接，稱為 Core link，具有較大的頻寬。同儕網路的節點都經過 一條連接隨機連到路由器上，該連接稱為 Edge link。這邊設定的網路環境是，每 個節點都有足夠的下載頻寬，但是不一定有足夠的上傳頻寬，因此我們設定 Edge link 的不同方向有不同的頻寬，路由器到節點的方向(下載)，頻寬一律是 100Mbps，

而節點到路由器的方向(上傳)，頻寬則隨機分布，且根據不同的測試環境有不同 的分布。

我們會測試在不同網路環境下，本論文的方法和 Coolstreaming 以及 Prime 的表現。我們測試的不同網路環境包括來源節點的上傳頻寬不同、一般節點的平 均上傳頻寬與分布不同，以及節點加入和離開的頻率不同。

我們會測試使用 CBCC 分別根據節點的頻寬、節點要求的子串流的延遲，以 及節點使用 BLACE 估計出的貢獻來分配傳輸速率，這三種不同的速率分配方式的 效能差異，並且與 Coolstreaming 以及 Prime 做比較。

本部分實驗的詳細參數設定列於表 5。

Edge link 頻寬 0-600K, 100-700K, 200-800K, 300-900K 之間平均分布 Edge link 延遲 1ms 到 100ms 之間平均分布

來源節點上傳頻寬 1.6M, 2.4M, 3.2M, 4.0M, 4.8M 節點加入離開頻率 每 10 秒 0, 1, 2, 3, 4 個節點

表 5 CBCC 與 BLACE 結合測試的實驗參數設定

5.3.2 實驗結果與分析

35

首先我們先測試沒有節點上下線的情況。在這個部分裡，我們設定來源節點 的上傳頻寬為 4.0Mbps，測試一般節點頻寬分布分別為 0-600kbps、100-700kbps、

200-800kbps、300-900kbps 時，各種方法的效能，以下是測試的結果。

圖 29 沒有節點上下線，不同上傳頻寬分布下節點平均的接收速率

圖 30 沒有節點上下線，不同上傳頻寬分布下節點收到片段的平均延遲

從以上圖表可看出，除了頻寬分布在 0-600 kbps 時，Prime 收到的片段延遲 是最小的之外，不管是在節點平均接收速率以及接收到的片段延遲方面，使用 CBCC 根據 BLACE 估計出的貢獻來分配頻寬，得到的效能都是最好的。

36

另外，我們發現節點上傳頻寬越來越大時，CBCC (bandwidth)和 CBCC (delay) 在節點接收速率的表現越來越接近，我們推測是因為節點平均上傳頻寬較小時， 來源節點的上傳頻寬為 4.0Mbps，一般節點的上傳頻寬平均分布於 300kbps 到 900kbps 之間。

37

圖 31 上下線頻率不同時，節點平均的接收速率

圖 32 上下線頻率不同時，節點收到片段的平均延遲

由以上圖表可看出，上下線頻率增加時，每種方法中，節點的平均接收速率 都會降低。但是儘管如此，CBCC (Contribution)依然是表現最好的方法。

接著我們測試來源節點的上傳頻寬對系統的效能造成的影響。在這個部分我 們設定來源節點上傳頻寬分別為 1.6M、2.4M、3.2M、4.0M、4.8M，而一般節點 上傳頻寬分布於 300kbps 到 900kbps 之間，每十秒鐘會有一節點上下線。

38

圖 33 來源節點上傳頻寬不同時，節點平均的接收速率

圖 34 來源節點的上傳頻寬不同時，節點收到片段的平均延遲

從上面圖表可看出接收速率方面，Coolstreaming 受到來源節點上傳頻寬的 影響最大，我們推測這是因為 Coolstreaming 使用 TCP 來傳送子串流，因此傳輸 速率會平均分配在所有接收者，當來源節點頻寬不足時，造成的結果就是所有的 接收者都無法收到完整的子串流。而 CBCC 在頻寬不足時，自然會把傳輸速率分 到少數幾個接收者，因此效果會比使用 TCP 還要好。而 Prime 是片段式的架構，

不需要提供者提供完整的子串流速率，因此受到來源節點上傳頻寬的影響最小。

39

再來我們來測試本論文提出的方法是否真的能達到傳輸較多的節點收到較 多的資料。這部分我們設定來源節點上傳頻寬為 4.0Mbps，一般節點上傳頻寬平 均分布在 100kbps 到 700kbps，沒有節點上下線。我們會測試 CBCC 只考慮上傳 頻寬跟考慮貢獻時，節點的傳輸速率跟接收速率的關係。

圖 35 考慮上傳頻寬時，節點的傳送速率跟接收速率的關係

圖 36 考慮貢獻時，節點的傳送速率跟接收速率的關係

由以上圖表可看出，雖然兩種方法都可以達到傳送較多的節點接收較多的效 果，但是在只考慮頻寬的狀況下，達到的效果是比較好的。

40

最後我們要測試 BLACE 所估計出的貢獻是否會跟實際的貢獻符合，在這個實 驗中，我們設定來源節點上傳頻寬為 4.0Mbps，一般節點上傳頻寬平均分布在 100kbps 到 700kbps，沒有節點上下線，並擷取系統運行了 2000 秒後的狀態。首 先我們只看單一子串流。

圖 37 節點對一個子串流的實際貢獻和估計的貢獻關係

由於大部分的點 Actual contribution 都分布在 200 以下，所以我們把縱座標 軸的上限設為 200，以便更清楚的看到分布的狀態。我們可以發現，就單一子串 流而言，實際的貢獻(即節點把該子串流散布給了多少人)和估計出的貢獻沒什麼 明顯的關係。

接著我們合計所有子串流的實際貢獻和估計貢獻，再來看它們的關係。

41

圖 38 節點對所有子串流合計的實際貢獻和合計的估計貢獻的關係

這次我們就可明顯的觀察到估計出的貢獻越大的節點，實際的貢獻也會越大，

且底部較密集的部分的點的實際貢獻大略符合估計出的貢獻。但是我們也可以看 到，估計出的貢獻和實際的貢獻其實還是沒有完全符合，我們推測的原因如下：

第一，本論文提出的方法中，每個節點完全是隨機的選擇提供者，所以頻寬大的 節點 A 可能選到頻寬小的節點 B 當作提供者，因此 A 的實際貢獻也會被算進 B 的實際貢獻，導致了頻寬小的 B 實際貢獻比頻寬大的 A 還大。第二，本論文假 設每個節點會把頻寬平均的用來傳送每一個子串流，但是根據實驗結果，我們發 現節點通常會把頻寬集中用來傳一個子串流。下圖就是我們觀察到的結果。

圖 39 節點對所有子串流合計的實際貢獻和對單一子串流最大的實際貢獻的關係 0

50 100 150 200

0 5 10 15 20 25 30 35 40 45

Actual Contribution

Estimated Contribution