# 祥瑋程式
* 安裝過程遇上的問題:
* Q1: 使用requirements.txt安裝會跳出**python 3.7.0版本過低**的錯誤。
* A: python 3.7.0 => python 3.7.6
* Q2: 安裝過程出現 **ERROR:Failed building wheel for mpi4py**。
* A: 程式碼並沒有用到mpi4py，所以**將requirements.txt裡的mpi4py==3.0.3移除**。

完成上列兩件事後可照[Github](https://github.com/ice1757/dqn-cache-replacement)開始測試。

# 實驗1:DQN與LeCaR比較
(註:[DQN](#DQN概述)為本篇方法，[LeCaR](#LeCaR概述)為DEAP提供)
本章使用本篇方法**DQN_trace**和**DEAP_trace**做比較

## 實驗1結果(命中率):
* DQN_trace
* snm_50_l9666.txt (cache_size=10)
* DQN: 62.09%
* LeCaR: 64.18% **(win)**
* zipf_50_9000_cps.txt(cache_size=10)
* DQN: 55.73%
* LeCaR: 58.62% **(win)**
* zipfc2_50_9000_cps.txt(cache_size=10)
* DQN: 43.04%
* LeCaR: 45.19% **(win)**

* DEAP_trace
* grep.csv(cache_size=10)
* DQN:由於object數太多無法執行(2^32^個相異object)

* LeCaR:35.36%

## 實驗1記錄:
方法:把同一筆trace格式做轉換後分別丟入DQN、LeCaR並記錄結果。(例如:將[DQN_trace格式](#DQN_trace格式)轉成DEAP_trace格式)

## 實驗2 調整zipf_para , content type , cachesize 測試
兩者經過實驗看起來LeCaR略勝一籌原因有下面幾點:
- 雖然實驗兩者勝利次數都是12次，但就執行時間來看 LeCaR只需要不到一分鐘，而DQN最久的一次測試需要2.5小時，且如果參數(content_type, cache_size)調大，會使記憶體使用量和執行時間大幅提升以致無法測試。
- zipf_trace
- SNM_trace

## 實驗2紀錄:
實驗問題:
- 只要cache size大 或是content type大，DQN方法就會需要佔用非常大量的記憶體，所以很多實驗沒辦法跑。比如:z2_10000_1000(參數_內容數量_快取大小)需要3.64TB記憶體空間
- 如果要重現實驗要記得把虛擬記憶體空間條大，目前測試調成64G
- 有些trace會出bug，目前還不知道原因，但可以透過從新製作相同參數的trace搞定。

實驗3:
有問題的Trace:

---------
# 附錄(以下都是補充 不用看)

## DQN概述
* State:(頻率排名,親近度,長期頻率,中期頻率,短期頻率,請求內容,請求內容大小,快取中內容,快取剩餘空間)
* 頻率排名:從請求開始到目前為止的request次數排名，次數越多排名越高。
* 親近度:自從上次request以來經過的time step
* (短,中,長)期頻率:觀測區間使用頻率，從目前時刻往前看1N~C~ , 2N~C~ , 3N~C~步的使用頻率。
* 請求內容:
* Action
* Reward
## DQN_trace格式
分為兩個資料**req_trace**和**req_data**，前者儲存**請求序列**、後者儲存**object的大小資訊(object,Size)**。

## LeCaR_trace格式
req1(換行)
req2(換行)
req3(換行)
....

## 學長request解釋

- Dyna-Zipf-1
- 可調參數:zipf參數、流行度排名。
- 固定**zipf參數**，但**流行度排名**會在三個時間點發生變化
- Dyna-Zipf-2
- 可調參數:zipf參數、流行度排名。
- **Zipf參數**和**流行度排名**會在三個時間點變化。
- SNM(Shot Noise Model)
- 可調參數:req_kind
- Zipf補充
- zipf參數:
- k=排名、z=zipf參數
- 不同排名k的object使用頻率為(1/k)^z^
- z越大，不同排名object的使用頻率差距越大。 例如:**排名1的object**的使用頻率占比越高。
- 流行度排名:
- [1,2,...,n]用np.random.permutation將順序打亂。

## 代辦
* ~~看懂DQN_trace格式~~
* ~~把LeCaR跑起來~~
* ~~看懂LeCaR_Trace~~
* ~~轉換的程式~~
* 蒐集CDNs trace
* 看懂CDNs trace格式
* 觀察大部分CDNs 有什麼特性（看看有沒有什麼可以利用的 比如zipf,object_size）
* 看懂LeCaR程式碼
* 做簡易admission LeCaR
* 搞清楚目標是什麼 比如說訂好一個QoS評分.因為在CDNs也不確定是不是命中率最重要，因為只要塞小object命中率自然會高 那大object好像就被忽略了，會不會有缺點。
* 思考重用距離套在LeCaR
* 思考對size分部建模
* 思考能不能利用zipf特性改善LFU效果，因為LFU就是在把頻率高的囤積起來。
* https://github.com/sylab/LeCaR

* 生測試資料
* "相異object數=(50,100,500,1000,5000,10000,50000,100000)" 8種

* zipf-1:(object數 8種)*request數
* zipf-2:
* snm:
* content_size:([1:0:0],[8:1:1],[1:1:1])*"相異object數=(50,100,500,1000,5000,10000,50000,100000)"