4. 模擬結果與分析
4.2. 實驗 1：二個來源端分別傳送 EF 及 AF1x
4.2.4. 實驗 1：FPRC 的佇列佔有情形
表4-6、4-7 分別為 EF、AF 資料流丟棄機制的參數設定值，在本實 驗環境中，我們設定 EF 佇列採用 DropTail 機制，而 AF 佇列則採用本 研究的FPRC 機制，其中表 4-7 的連線容量(C)為 router 2 到 router 3 連 線間的瓶頸頻寬。除此之外，必需再給定FPRC 演算法：minimum desired utilization (αmin) 、 maximum desired utilization (αmax) 、 VQ.threshold 、 MaxListQty 四個參數值，我們將之設為實驗的變數，以觀察他們對實驗 結果的影響：
AF(from s2)
表 4-6 實驗 1 - EF 佇列的參數設定- DropTail
丟棄機制 參數設定 參數意義
DropTail Q = 10000 (bytes) queue size
表4-7 實驗 1 - AF 佇列的參數設定- FPRC
丟棄機制 參數設定 參數意義
Q = 50000 (bytes) queue size FPRC C = 1M (bps) link capacity
我們採用之前已設定好環境，來測試採用FPRC 演算法後的情況，
為了更準確的看出實際佇列長度(actual queue size)的變化，這裡是將 Q 設成50000 bytes，此外還需給定一個 VQ.threshold。在第一個測試中，
我們使用之αmax與αmin都固定為0.7 與 0.4，並固定 MaxListQty 為 7，只 變動VQ.capacity，以觀察實際佇列長度(actual queue size)是否會根據我 們所設定的VQ.capacity 而有所變動，實驗結果如圖 4-7。
圖4-7 (a) 實驗 1 - 佇列佔有與時間(sec)之對應圖- VQ.threshold = 0.3
圖4-7 (b) 實驗 1 - 佇列佔有與時間(sec)之對應圖- VQ.threshold = 0.5 AF(from s2)
EF(from s1)
AF(from s2)
EF(from s1)
圖4-7 (c) 實驗 1 - 佇列佔有與時間(sec)之對應圖- VQ.threshold = 0.7
圖4-7 (d) 實驗 1 - 佇列佔有與時間(sec)之對應圖- VQ.threshold = 0.9 EF(from s1) AF(from s2)
AF(from s2)
EF(from s1)
由圖4-7 中，我們可以發現實際佇列長度(actual queue size)都可以很 準確的控制在指定的門檻值附近，以圖4-7 (a)為例，我們設定實際佇列 長度(Q) = 50000 bytes，VQ.threshold = 0.3，故 VQ.capacity = 50000 × 0.3
= 15000 bytes，而圖中所示之實際佇列長度(actual queue size)即控制在 15000 bytes 附近。以此得知，FPRC 能夠穩定的將佇列長度(queue size) 控制在指定的範圍內。
再來我們必須要測試的是如何採用 αmin 與 αmax，使佇列長度(queue size)能夠更穩定，震盪的幅度更小。這次我們固定 αmax = 0.9、VQ.threshold
= 0.7、MaxListQty = 7，而讓 αmin由 0.1 至 0.8 變動，結果如圖 4-8 所示。
圖4-8 (a) 實驗 1 - 佇列佔有與時間(sec)之對應圖- αmin = 0.1
EF(from s1) AF(from s2)
圖 4-8 (b) 實驗 1 - 佇列佔有與時間(sec)之對應圖- αmin = 0.2
圖4-8 (c) 實驗 1 - 佇列佔有與時間(sec)之對應圖- αmin = 0.3
AF(from s2)
EF(from s1) EF(from s1)
AF(from s2)
圖 4-8 (d) 實驗 1 - 佇列佔有與時間(sec)之對應圖- αmin = 0.4
圖4-8 (e) 實驗 1 - 佇列佔有與時間(sec)之對應圖- αmin = 0.5
AF(from s2)
EF(from s1) EF(from s1)
AF(from s2)
圖4-8 (f) 實驗 1 - 佇列佔有與時間(sec)之對應圖- αmin = 0.6
圖 4-8 (g) 實驗 1 - 佇列佔有與時間(sec)之對應圖- αmin = 0.7
AF(from s2)
EF(from s1) EF(from s1)
AF(from s2)
圖 4-8 (h) 實驗 1 - 佇列佔有與時間(sec)之對應圖- αmin = 0.8
觀察圖4-8，我們發現當 αmin在0.2 至 0.4 左右可以將佇列長度(queue size)控制在固定的範圍內。當 αmin過小時，封包丟棄的數量，將為了使 封包到達率(input rate)達到 αmin而增加，故佇列長度(queue size)會震盪較 大 ， 但 佇 列 長 度(queue size) 還 是 會 穩 定 的 控 制 在 虛 擬 佇 列 長 度 (VQ.capacity)之下，如圖 4-8(b)與(c)所示，(b)的震盪幅度明顯的比(c)還 要大；相反的，當 αmin過大時，每次當封包到達率(input rate)超過 αmax 就開始丟棄，而丟棄又造成封包到達率(input rate)降低，又很快的到達 我們所設的 αmin，封包又開始排入佇列，但事實上，我們丟棄的封包可 能還不夠，佇列可能還是沒有足夠的空間，故如此的惡性循環，造成佇 列長度(queue size)無法控制在 VQ.capacity 之下，造成佇列長度(queue size)溢滿的現象，如圖 4-8 (e)所示，由於我們丟棄的封包數量不足，造 成佇列長度(queue size)不能控制在 35000 bytes (50000 × 0.7 = 35000)之 AF(from s2)
EF(from s1)
下，最後就會產生如圖4-8 (f)至(h)中佇列溢滿的結果。
根據上述之觀察，我們得知αmin與αmax之間的差距應該調整在一定 的範圍，不能過小，可以先由差距大一些開始實驗，慢慢調小，直到無 法將佇列長度(queue size)控制在虛擬佇列長度(VQ.capacity)為止。根據 這個想法，我們試著找出能夠使佇列長度(queue size)穩定的 αmin與 αmax
組合，如圖4-9 所示，圖中之 VQ.threshold 皆為 0.7，MaxListQty 為 7。
圖 4-9 (a) 實驗 1 - 佇列佔有與時間(sec)之對應圖- αmin = 0.3, αmax = 0.6 EF(from s1) AF(from s2)
圖4-9 (b) 實驗 1 - 佇列佔有與時間(sec)之對應圖- αmin = 0.4, αmax = 0.7
圖 4-9 (c) 實驗 1 - 佇列佔有與時間(sec)之對應圖- αmin = 0.3, αmax = 0.8 AF(from s2)
EF(from s1)
EF(from s1) AF(from s2)
圖 4-9 (d) 實驗 1 - 佇列佔有與時間(sec)之對應圖- αmin =0.3, αmax = 0.9
根據圖 4-9，我們發現當 αmax設的較小時，其 αmin與 αmax的差距便 不用太大，如圖4-9 (a)與(b)，其差距僅需 0.3 即可。這是因為我們在封 包到達率(input rate)尚未太大之前就開始丟棄封包了，所以提早丟就可 以避免像 αmax設的過大時，當封包到達率(input rate)超過 αmax時，封包 到達率(input rate)已經太大了，此時才開始要丟封包，需丟棄掉很多封 包才可以使佇列長度(queue size)達到平衡。
根據上述之觀察，我們得知 αmin與 αmax及 VQ.threshold 之間的關係 及最佳的搭配組合。現在我們較感興趣的是MaxListQty 對實驗的影響，
根 據 這 個 想 法 ， 我 們 試 著 找 出 能 夠 使 佇 列 長 度(queue size) 穩 定 的 MaxListQty 值，這次我們固定 αmin = 0.4、αmax = 0.7、VQ.threshold = 0.7，
而讓MaxListQty 變動，結果如圖 4-10 所示。
AF(from s2)
EF(from s1)
圖 4-10 (a) 實驗 1 - 佇列佔有與時間(sec)之對應圖- MaxListQty = 3
圖4-10 (b) 實驗 1 - 佇列佔有與時間(sec)之對應圖- MaxListQty = 4 EF(from s1)
EF(from s1) AF(from s2)
AF(from s2)
圖 4-10 (c) 實驗 1 - 佇列佔有與時間(sec)之對應圖- MaxListQty = 5
圖4-10 (d) 實驗 1 - 佇列佔有與時間(sec)之對應圖- MaxListQty = 6 AF(from s2)
AF(from s2) EF(from s1)
EF(from s1)
圖 4-10 (e) 實驗 1 - 佇列佔有與時間(sec)之對應圖- MaxListQty = 7
圖4-10 (f) 實驗 1 - 佇列佔有與時間(sec)之對應圖- MaxListQty = 8 EF(from s1)
EF(from s1) AF(from s2)
AF(from s2)
圖4-10 (g) 實驗 1 - 佇列佔有與時間(sec)之對應圖- MaxListQty = 9
圖4-10 (h) 實驗 1 - 佇列佔有與時間(sec)之對應圖- MaxListQty = 10 AF(from s2) AF(from s2)
EF(from s1)
EF(from s1)
圖4-10 (i) 實驗 1 - 佇列佔有與時間(sec)之對應圖- MaxListQty = 30
圖4-10 (j) 實驗 1 - 佇列佔有與時間(sec)之對應圖- MaxListQty = 50 EF(from s1) EF(from s1) AF(from s2)
AF(from s2)
根據圖 4-10，我們發現當 MaxListQty = 4 到 10 時都有不錯的效果，
尤其是MaxListQty = 6 或 7 時，其佇列長度較穩定(比較圖 4-10 (b))，震 盪幅度也較小(比較圖 4-10 (h))。
當MaxListQty 設置過小時，由於參與計算封包到達率的封包個數太 少，導致求得的封包到達率過於激進，時大時小，造成封包一會被丟棄 一會又被接受的情形，因此佇列嚴重的震盪，如圖4-10 (a) 所示。
當 MaxListQty 設置過大時，其佇列長度震盪幅度較大也較不穩 定，如圖4-10 (i) 所示。尤其當 MaxListQty 大到一個程度時，演算法就 的速度(input rate)，以達到符合之封包輸出速度(output rate)，藉此控制 佇列的長度，乍看之下，我們似乎可以利用這點來控制封包輸出的速