模擬結果

5.2.1 封包完成數(Throughput)

此模擬主要變數是 n，因為我們設定是 1~8，我們先用 1 來舉例，Slot Number 是 32000，而 Avg 是 1600/n，因為 n 為 1，所以 Slot Number 除上 Avg 則就是我們執 行總秒數，因 n 的變數，所以我們有 20、40、60、80、100、120、140 與 160 秒的模 擬結果。

圖 5.1 封包完成數量(Throughput)

在封包完成數，如圖 5.1 當中可看見 Modify_1、Modify_2 與 Modify_3 跟 Blueweb 所完成的數量差不多，當封包產生率越快，整體網路封包較多時，在 Modify_1 的效 能比 Blueweb 有更好的效能。

44

5.2.2 封包完成佔全部封包百分比

此模擬主要變數是 n，因為我們設定是 1~8，我們程式當中是將需執行總封包數 的初始值設在 400，我們先用 1 來舉例，總封包數就是 400＊n，所以一共有 400、800、

1200、1600、2000、2400、2800 與 3200 個總封包。

封包完成百分比

80 82 84 86 88 90 92 94 96 98 100

400 800 1200 1600 2000 2400 2800 3200 傳送的的總封包數

封包完成百分比

Blueweb Modify_1 Modify_2 Modify_3

圖 5.2 封包完成百分比

圖 5.2 中可看見 Modify_1、Modify_2、 Modify_3 與 Blueweb 在封包數少的時候，

所完成傳送的封包是差不多的，當封包數越來越多時，Blueweb 完成的封包數開始越 來越少，因為在詢問當中，有可能都往 Route Master 詢問而造成壅塞，而 Modify_1 的效能比起 Blueweb 好很多，有可能在詢問 Route Master 次數變少，所以就直接回覆 傳送，而在 Modify_2 與 Modify_3 有可能因路由表與 Route Master 一樣，所以數據上 與 Blueweb 差不多。

45

5.2.3 封包延遲(Packet delay)

此模擬的作法是封包一旦開始傳遞，則會在路徑經過多少節點數的時間去除以節 點一開始發封包開始詢問每經過的節點加上回覆時的時間與封包完成傳送的總時 間，於是這稱為封包傳遞上的延遲。

封包延遲數量圖

0 500 1000 1500 2000 2500

400 800 1200 1600 2000 2400 2800 3200 總封包數

P ac ke t de la y

Blueweb Modify_1 Modify_2 Modify_3

圖 5.3 封包延遲時槽(Packet delay slot)

在圖 5.3 中，在總時槽上詢問路由表時有可能會花費許多時間，因此造成封 包延遲的增加。Modify 的部份，每個 Master 都擁有大的路由表，所以在 Packet Delay 上，當封包數越來越多時，modify Blueweb 的部份會比較原 Bluewb 好許 多。但在 Modify_2 與 Modify_3 當中，因為 local master 擁有較大的路由表，所 以詢問 route master 的次數相對減少，所以詢問延遲時間改善沒有 Modify_1 好。

而在 Modify_1 當中可知，傳送封包的時間就比 Blueweb 快上許多。

46

5.2.4 詢問封包延遲(Query delay)

此圖要表示每個節點詢問路由表所需佔用的時間，若問的越多層或越多個節點，

則詢問延遲時槽的次數就會一直累加上去。

詢問延遲數量圖

0 500 1000 1500 2000

400 800 1200 1600 2000 2400 2800 3200 總封包數

詢問延遲時槽

Blueweb Modify_1 Modify_2 Modify_3

圖 5.4 詢問延遲時槽(Query delay slot)

在圖 5.4 中，我們可以發現我們將路由表擴大的話，Route Master 被詢問的 次數已經有明顯減少，Modify_2 與 Modify_3 當中，因為 local master 擁有較大的 路由表，所以詢問 route master 的次數相對減少，所以詢問延遲時間改善沒有 Modify_1 好，此外，Upstream Master 所串聯起來的路由表，已經相當於接近於 Route Master 的路由表，所以模擬結果上可明顯發現 modify Blueweb 有效的減少 了詢問的時間

47