事件層平行模擬為了能在多核心的系統上正常模擬，它增加了許多額外的負擔，
包含執行緒間共用的變數必需上鎖，尋找可平行運算的安全事件，以及 thread 之間的 IPC 通訊等。上述因素均會影響到事件層平行模擬的效能。在這個章節中，我們將分析 此 ELP 架構的各個部份，希望藉此來找出可以改良的地方。
Parameter Name Value
ns-2 Version 2.31
CPU model Intel Quad-Core
Main memory 2 GBytes
Simulated Grid Network Topology 3x3, 4x4, 5x5, 6x6, 7x7, 8x8, 9x9, *10x10 Number of threads 1, 2, 3, 4
Simulated Time (s) 60
Traffic Type CBR UDP, TCP Interface Output Queue Length (pkts) 50
Event Computation Empty Loop Count (x1000)
0, 10, 20, 30, 50, 60, 70, 80, 90, 100 Link Bandwidth (Mbps) 1, *10, 100, 1000
Link Delay (ms) 1, *10, 100, 200, 300 Transmit range (m) 250
Table 4.1 The used parameter settings
模擬用的環境參數如 Table 4.1 所示，我們列出了所有使用的系統參數，不同的參 數代表不一樣的網路環境。表中用星號標記的文字代表模擬中所使用的預設值。我們建 立了 8 種大小的 Grid 網路拓樸，包括 9、16、25、36、49、64、81、100 個 node。
Figure 4.1 The 5x5 grid wired and wireless networks
以 5x5 大小的模擬網路拓樸為例，如 Figure 4.1 (a)所示為 Grid wired network 的相連方式，每個節點都與上、下、左、右相鄰四點做連接。而 Figure 4.1 (b)所示為 Grid wireless network 的放置方式，每個節點和上、下、左、右相鄰四點的間距都為 250 公尺，使封包剛好可以送到。所有測試的案例，不管是使用 TCP 或是 UDP 協定模組 的應用程式，都會依照拓樸大小來決定應用程式的多寡。所有在網路最上排的節點都放 置了程式來產生封包送往最下排的節點上的程式，網路最左邊的節點，也都會產生封包 送往最右邊的節點。
Event computation loop 所表示的是一個事件所需額外執行的空迴圈次數，如 for(i=0;i<N;i++);，我們藉由這個值來模擬封包在 physical layer 做編碼和解碼所花 費的時間，其送端和收端的模組都有一個對應的迴圈存在，我們測量的值為零到十萬，
4.1 影響 ELP 效能的因素
根據 ELP 的想法歸納出以下幾個會影響到平行化模擬效能的原因。
z worker thread 的個數
因為 worker thread 的數量決定了最大可以同時執行的事件數，因此 speedup 最大不會超過這個值。
z 模擬節點的個數
在網路模擬當中，若是以收端的角度來看，不管是 timer event 或是 physical layer event，所有它處理的事件一定是依照時間的先後次序來執行，正因為 如此，只有不同節點在等待處理的第 1 個封包才有機會判定為安全事件，所 以 speedup 上限不會超過模擬的節點數。
z 處理事件的時間與找安全事件的時間的比例
為了避免 race condition 發生，因此找安全事件時要 lock run queue，確保 同一時間只能有一個執行緒去存取，這樣的話，若是想要達到 N 倍的
speedup，找安全事件所需時間就需要是執行事件所需時間的 N 倍快。
z 找到安全事件的機率
在平行化網路模擬中，當兩個事件互為安全事件的機率越高，master thread 越不用花多餘的時間去找其它安全事件來給 worker thread，使得 worker thread 可以更快的拿到安全事件執行，增進效能。
依據以上所分析的影響平行化模擬效能的因素，因此我們設計了以下的實驗，將會 使用不同的執行緒數目、traffic type、event computation loop count 來模擬。
4.2 Overheads of finding Safe Events
當找安全事件所花的時間越小，代表要平行化網路模擬器所額外付出的 overhead 就越少，其 speedup 就會越高，因此計算找出一個安全事件平均所需的時間，可有助於 了解使用這個架構額外付出的 overhead。在檢查安全事件時，因為要存取 global run queue，需要用 lock 來做保護，因此，我們利用 gettimeofdays () function 來分別取 得 lock 前和 unlock 後的時間，依據其差值得出所花的時間。
Number of Worker
Threads 1 2 3 4
average required time 1.341316 4.446133 5.157505 5.641939 standard deviation 0.483141 4.622712 4.619523 4.110412
Table 4.2 Time required for finding safe events
根據模擬的結果，找安全事件所需的時間只和執行緒數目有關。由 Table 3 可明顯 看出找安全事件所需的時間是相當集中的，當執行緒數量由 1 增加到 2 時，可看到所需 時間大幅上升，原因在於多了要同步不同 CPU 之間的 cache 的負擔，而當 worker thread 數目增加時，找安全事件所需的時間也會繼續上升，這是因為當我們在找安全事件時，
在 worker thread 內執行的事件也要一併檢查，以避免發生因果錯誤，因此當 thread 數越多，找安全事件所花的時間就會越長。
4.3 The Proportion of Physical-layer Events to All of the Simulated Events
在網路模擬器當中，通常 physical layer event 會要花比較多的時間來處理，如
執行安全事件所需的時間就越長，平行化後就越容易得到效率的提升。因此我們計算在 不同的模擬環境下 physical layer event 的比例，並統計成下表
Traffic Type Wired TCP Wired UDP Wireless TCP Wireless UDP Physical-layer Event 28.16% 96.93% 2.39% 18.14%
Table 4.3 Physical-layer event 與總合 event 的比例
從 Table 4.3 來看，UDP 的 physical layer event 比例比 TCP 高，原因是 TCP 需要 許多 timer event 來幫忙處理 retransmit、congestion control 等，而 802.11 的 CSMA/CA 機制，也同樣需要大量的 timer event，因此在 wired 中 physical-layer event 的比例 也明顯比 wireless 多。另外根據實測的結果發現，就算模擬的網路拓樸大小不同，對 physical layer event 所佔比例沒有影響。
由此可看出 Wired UDP 因為有大量的 physical-layer event，當 event computation loop count 增加時，其模擬速度上升的效率會是裡面最好的，Wired TCP 和 Wireless UDP 則是其次，而 Wireless TCP 因為 physical layer event 稀少，可能難以有良好的結 果。
4.4 Overheads of Executing a Safe Event
藉由執行安全事件平均所需的時間和找安全事件所需的時間比，可用來推算出理 想上效率提升的最大值。因此我們在 worker thread 執行安全事件時，利用
gettimeofdays () function 來分別取得執行安全事件前後的時間，並依據其差值得出 所花的時間。
0
Event Computation loop count (x1000)
Time (microseconds)
Wired TCP Wired UDP Wireless TCP Wireless UDP
Figure 4.2 Event Processing time
Event Computation Loop count 代表對 physical-layer event 額外加的 overhead，
如 Figure 4.2 所示，當 event computation loop count 增加後，平均處理事件所需的 時間也會上升。其模擬結果也和上一小節的 physical-layer event 的比例相呼應，當 event computation loop count 增加，physical-layer event 比例越高的網路拓樸其 處理安全事件所需時間的上升越快。
Event Computation Time (microseconds)
Probability Distribution Function
0
Event Computation Time (microseconds)
Probability Distribution Function
Figure 4.4 Event computation loop count 為十萬的 Wireless UDP 處理事件時間分 佈圖
以上為處理事件的時間分布圖，我們以 10x10 的 Wireless UDP 的為例。兩張圖相 比較的結果顯示，沒有隨 event computation loop count 上升而增加處理時間的都是 timer event，很明顯的可以看出，這些事件所需的處理時間都相當小，而在多執行緒 的架構下，找安全事件所需的時間平均也要 4 microseconds，這樣的話平行處理這些 timer event 不僅不會有任何好處，反而會降低模擬的效率。
4.5 Overheads of Thread Switching and Global Variable Access
在多執行緒的應用程式中，各執行緒間共享多個變數，一起去修改它是常有的事，
而在平行模擬中，最常被存取的就是 global run queue，因為原始的平行化網路模擬器 架構較為複雜，並不利於測量，所以另外寫一個小程式，用來估算 thread switching 所需最小 overhead。
先建立 2 個執行緒來搶同個 lock，在取得 lock 的同時執行緒會讀取同個變數，並 寫入特定的數值，因此當發現此變數改變時，就表示曾切換到另一個執行緒過。藉由計 算此變數改變的次數，便可得知執行緒切換的次數。而由那個執行緒搶到 lock 則是由
Linux kernel 來決定的，因此我們跑了數次結果，將執行此程式所花的時間和執行緒切 換的次數做成如下圖表。
0 10000 20000 30000 40000 50000
0 2000 4000 6000 8000 10000 12000 14000 Thread間切換次數
時間 (microseconds)
Figure 4.5 Thread switching overhead
根據此圖，可發現大致上點是分佈在一條直線上的，因此我們用最小平方法計算出 其 linear equation 為＂y=2.818x+2767.279＂，則執行緒間切換所造成的 overhead 約 為 2.818 microseconds，而網路模擬器在執行緒切換時要同步的變數遠比此測試程式 多，因此實際上所需的 overhead 相信會比這值大。