行政院國家科學委員會專題研究計畫 成果報告
嵌入式網路通訊裝置評比技術與工具之研發--子計畫一:嵌
入式網路通訊裝置應用效能評比技術與工具之研發(中心分
項)(2/2)
研究成果報告(完整版)
計 畫 類 別 ： 整合型 計 畫 編 號 ： NSC 99-2220-E-009-044- 執 行 期 間 ： 99 年 08 月 01 日至 100 年 07 月 31 日 執 行 單 位 ： 國立交通大學資訊工程學系（所） 計 畫 主 持 人 ： 林盈達 處 理 方 式 ： 本計畫可公開查詢中 華 民 國 100 年 10 月 30 日
目錄 (Cotent) [1] 摘要 ... 1 [2]緣由與目的 ... 1 [3]研究內容 ... 2 SSLTC ... 2 IVQT... 4 MLPP ... 7 [4]研究成果與討論 ... 9 [5]參考文獻 ... 11
1
1. 摘要
嵌入式系統平台已被大量應用在商用 及家用產品上如PDA 和 WiFi Phone，但是 對於嵌入式系統網路裝置在使用者端的應 用效能上卻缺乏可用的測試工具，廠商在開 發產品之後無法精確得到其效能，當產品有 關於效能方面的問題也無從得知可以改善 的方式，為此，開發「嵌入式系統網路通訊 裝置應用效能評比工具」，除了要提供黑箱 測試數據外，更應設計對於開發者可進行加 強以及偵錯的灰箱及白箱測試，協助開發者 清楚了解產品在使用者端所遇到的缺點以 及相關改進的方法。 本計畫開發的項目，是針對目前熱門的 嵌入式系統網路通訊產品，進行相關網路應 用服務效能評比(如: Throughput, Session Capacity, Session Rate, Voice Quality )，利用 NBL 現有的工具以及 Open Source 軟體，以 Repeatable、Scalable、Automatic、Integrated 等四個條件為前提，進行 1. 測試計畫及方 法之研發, 2. 對測試設備無依賴性之測試 工具研發, 3. 整合型測試工具研發，配合總 計畫提供的共通測試平台，提供各種不同層 級的背景流量，更能貼近實際上使用者端使 用的環境，在測試工具的開發規劃裡，預計 進行兩項測試工具的開發，其中包括：連線 量測試工具、SSL VPN 連線量測試工具以及 語音品質整合測試工具，這些都是目前所所 缺乏的應用效能測試工。達成對嵌入式網路 通訊裝置進行完整效能的測試及評比，除了 能幫助產品開發者進行效能改進及選擇適 合使用的元件平台，亦可做為學術上進行相 關研究時有實際上產品的數據供做先進技 術的研發，並將此系統原始碼公開，提供開 放原始碼社群使用及研究。 關鍵詞： 嵌入式系統、網路通訊裝置、網 路應用服務效能、開放原始碼
2. 緣由與目的
晶片設計以及製程技術的進步，晶片組 以及其相關整合產品效能不斷的提升且價 格更趨便宜，使得許多平常可見的商用或家 用產品皆可利用嵌入式系統實現之，尤其現 在更強調這些產品的網路連通性，以及彼此 之間與個人電腦和網際網路的整合性，網路 功能不再是個人電腦的專利，而是各項資訊 產品、家電等各種產品用來整合個人和公司 資訊及各項功能的方案；然而針對這類型的 整合性產品(ex: PDA, WiFi Phone)卻缺乏可 以進行嵌入式網路通訊系統效能評比的方 式，針對單一元件可以直接進行該元件測試 即可達成，然而對System Vendor 而言卻非 如此，Chip Vendor 可以經由單一晶片測試 達到其所需求的結果，但是 System Vendor 卻必須將目標放在產品的系統效能上，除此 之外現在 Chip Vendor 已漸漸走向 Total Solution 的模式，也就是說 Chip Vendor 要自 己來開發System，因此更會期待一個測試中 心可以對整體系統的效能表現作一個完整 的測試，所以子計畫一的目標應考慮整合好 的產品所必須要了解的系統效能，並且要能 經由不同的應用程式測試，達成對整體系統 的分析，根據不同的嵌入式網路通訊系統 (註一)所欲得之結果(註二)，開發針對不同 型態(註三)的測試項目。 註一: handheld、server、network。 註二: Throughput、Latency、Bandwidth Consumption、Response time、TCP connection rate/capacity IPSec tunnel rate/capacity、Voice Quality、SIP call rate/capacity、WLAN association rate/capacity。註三: Black, Grey, White Box。
2 子，餵入合成的存取樣式，從外部測量基本 的效能的讀數，如Throughput。這種測試可 以測出在通用或是已知的特殊情況的行為 及效能。 Gray box 測試：不同的網路通訊裝置有其 特殊的使用機制，如NAT/Firewall 上設定的 規則，必須進入Gray Box 階段。並透過廠 商提供的控制介面，進一步的從待測物上取 得black box 讀取不到的數據，如：Default Rules 和 Matching priority，進行 Throughput 和Latency 效能評估。 White box 測試：主要用來取得更詳盡的測 試數據與事件截取，因為有了原始碼，則可 以直接針對該演算法取得所有與效能相關 的數據。 而評斷嵌入式系統效能的好壞可以由 兩個方向進行區分，一者為硬體上的效能， 指的是裝置上的CPU、Memory 和 I/O 等裝 置的效能，例如 CPU 的處理速度為一秒鐘 可以執行多少指令集，記憶體容量有多少、 能以多快的速度接受存取，I/O 在複製、搬 移等動作時，每秒可以存取多少容量；另一 者 為 網 路 系 統 效 能 ， 如 Throughput 、 Latency 、 Loss 和 Session Capacity 等 ， Throughput 是對於網路系統最直接的評斷 方式，直接指出該網路系統在不造成封包丟 棄 的 狀 態 下 ， 能 處 理 的 最 大 數 量 封 包 ， Latency 則是封包從進入該網路系統至離開 該網路系統時，在系統中停留的時間，即為 系統所造成之延遲，Loss 則是當輸入 loading 超過系統所能負荷的最大負載時，所造成的 封包遺失為多少，Session Capacity 則是在測 試針對某單一通訊協定(如 TCP)，網路系統 能承受的連線數量為多少。 另外，在嵌入式系統上剖析使用情境的 執行時間，會面臨三個主要的問題:第一、 使用情境的執行會橫跨不同軟體層來呼叫 不同元件，第二、軟體層皆是由一種以上的 程式語言所構成，第三、系統的儲存空間有 限。在此我們設計一個分段反覆插入剖析方 法 ， 可 以 在 多 種 程 式 語 言 及 多 個 軟 體 層 (multi-langue and multi-layer)平台上找出執 行時間瓶頸。由單一的模組開始，進而逐漸 地加入不同軟體層的不同模組來剖析，以避 免在剖析過程中產生大量不必要的資料節 省儲存空間，最後再把不同軟體層執行時所 輸出的資料合併分析，藉此找出執行時間瓶 頸。
3. 研究內容
本計畫研究所開發之工具為 SSL VPN Tunnel Tester (SSLTC) 、 Integrated Voice Quality Test (IVQT) ， 以 及 Multi-Level Performance Profiling (MLPP)其詳細架構如 下： SSLTC 用戶端可以利用VPN 方式連線，進行私密 安全連線，以防止資料在網路上進行傳輸 時，遭到駭客竊取，但是加密連線必須使用 大量的運算，以及過濾，使得該類型的網路 安全產品可容納的VPN 容量無法達到實際 需求，考量在大部份的情況下，利用VPN 進行連線時，許多的連線都是在進行網頁瀏 覽，因此並非需要在Client 和 Server 端之間 保持建立連線的狀況態，也可由此減輕VPN 網通裝置的負擔，利用SSL VPN 的方式進 行資料的流通，以Linux 為 SSL VPN 的 client，產生同時多條的 SSL VPN tunnels (Full Tunnel Mode)與 users 來連上 SSL VPN server，可用來自動化測試 tunnel capacity、 user capacity、stability。本系統的軟體架構主要是由幾項元件 所構成: Traffic Generator– SSL VPN Tunnel, Traffic Generator – Background Traffic, Controller，以下說明各個元件所扮演的角色 以及如何進行測試與蒐集數據：
Traffic Generator – SSL VPN Tunnel： 使
3
tunnels。
Traffic Generator – Background Traffic：除
了建立SSL VPN tunnel 外，也可產生網路流 量導入SSL VPN tunnel 中，如 HTTP、FTP.. 等等。
Controller：會使用一台 PC 作為 controller，
controller 的 功 能 一 是 用 來 trigger traffic generators ， 二 是 用 來 抓 取 DUT 上 的 information 來判斷該次測試的結果是 Pass or Fail。 SSLTC 之系統架構如下所示： 在Client 上先執行 pptpd，然後執行測 試程式。測試程式會先登入SSLVPN 裝置， 認證成功後由pptpd 呼叫 pppd 建立 ppp 介 面，連到後端server 所在的 subnet，之後再 由測試程式透過建立好的SSLVPN Tunnel 向後端server 抓取資料，驗證是否成功連線。 目前支援capacity 及 throughput 兩種測 試模式，capacity 會不斷建立 tunnel，直到 指定的數量或是所有帳號都用完為止，每個 tunnel 建立的間隔時間為 RATE。每個 tunnel 建立後，會依據指定的TRAFFICRATE 時間 間隔，向後端server 抓取資料，驗證 tunnel 是否正常。 Throughput 測試會先建立指定數量的 tunnel。等全部建立好後同時向後端 server 抓取資料。每條tunnel 會各自計算 throughput(總傳輸的資料量/(結束時間-開始 時間))，另外也會算總共的 throughput，以 全部tunnel 的傳輸量除以(所有傳輸完成時 間-開始傳輸時間)。 目前支援capacity 及 throughput 兩種測 試模式，capacity 會不斷建立 tunnel，直到 指定的數量或是所有帳號都用完為止，每個 tunnel 建立的間隔時間為 RATE。每個 tunnel 建立後，會依據指定的TRAFFICRATE 時間 間隔，向後端server 抓取資料，驗證 tunnel 是否正常。 Throughput 測試會先建立指定數量的 tunnel。等全部建立好後同時向後端 server 抓取資料。每條tunnel 會各自計算 throughput(總傳輸資料量/(結束時間-開始時 間))，另外也會算總共的 throughput，以全 部tunnel 的傳輸量除以(所有傳輸完成時間-開始傳輸時間)，時間計算如下圖的 部 分。 程式首先會讀取命令列參數，取得設定 檔名與要測試tunnel 數，如果不是前面列的 參數(如 TRAFFIC、RATE)，就建立一個 test instance，傳入帳號密碼及其他資訊，若密 碼後有接IP(以,分隔)，則使用這組帳號密碼 連線時，會連到此SSLVPN 裝置，而不是 DEVICE 指定的 IP。全部建好後，就依設定 的間隔執行。每一個instance 用一個 thread 跑，所以測試時會有很多個thread 同時跑。 Test Clie SSLV PN 後端 Ser e SSL VPN
4 Tunnel 建立流程如下: (1) getAuthCookie 連到 SSLVPN 裝置的 https 網頁，以給定 的帳號密碼登入後取得 cookie。 (2) getIPInfo 用第一步取得的cookie，一樣連到 SSLVPN 的 HTTPS，送出: CONNECT 127.0.0.1: 10443 HTTP/1.1\r\n Host: 127.0.0.1\r\n Cookie: authtok= xxxxxxx\r\n\r\n 若回傳 HTTP/1.1 200，代表成功，之後 傳送如下，抓取IP 設定資訊: GET /L2TunCFG xxxxxxx (3) resolvIPInfo 分割第二步抓到的資訊，取得interface IP 等資訊。 (4) getDeviceConnection 同樣連到SSLVPN HTTPS，送出： Get /L2TunREADY xxxxxxx 之後此連線要持續，整個SSLVPN Session 中不可中斷。 (5) getServerConnection 與本機的pptpd 溝通後會先額外送一個 含有第三步IP 資訊的封包，以及本地 GRE port，交給 pptpd 的 getPreHeader 處理。Pptpd 呼叫 pppd 建立 interface 後， 會呼叫extra/etc/ppp/ip-up 建立 routing entry，ppp interface 關閉時也會呼叫 extra/etc/ppp/ip-down 刪除 routing entry。 (6) doPPTP
分成兩步同時執行。首先是RecvServer 建立一個thread，由 test.java 中的 recvServer()函式處理。從 pptpd 抓取封 包送至SSLVPN 裝置。另外是
RecvDevice，由 test.java 中的 recvDevice() 處理。從第四步的連線抓取封包，去除 header 後寫至第五步的 pptpd socket 建立 後取得的gre socket。 流量測試的程式，依據設定檔中的 TRAFFIC 設定，呼叫 HttpClient、FtpClient、 SmbClient 執行。 而統計流量時，每個*Client 會各自計算 總共收到的byte 數，再除以時間。另外 test client 會傳進一個 AtomicLong，讓每一個 client 將他收到的 byte 數也加進去，以計算 總共的throughput。 而在SmbClient 部分，因為是使用 jcifs library 處理，沒辦法抓到一開始溝通， 登入部份的封包，所以只計算下載資料的封 包。時間上會另外計算溝通所佔的時間，計 算throughput 會扣掉所有這段時間的平均。 IVQT
PDA 或是 WiFi Phone 可以透過有線及無線 網路進行VoIP 連線，利用 SIP 協定進行撥 打電話的動作，再藉由直接或間接使用RTP 協定封包進行語音封包傳送，利用有線的方 式進行VoIP 連線不必考慮移動性的問題， 但是在無線網路環境下則不同，除了無線網 路使用的MAC Layer 協定(主要是
CSMA/CA)限制了 VoWiFi(Voice over WiFi) 使用上無法充份使用預定的頻寬，實際使用 上還有關於在無線網路下Roaming 等問 題，所以在有線及無線網路的環境下，皆可 利用各自條件不同的變因，使用PESQ 測試 語音品質的標準，測試對於待測物品的語音 通話品質影響。 本系統的軟硬體架構主要是由幾項元
5
件所構成: NIST-Net Controller，Background Traffic Generator，Azimuth Platform， Integrated Controller，以下說明各個元件所 扮演的角色以及如何進行測試與蒐集數據: NIST-Net Controller：需能支援使用 NIST-Net 控制對於網路環境的影響，如在收 話端與受話端之間Traffic 受環境影響的控 制，封包延遲或Loss 等條件，用以測試在 該環境下對於語音通話品質的影響。
Background Traffic Generator：需能支援
在不同型態的Background Traffic之下，擷取 語音相關的封包進行語音品質測試，
Background Traffic可以為HTTP,FTP, or P2P etc.，藉以觀察在不同的traffic以及不同的 loading之下對Voice Quality的影響。
Azimuth Platform(For Wireless Only)：利
用Azimuth 平台進行 RF Attenuator 控制，可 以擬似對於WiFi Phone 的移動模式，藉以 測試在移動狀態中的WiFi Phone 對於 Voice Quality 的影響，藉由本測試可以分析關於 WiFi Phone 與 AP 在移動態狀下的適應性， 由本測試可以進一步進行在移動中需進行 Roaming 時，WiFi Phone 對於 Roaming 機制 的調適，選擇以何機制和時機進行Roaming 的動作，以及在Roaming 的同時對於語音品 質的影響為何。 Integrated Controller：上面的測試都是只 有針對單一的情況進行測試，但是這樣的測 試無法進行多次的重複使用，每次進行測試 時都要重新再設定不同的環境和不同的條 件及劇本，做一次測試要花費許多的時間進 行其它工具的設定，再者在動態設定的情況 下，會造成各工具之間Timing 的非同步， 造成測試不精確，因此本項目支援的目的是 要做到在測試時可以利用單一視窗介面，進 行對WiFi Phone, NIST-Net 和 Azimuth 同步 的控制以及批次處理。
IVQT之整體系統架構如下所示：
IVQT之自動化控制架構：
IVQT之程式架構與Work Flow：
整個系統的軟體架構可以分成三部 份：Platform Controller、Traffic Controller 及Traffic Parser，初始時可以利用 tcl 進行對 VoIP 產品與 AP 間的距離，控制 Azimuth 的 RF Module 造成 Voice Phone 與 AP 之間有訊 號上的衰減等因子，透過距離與RF 訊號衰 減的公式，進行RF 訊號強度調整，同時套 用入距離動態調變，並啓動相關module(ex: 利用chariot 產生背景流量等)，而整個系統
6 啓動同時，VQT 亦開始進行 voice quality 的 量測，包含語音訊號產生、語音訊號傳送與 語音訊號品質量測等。最後會將測試的結果 及過程，將相關的記錄檔送至Traffic Parser 進行後端的分析，以及語音量測分數產生， 達成對語音訊號品質量測的結果及報告。 IVQT 之 Stack Diagram(Platform)：
IVQT之Stack Diagram(Traffic Control and Analysis)： MLPP 在現今許多嵌入式系統有著以下特 特：1）多層架構(multi-layer)，2）多種程式 語言寫成(multi-language)，三）有限記錄檔 (log)儲存空間。 析分析工具的選擇：在現有嵌入式系統評測 工具中，若有支援多層分析的工具硬是能使 分析複雜度大幅降低。其因一，分析工具學 習時間縮短和原始碼修改的複雜度降低；其 二，能夠使分析結果的格式簡化。本研究選 用的log 分析工具，皆是用於 user space 模 組，不管位於那些層或者是什麼程式語言都 能夠進行效能分析。至於對於kernel 分析的 工作，則交予picks 和 printk 兩個函式，這 兩者的使用方式與上述log 工具的運作相當 類似。
log 合併：在使用上述 log 分析工具和 printk
函式後，會發現其兩者的時間單位、日期格 式以及環境基準是不同的。前者的時間單位 為μs，日期格式為從 cpu_clock 函式所輸出 的yy/mm/dd，且所有的值皆是與 CPU 綁在 一起；後者時間單位為ns，其日期格式是由 current_kernel_time 函式所輸出的一組數 字，且所有數值皆是與kernel 綁在一起。為 了得到更精確的結果，我們會把所有分析工 具的輸出統一轉換為printk 函式的格式。 自動插 code：將分析所需的 code 插入原始 碼是一個繁覆且枯燥的工作，所以我們實作 了自動化script，使得這些分析程式碼，能 夠自動地被插入到指定的檔案或資料夾，亦 或於分析完成後自動地被移除。這些自動化 的script 能夠運行在 C、C++和 Java 上，並 能選擇輸出為log 工具格式或 printk 函式的 格式，使得整個效能分析的過程更加簡便。 多層架構與多種程式語言(multi-layer & multi-language)：在此研究中，我們同時運 行多種分析工具模組，使之能應付多層架構 與多種程式語言特性。然而，多種模組的使 用上也衍生出新的問題──必需整合所有分 析工具的結果，為解決此問題，我們需在每 一使用模組的log 都加入一紅時間標記 (time-stamped tag)。 有限記錄檔儲存空間：為客服記錄檔儲存空 間不足的問題，我們一開始只分析一個模組
7 的效能，然後逐漸’限制性地’增加更多的分 析模組和層次，以避免大量無關的結果。實 做上，對於一個使用情景，例如，網頁瀏覽， 我們首先選擇一些特定模組或其他專家所 建議的模組來進行校能剖析。令M 為被選 模組集合，S 為其中被插入檢查點 (checkpoint)的函式(function)，最後，這些含 有S 的 M 原始碼會被重建、執行並獲得分 析結果。分析結果可包含不必要的 checkpoint，這些 checkpoint 必需予以刪除， 以減少不必要的輸出。如此不斷重新生成新 的原始碼，並重覆再次執行，以得到細化分 析的結果。上述的步驟描述了一個分析階段 (圖 3.1a)，經由多次迭代，從步驟 6 至步驟 10 步，可大幅減少 log 檔所需空間。然而， 所選出的M 可能無法涵蓋一個完整的執行 流程所需的所有模組，對於這樣的情況，位 於相鄰層(layer)有關的模組 M+和含 checkpoint 的 function S+會被加入，然後開 始新的上述階段，一直重覆該做法，直到沒 有新的模組為止。以下以Android 系統為 例，詳述實作方法。 開機時間(booting time)：開機時間被定義為 從按下Android 裝置的電源開關到’啟動螢 幕’繪製完成(SurfaceFlinger.cpp 中的 SurfaceFlinger::bootFinished()執行結束)的這 段時間。其中，Wi-Fi 服務和電信服務在我 測試環境中是處於預設的’未啟動’狀態。 開機流程
按下電源開關後，Initial Program Loader (IPL) 會檢查硬體元件並啟動 Second Program Loader (SPL)，接著 SPL 會依序將 壓縮的kernel image 從 Flash 載到記憶體、 將image 解壓縮，然後執行 kernel 裡的第一 個函式──start_kernel。kernel 首先初始化各 個資料結構(data structure)和任務(task)，並 加載入驅動程式。接著，user space 的程式 依序初始化並開始執行 ──service_manager、deamon programs、 zygote 及 media_server。Zygote 繼續預載一 些Java class 和 resource，以加速 Java 應用 程式，然後啟動 system_server。 system_server 是一個管理所有的 Android 服 務的程式，。它可以掃描flash，找出所有已 安裝的應用程式，然後為每一程式創建 thread 以提供服務。其中一個重要的服務是 負責螢幕拖曳的SurfaceFlinger，在啟動過程 也結束於SurfaceFlinger 裡的 bootFinished( ) 執行完成。 圖 1 開機流程 Checkpoint 根據上述啟動程序，我們分為開機過程分為 三個區塊：導引程式、kernel space 和 user space，最初的三個 checkpoint 即被設置於這 三個區塊的邊界。然後，我們使用了階段性 插入的方法的逐啟動效能分析，並確定了以 下七個重要 checkpoint：service_manger、 daemon、zygote、media_server、JAVA class & resource、system_server 以及 SurfaceFlinger()。(圖１)為上述過程。
8 網頁瀏覽：網頁瀏覽工作啟動時間被定義為 從點擊螢幕上的瀏覽器後、在Web 瀏覽器 指定一個 URL，並完成載入指定的網頁 (BrowserActivity.java 裡的 onPageFinished( ) 執行完成)的這段時間。 網頁瀏覽流程 點擊螢幕上的瀏覽器後會產生一個系統事 件，該事件由kernel 觸控螢幕的 driver 所產 生的，然後被傳遞至ActivityManager 和 Web 瀏覽器，Web 瀏覽器就可以知道指定的 URL 並把request 發送到 Android 內建的瀏覽器引 擎──WebKit。 Webkit 的使用 HTTP protocol 來請求所需的網頁，然後將收到的 網頁解析到Document Object Model (DOM) tree。通常，一個網頁包含多個原件（例如， 圖片）當螢幕上準備畫出網頁時，Webkit 會繼續下載這些未取得的原件。 Checkpoint 在使用階段性插入效能分析時，模組 M 在 第一次迭代中只含有 Web 瀏覽器，在經過 多次反覆迭代後，我們可確定了以下重要 checkpoint：觸控式螢幕的中斷請求（IRQ）、 Web 瀏覽器和 ActivityManager 的事件處理 器、Webkit 的喚醒函式、HTTP 請求和回應 函式、DOM tree 的建立和分析以及螢幕輸 出功能。(圖 2)說明了這些重要的模組及其 相對應的 checkpoint。 圖2 網頁瀏覽流程 影音媒體播放：Android 內建的媒體播放器 為YouTube，所以在分析此情境之前，我們 必需先連接到Internet 並執行 YouTube，接 著YouTube 會把數個影片的圖示列在螢幕 上。影音媒體播放時間被定義為從觸擊螢幕 上的影片圖示到結束影片播放（即 MediaPlayer.java 中的 stayAwake()執行完 成）的這段時間。
9 圖3 影片播放流程 影片播放流程 如同網頁瀏覽，觸擊螢幕上的視訊圖示，也 會產生一個系統事件，該事件會依序地傳送 到 ActivityManager 和 YouTube，YouTube 接著會對 MediaPlayer 發出播放影片的請 求，MediaPlayer 會再要求內建的影片播放 器 PVPlayer 進行影片下載、解碼及顯示在 螢幕上的工作。最後，整個播放流程結束於 stayAwake 函式。 Checkpoint 由於 YouTube 不開放其源始碼，因此我們 無法直接對 YouTube 進行階段性插入效能 分析，因此我們必需從 Android 的 application framework 層開始插入分析。在第一次迭 代，M 包含了 application framework 層的模 組，此外，以 binary 形式發佈的 YouTube 所留下的 log 檔也須加入 checkpoint。經過 多次迭代，我們確定了以下重要 checkpoint：觸控式螢幕的中斷請求（IRQ）、 事件處理程式 ActivityManager、記錄開始下 載 YouTube 影片的 log 檔、MediaPlayer 和 PVPlayer 的建立、影音的下載及解碼、影片 的播放以及最後的 stayAwake 函式。(圖 3) 說明了重要的模組流程
4. 研究成果與討論
本計畫已經能利用相關的工具以及已 經開發的程式及模組，進行SSL VPN Tunnel 及Voice Quality 量測的工具。其中 SSL VPN Tunnel 部份，由於目前 SSL VPN Tunnel 技 術並沒有相關的標準製定，因此目前已經與 多家知名大廠合作，廠商也願意提供產品在 進行研發時將所使用的protocol stack 與本 計畫合作，在本計畫本所使用的建立SSL VPN Tunnel 技術有一定的透明度，使本計 畫中研發來給SSL VPN 相關技術所使用的 測試計畫，不但有黑箱測試，同時也有灰箱 測試的部份，有助於本計畫團隊對於SSL VPN 技術應用在學術用、商用平台上能精 確的了解其Tunnel 建立技術；而 IVQT 部 份，由於涵蓋相當大範圍的不同技術(Voice Codec, Voice Generator, Voice Quality Tester, 802.11a/b/g, Background Traffic)及開發工具 (Azimuth, Abacus, Net-NIST, IxChariot)的整 合，雖然大部份的內容都是黑箱測試，但是 對於各項通訊協定及語音編碼、語音量測等 相關的標準的了解，有助於未來本團隊在進 行相關工具開發及學術研究的延展性，同時 整合多項測試工具實行利用有限的空間，實 施更大規模的測試，有助於未來在工具開發 及執行相關測試專案時，能接受各種不同腳 本進行有彈性的調整及高度客製化。 於MLPP 中，我們也實際從現有 Android 裝 置中測得了一些有效資訊。實驗結果顯示 72%的開機時間花在 user space 環境的初始10
化，而在user space 初始化中，44.4%的時間 花在啟用背景服務程式及背景管理程式， 37%花在先行載入 Java classes 和 resources. 實驗結果並顯示，網路是影響網頁瀏覽最主 要的因素。在載入一個2128 kB 大小的網頁 的實驗環境下，螢幕繪圖顯示系統僅佔總執 行時間的5%。在 Wi-Fi 環境下播放一段 22 MB 的串流短片，系統需要花 10%的時間來 做撥放準備的動作。影片資料下載加上音訊 解碼部分的執行時間共佔了這段準備時間 的77%。從結果顯示，已能正確找出效能評 頸並應用在實際例子上。
11 5.
參考文獻
[1] Tilman Wolf and Mark Franklin, “A
Telecommunications Benchmark for Network. Processors,” Proc. of IEEE International Symposium on.
Performance Analysis of Systems and Software, 2000.
[2] M. R. Guthaus, J. S. Ringenberg, D. Ernst, T. M. Austin, T. Mudge, and R. B. Brown, “MiBench: A free, commercially representative embedded benchmark suite," IEEE International Workshop on Workload Characterization, pp. 3-14, 2001.
[3] S. Bradner, Bechmarking Terminology for Network Interconnection
Devices.RFC1242, July 1991
[4] S Bradner, J McQuaid, Benchmarking Methodology for Network Interconnect Devices, RFC 2544, March 1999
[5] D. Newman, RFC 2647 - Benchmarking Terminology for Firewall Performance, August 1999
[6] Yunfei Wu, Stephan Wong, and Stamatis Vassiliadis, “Real-Time Network
Processing: An Investigation,” [7] Manohar Castelino and Frank Hady,
“Tutorial on NPF's IPsec Forwarding Benchmark,” Network Processing Forum [8] Lee Eng Kean, Sulaiman bin Mohd. Nor,
“A Benchmarking Methodology for NPU-Based Stateful Firewall,” IEEE 2003
[9] R. Ramjee, J. Kurose, D. Towsley, H. Schulzrinne, "Adaptive Playout Mechanisms for packetized Audio Applications in Wide Area Networks", Proceedings of the Conference on Computer Communications (IEEE
Infocom), Toronto, Canada, 1994 [10] K. Fujimoto, “Adaptive Playout Buffer
Algorithm for Enchancing Perceived Quality of Streaming Apllications,” Osaka University, Japan, February 2002 [11] Henning Schulzrinne, Sankaran
Narayanan, Michael Doyle and Jonathan Lennox, "SIPstone - Benchmarking SIP Server Performance," April, 2002 [12] C. Lee, M. Potkonjak and
H.Mangione-Smith,”MediaBench: A Tool for Evaluating and Synthesizing Multimedia and Communications
Systems,” Micro-30, November 1997.SJ Shah, “Network benchmarking,”
netprl.calpoly.edu, 1997
[14] Sandra Johnson, Gerrit Huizenga, Badari Pulavarty, Performance Tuning for Linux Servers,IBM Press, May 2005
[15] Netfilter: firewalling, NAT and packet mangling for Linux,
http://www.netfilter.org [16] Tcl, http://tcl.sourceforge.net/ [17] Netperf, http://www.netperf.org/netperf/ [18] Netio, http://www.nwlab.net/art/netio/netio.html [19] ipbench, http://ipbench.sourceforge.net/ [20] EEMBC, http://www.embedded-computing.com [21] NIST NET, http://www-x.antd.nist.gov/nistnet/ [22] Azimuth Systems, http://www.azimuthsystems.com/ [23] Spirent, http://www.spirentcom.com/ [24] Radcom, http://www.radcom.com [25] NBL, http://www.nbl.org.tw
國科會補助計畫衍生研發成果推廣資料表
日期:2011/10/28國科會補助計畫
計畫名稱: 子計畫一:嵌入式網路通訊裝置應用效能評比技術與工具之研發(中心分項) (2/2) 計畫主持人: 林盈達 計畫編號: 99-2220-E-009-044- 學門領域: 自由軟體暨嵌入式系統無研發成果推廣資料
99 年度專題研究計畫研究成果彙整表
計畫主持人：林盈達 計畫編號： 99-2220-E-009-044-計畫名稱：嵌入式網路通訊裝置評比技術與工具之研發--子計畫一:嵌入式網路通訊裝置應用效能評比 技術與工具之研發(中心分項)(2/2) 量化 成果項目 實際已達成 數（被接受 或已發表） 預期總達成 數(含實際已 達成數) 本計畫實 際貢獻百 分比 單位 備 註 （ 質 化 說 明：如 數 個 計 畫 共 同 成 果、成 果 列 為 該 期 刊 之 封 面 故 事 ... 等） 期刊論文 0 0 100% 研究報告/技術報告 0 0 100% 研討會論文 0 0 100% 篇 論文著作 專書 0 0 100% 申請中件數 0 0 100% 專利 已獲得件數 0 0 100% 件 件數 4 0 100% 件 技術移轉 權利金 2617 0 100% 千元 碩士生 2 0 100% 博士生 0 0 100% 博士後研究員 0 0 100% 國內 參與計畫人力 （本國籍） 專任助理 0 0 100% 人次 期刊論文 5 0 100% 研究報告/技術報告 0 0 100% 研討會論文 0 0 100% 篇 論文著作 專書 0 0 100% 章/本 申請中件數 0 0 100% 專利 已獲得件數 0 0 100% 件 件數 0 0 100% 件 技術移轉 權利金 0 0 100% 千元 碩士生 0 0 100% 博士生 0 0 100% 博士後研究員 0 0 100% 國外 參與計畫人力 （外國籍） 專任助理 0 0 100% 人次其他成果
