# [Oasis: Performance Matching IoT System Emulation](https://ieeexplore.ieee.org/abstract/document/9582250)

## Abstract

* 隨著設備越來越多，希望可以評估 IoT 設備的性能和擴展性
* 使用模擬降低成本，但通常無法評估設備性能
* 提出 Oasis，利用 Docker 來模擬設備，藉由分配資源來達到模擬性能

## Introduction

* 隨著物聯網高速發展，出現了部屬前評估系統的需求
* 利用模擬，通常會因為抽象化過程導致失去真實性
* 利用真實設備太過昂貴
* 利用 Container 模擬設備，可以設置設備的連接關係和能力
* 提出 Dynamic Resource Allocation 來控制設備的計算能力與網路容量
* 根據實驗，計算能力和網路性能的誤差是 8.77% 和 2.02%

## Related Work

* EmuEdge 用 netns 做網路模擬，用 Xen 做設備模擬
* VM 模擬技術會導致性能降低，無法評估也無法大量模擬
* 使用 Container 模擬，多個容器共享一個 OS
* 將 OS lib, tools 和 applications 都封裝成 process
* 與大部分現有的 Container 模擬不同，Oasis 目標是性能匹配的模擬

## Challenges in Performance Matching

* 正常來說，server 的資源比 IoT 設備好很多，可以藉由調整容器大小來匹配真實性能
* 為了瞭解設備性能，做了一個小實驗
* Comp-Perf: 計算第 N 項費式數列，紀錄花費時間
* Net-Perf: 計算從 A 節點到 B 節點花費的時間(速率)
* 先使用真實設備跑 Comp-Perf
* Raspberry Pi-3 with four 1.2 GHz ARM processors and 1 GB of memory
* Firefly RK3399 with six 1.8 GHz ARM (big-little architecture) processors and 4 GB of memory
* 46.6 秒和 6.5 秒
* 接著在 Docker 裡面跑，隨時調整容器大小，直到和剛剛的時間一樣
* 
* 用這種方式就知道設備的計算能力大概佔主機的多少
* 同樣的方式跑 Net-Perf 可以測量 bandwidth 的部分
* 
* 實驗結果發現，不管是哪個設備，當你調整 CPU 到可以匹配計算能力的時候，傳輸能力就會更好或更壞，無法同時匹配兩者

## Oasis Design

* 前面的實驗可以發現，藉由調整容器大小來匹配性能是有難度的

### Analyzing Challenges

* 模擬的情況可以分成四種
* 1a: 計算能力剛好時，網路太慢
* 1b: 網路剛好時，計算能力太快
* 2a: 網路剛好時，計算能力太慢
* 2b: 計算能力剛好時，網路太快
* 網路能力太好可以藉由 Linux traffic control 調整，但計算能力就沒辦法了
* 動態調整容器大小要考慮到兩個問題
* 準確性：不針對應用程式，配置匹配能力的容器大小
* 即時性：調整容器會造成延遲

### Dynamic Resource Allocation Algorithm

* 根據輸入，同一個程式可能是來不及算或是網路來不及傳
* 因此同一個設備，根據不同輸入需要配置的容器大小都不同
* 提出一個 DRA 演算法，演算法分成兩個階段
* 
* 學習階段
* 在真實設備上，丟入各種不同的輸入，並將計算速率和網路速率全部記錄在一張表之中
* 同時在模擬環境中用相同的輸入去算速率，不停調整容器大小直到速率最接近時，將容器大小也記錄在表之中
* 模擬階段
* 一次模擬各種大小的容器，根據接受到的輸入把工作派給適合的容器運作
* 太久沒有使用到的容器可能會被 free，時常被使用的容器可能會架設更多
* 利用這種預啟動的方式來降低延遲

### Scalable and Performance Matching Design

* 實作上使用 docker swarm 來一次部屬多個容器
* 控制器根據 DRA 演算法去控制容器

## Evaluation

* 一樣使用 Raspberry Pi-3 和 Firefly 用來評估結果
* 應用程式先接收一堆圖片，接著將他們轉成灰階圖，評估網路和計算能力
* 對於網路能力還使用 iperf 測試

### Performance Matching

* 
* IPS: 每秒處理圖像、NTR: 網路傳輸速率
* Raspberry Pi-3 的計算和網路性能，最大差異分別是 14.2% 和 2.7%
* Firefly 的計算和網路性能，最大差異分別是 2.2% 和 4.2%

### Network Intensive Processing

* 
* CPS: 每秒 iperf 指令數、NTR: 網路傳輸速率
* 流量限制太低時會有高的錯誤率，但流量增加之後傳輸速率就變得穩定

### Scalability

* 
* 比較無限制的容器和 Oasis 限制的容器，同一個機器能部屬的數量差距
* 至少要能跑每秒 26 個 50 KB 的圖

## Conclusion and Future Works

* 利用 Docker 容器模擬 IoT 設備
* 提出 DRA 演算法調整容器能力，能更符合現實設備的性能也可以部屬更多裝置。
* 未來希望可以加入機器學習來增強 DRA

###### tags: `paper`