## 群聯計畫
ZNS 指的是 "Zoned Namespace"，用於SSD空間管理方式。

傳統的 SSD 是以 Block的方式進行存儲，而寫入操作往往需要擦除整個塊，這種操作稱為「塊擦除」。然而，在實際應用中，寫入操作的工作負載可能導致某些塊頻繁地被擦除，這對於SSD的壽命和效能可能會產生不利影響。

Zoned Namespace 技術通過將SSD分為多個區域（Zones），每個區域包含多個連續的塊。每個區域內的塊可以按照連續的順序進行寫入，而不需要擦除操作。當整個區域內的塊都被寫滿後，該區域將被標記為「寫入封閉」，不再接受新的寫入操作。這樣的操作方式減少了塊擦除操作，有助於提高SSD的耐用性和效能。

Zoned Namespace 技術對於特定應用場景和工作負載可能特別有益，例如日誌記錄（logging）和大規模數據寫入等情況。然而，它也需要作業系統和應用程式進行相應的支援，以充分發揮其優勢。

總之，Zoned Namespace 技術是一種在記憶體領域中使用的技術，旨在優化固態硬碟的寫入操作，提高效能和耐用性。

MLP 代表多層感知器（Multilayer Perceptron），是一種常見的神經網路架構。多層感知器是一種前饋式神經網路，其主要特徵是由多個層次的神經元組成，每個層次都與上一層次的神經元相連。

多層感知器的基本結構包含三種類型的層次：

輸入層（Input Layer）： 這一層包含了神經元，每個神經元代表了輸入特徵的一個維度。例如，如果你正在處理圖像，每個像素可以是一個輸入特徵。

隱藏層（Hidden Layers）： 隱藏層是介於輸入層和輸出層之間的一個或多個層次。每個隱藏層都包含多個神經元，這些神經元的輸出會被餵給下一層的神經元。隱藏層的存在使得多層感知器能夠學習複雜的非線性關係。

輸出層（Output Layer）： 輸出層包含了神經元，每個神經元代表了模型的一個輸出。例如，在分類任務中，每個神經元可能代表一個不同的類別。

多層感知器通常具有權重（weights）和偏差（biases），這些參數用於調整每個神經元的輸入和輸出。訓練多層感知器涉及到通過反向傳播算法來調整這些參數，以最小化模型的預測與實際標籤之間的誤差。

MLP 可以應用於各種機器學習任務，例如分類、回歸和模式識別。然而，在處理複雜的問題時，可能需要更深的神經網路結構，這就導致了深度學習的興起，其中的深度神經網路（如卷積神經網路和循環神經網路）可以捕捉更高層次的特徵表示。

DL 推薦系統是指基於深度學習（Deep Learning，DL）技術所建立的推薦系統。推薦系統是利用電腦演算法和技術，為使用者提供個人化推薦的系統，其目的是根據使用者的興趣和行為，向他們推薦可能感興趣的物品，例如商品、文章、音樂、影片等。

傳統的推薦系統使用協同過濾、內容過濾等技術進行推薦，但隨著深度學習的發展，越來越多的研究開始將深度學習應用於推薦系統中，以提高推薦的準確性和個人化程度。

DL 推薦系統利用深度學習模型來學習使用者和物品之間的複雜關係，從而更好地理解使用者的興趣和行為。常見的深度學習模型包括但不限於以下幾種：

神經網路模型： 使用多層神經網路，如前饋神經網路或多層感知器，來學習使用者和物品的表示，以及它們之間的關係。這些模型可以學習出更抽象的特徵表示，從而更好地捕捉使用者的行為和偏好。

矩陣分解模型： 這類模型將使用者和物品表示為低維的向量，通過將使用者-物品交互建模為這些向量的內積來預測使用者對物品的評分或偏好。

深度神經網路模型： 如基於卷積神經網路（CNN）或循環神經網路（RNN）的模型，用於處理圖像、序列等類型的推薦問題。

自編碼器模型： 這些模型旨在學習資料的緊湊表示，從而減少噪音並揭示潛在的關係，可用於推薦任務。

注意力模型： 這些模型允許模型關注使用者行為序列中的不同部分，以更好地捕捉重要信息，從而提升推薦效果。

Transformer 模型： 像BERT和GPT這樣的Transformer模型在自然語言處理領域取得了顯著的成功，也被用於推薦系統中，特別是對文本數據進行推薦。

這些模型可以根據具體的任務和資料進行調整和組合，以建立更準確、個人化的推薦系統。然而，深度學習模型通常需要大量的資料和運算資源進行訓練，因此在設計 DL 推薦系統時，也需要考慮軟硬體協同設計，以實現快速和可擴展的訓練。

嵌入向量（Embedding Vector）是自然语言处理（NLP）领域中常用的概念之一，它是用来表示离散型数据（如单词、词汇）的低维实数向量。在NLP中，文字通常被表示为离散的标记，比如单词或字符，但是在进行机器学习和深度学习任务时，我们需要将这些离散的标记转换为连续的向量，以便计算机能够更好地处理和理解它们。

嵌入向量的主要思想是将每个离散的标记（如单词）映射到一个实数向量空间中的点，使得在这个向量空间中，具有语义相似性的标记在空间中也是相近的。换句话说，嵌入向量捕捉了标记之间的语义关系，使得相似的标记在向量空间中距离较近，从而使得模型可以更好地理解语义信息。

例如，在一个嵌入向量空间中，类似的单词（如"king"和"queen"）可能会有较近的向量表示，因为它们之间有一定的语义关系。这种表示使得机器学习模型能够更好地捕捉到这些语义关系，从而在NLP任务中表现更好。

嵌入向量通常通过预训练的方法得到，其中模型在大规模的语料库上学习将单词映射到向量。Word2Vec、GloVe和BERT等模型就是常见的用于学习嵌入向量的例子。这些预训练的嵌入向量可以作为神经网络等模型的输入，帮助提升模型在各种NLP任务中的性能。

### A swapping Behavior Analysis of Deep Learning Recommendation System Training ###
### ---------- ###
### 講稿 ###
### ---------- ###
**p3.**

推薦系統被應用在許多場景，而為了得到更好的效能，系統所蒐集使用者與物品的相關訊息越來越大，隨之而來的是需要重新訓練模型以獲得更準確的預測結果，但記憶體使用量也隨之上升。
當記憶體需求大於 physical memory 上限時，系統會使用SWAP來置換SSD作為擴張。但主要時間受SSD影響，因為NAND比DRAM執行來的耗時。SSD內部任務也會造成時間影響因素之一，比如垃圾收集(Garbage collection)也會跟用戶搶奪I/O資源，導致性能下降。

**p4.**

DLRM擁有三個部分，頂端與底端的MLP層，主要用來獲得資料集的時間類的連續特徵。而EBT是用來處理離散特徵，將其轉換成連續的特徵以便深度網路神經來更好的學習。
而目前FB的DLRM模型參數已經達到1.2兆，其中的EBT佔據了記憶體上百GB~TB的大小，因此會OS很常需要使用SWAP來讓模型獲取所需資料。

**p5.**

Fig2.2中
***右邊***的NAND快閃記憶體晶片用來儲存Data。這些晶片分為多個存儲單元，通常是SLC, MLC, TLC，表示每個單元可以儲存位元數量。
***中間***有一個控制器晶片，負責管理和控制數據的存取和流動與排成。控制器還負責實現讀寫操作的I/O請求、GC任務、錯誤修復、block管理。
***下面***有 DRAM 被用作快取，以提高讀寫性能。
***左邊***有一個介面，通常使用SATA、NVMe（Non-Volatile Memory Express）與電腦連接，以實現高速數據傳輸。
GC任務?用於回收使用過的NAND BLOCK，他會先選擇一個有效page最少的block作為victim，複製有效page到一個新的block後，回收這個含有較多非有效page的block。

**p6.**

因為不同模型擁有不同的複雜度、記憶體限制也會影響總訓練時間以及I/O的多寡。
因此這裡使用48GB的模型在128G, 32G, 16G下做訓練來做比較。
可以發現16G跟32G為128G的5.54x, 2.44x
可以得出結論：記憶體不足時，訓練時間會上升

**p7.**

因為128GB不需要SWAP，所以只需要比較32與16的。
他們所產出的總I/O量為3~6TB。
在這裡他們也測試了R/W的Latency，一開始因為mem還無滿，但在25000秒後可以發現有上升的趨勢，這裡的R/W分別為100ms和1ms。

**p8.**

這裡開始分析了大量I/O的特性及原因，以便分析swap速度慢的原因，並且觀察GC的影響。
首先這裡介紹了他們使用的HW/SW
**但我這裡發現他沒有解釋他SSD的型號，前幾天群聯內部會議的時候所提到的問題會不會與這個有關?因為無法分辨他是多少比例的SLC/TLC**

**p9.**

這裡主要差異為M1擁有64浮點數，M2有128的浮點數，導致整體模型複雜度為2倍。
而EBT占了90%

**p10.**

這裡介紹他使用的分析工具，
Cgroup是用來限制process使用資源的功能，比如說在特定core上運算、CPU時間。這裡使用其來限制總記憶體的DRAM容量
BLKTRACE為記錄kernel內部bio層的狀態工具，可以監控I/O量、延遲、大小、產能、要求
而BIO層是送往儲存裝置的最基本資料結構

**p11.**

存取模式與利用率
為了找出I/O量如此巨大的原因，所以來分析DLRM的存取模式以及page的利用率。
前述模型提到的多個EBT中，前五大的EBT佔了97.8%，因此觀察這***五個EBT就可以分析整個模型***

**p12.**

這裡他們發現每個EBT的虛擬位址是連續性的，但不同的EBT並不一定是連續性的。
因此開始分析這裡的space locality。
只要有頁面的向量被同一批access，就會算一次，
如果同時被access的vector越多，DLRM的space locality越好。
右下角的結果發現他的存取模式非常稀疏，只有3~5%的頁面會在一次批量處理中超過2個vector。
***可以得出結論：因此DLRM的space locality不強***

**p13.**

這裡開始分析實際的vector數量，方法為計算單一一個page中從swap in 到 swap out 所使用的vector總數，可以顯現頁面swap的利用率。
實驗結果發現利用率只有6~12%，
***而且右下角顯示MEMORY大小並無法決定利用率。
而是模型複雜度才會影響swap的利用率***

**p14.**

前面較低的利用率反應了一個結果，這意味著每個page利用率非常低，OS需要常常swap in out，導致巨大I/O量。
***因此這裡得到的結論為DLRM的access pattern非常的sparse，且page utilizationzo非常低。基於page的管理方式不適合DLRM的access pattern***

**p15.**

這裡開始分析I/O的行為。
因為前面提到的交換率很低，所以我們開始尋找原因是否為HW或SW的問題。
這裡提到的英文為
Q(queued), G(get requested), I(inserted), M(merged), D(issued), C(Completed),
可以發現由D2C，也就是issued 給 SSD 到完成記憶體讀取的時間為耗時最長。
***因此這裡得到的結論為花費大量的時間等待SSD完成I/O的mission***

**p16.**

這裡開始分析I/O的數量。
因為M1 32G有較大記憶體的緣故，所以可以在cache 2/3 model,
但M1 16G 有記憶體限制， M2 32G有模型複雜度的限制，實驗結果發現只能cache 1/3 model。
因為memory滿了後需要找出victim page來做置換，置換時也會同時需要寫入才能讀取，R/W比例大約為1:1
***因此這裡得到的結論為SSD是DLRM訓練的瓶頸***

**p17.**

這裡開始分析I/O的數量，
倘若I/O請求大小夠大，就能增加SSD的internal parallelism
這是為甚麼呢 主要有三點

***減少讀取/寫入延遲***：較大的I/O request size可以減少讀取和寫入操作之間的切換時間，這有助於提高整體性能。較小的I/O request size可能需要更多的I/O操作，這會增加延遲，降低效能。

***內部數據傳輸***:SSD通常具有多個通道、多個芯片、多個NAND閘或多個佇列來實現內部並行處理。當I/O request size較大時，SSD可以更容易地將數據分發到多個內部單元進行處理，這樣可以同時處理更多的數據，提高吞吐量。

***降低控制器開銷***：每個I/O request都需要SSD控制器進行管理和處理。當I/O request size較小時，相對於數據傳輸本身，控制器的開銷可能變得更加明顯，這可能導致效能下降。較大的I/O request size可以減少控制器開銷的相對比例。

如果I/O請求是短時間內發出且連續的，那BIO會把他們merge起來成大I/O請求。
實驗中顯示有83%~96%的寫被合併、
而讀取只有1.2~2.4%，這是因為他們讀取大小皆為4K，其原因是先前提到的DLRM access pattern非常sparse，而寫入大多小於32K，不利於SSD internal parallelism
而因為非常sparse，page內有許多的slot是invalid的，因此寫入更容易合併。

***因此這裡得到的結論為大多數的R/W請求都小於32K***

**p18.**

這裡想分析在訓練期間，SSD的性能是否有變化，
剛開始SSD的throughput很高(2~3GB/S)，但當達到SSD容量滿時，
throughput就會下降。
而這裡分析的原因為剛開始擁有SLC加速，但因DLRM的寫入量>>>SLC的容量，
當滿了後就會改成TLC，會變慢。
然而SSD開始GC時，需要回收block來滿足連續寫入請求，因為GC會共用SSD的內部BUS，
所以間接性影響I/O產能，大部分降速到(40MB/S)
***因此這裡得到的結論SLC無法幫助DLRM訓練，而GC也會導致性能下降***

***那我這裡其實有想問了一下CHATGPT，
若都由SLC構成的SSD會比SLC與TLC構成的SSD來比較，由SLC構成的SSD會比較快，
但相對的價格很高。***

**p19.**

大多數情況下的SSD內controller的queue深度為5~8，因此在queue的等待時間不算長。
關於前天內部會議提到的問題，我問了一下CHATGPT。
我想他這裡的解釋是
一個core可執行一個thread，如果一個thread只丟出一個I/O請求，並且時間足夠短讓該thread無法藉在短時間內在前一個I/O執行完前的時間先丟出下一個I/O請求，8個core大多數都維持8個queue depth是蠻合理的。因為他這裡最後結論是寫分析為I/O request並不密集。

**p.20**

前面有提到當I/O寫入達到SSD上限時會使用GC來回收block，當GC結束後可以發現R/W會急速上升，因此可以使用夠大的SSD來降低GC效應所帶來的延遲。

**P.21**
a,b讀取的時間<寫入的時間
可以藉由95%信賴區間的時間來比對，a,c可以得知結論較小的MEMORY會有更長的延遲，
而且較小的MEMORY會有較多的I/O量，GC也越大，
***因此這裡得到的結論為較小的MEMORY中95%信賴區間的latency會增加是因為I/O大，GC多***

**P.22**
這裡論文中蒐集了RAW後的1,2,3,5,10,50個read請求，
當收集到的read要求上升，95%信賴區間的latency會變高，直到第10個。
可以觀察10跟50的95%信賴區間差異，因此一個寫入會影響10個後續的讀取請求。
***倘若當前的系統擁有較好的應用訊息，可以對I/O進行較好的排程，就能降低latency***

**P.23**
Fio模擬：
Fio是一個可以模擬I/O的工具，他可以調整大小與讀寫的比例，在這裡實驗觀察throughput的變化。
這裡將寫入的大小比例設定為128K與4K，而讀取大小與DLRM原先比例相同。
而這裡也先將SSD以隨機填值而來模擬SWAP的步驟。
而這裡實驗結果其實與前述4.13的結果相符，整體R/W的bandwidth為22.8~28.1 (MB/S)

**P.24**
測試了不同的I/O大小，可以觀察無論R/W都可以得到結論為，
I/O請求大小越大可以帶給我們更高的bandwidth，
並且與P22比起來，setting1 與 setting2 的I/O request平均值為78.4, 41.2
(皆大於32K)
但是整體bandwidth卻會小於只有單一大小請求的32K I/O request
且若I/O size越接近NAND PAGE的大小(16K)，
Internal parallelism就會降低
***因此這裡的結論為I/O REQUEST大小相同且大於NAND PAGE的大小效能更好***

**P.25**
順序寫入與隨機寫入會大幅度影響page中invalid/valid的比例，導致GC時間的不同。
這裡發現設置1(比對先前隨機寫入)讀取快了倍率2.78、寫入提升4.37
設置4是只有128k的 I/O request，與先前差異了6.53與6.16倍
GC也會更容易回收可用的BLOCK，因為隨機寫入會分散可用BLOCK，
而且GC會依據
且GC可用的空間也會因為連續頁面更多
***因此這裡的結論順序寫入為GC提升效率而提升性能***

**P.26**
第一：
使用更大的I/O request 並且使用順序寫入。
當更大的I/O request可以提升bandwidth，
提升了bandwidth就可以提升internal parallelism與GC效率。
第二：
使用Open channel ssd or zns ssd
因為這兩個中的並沒有使用FTL(不使用位址轉換，可以主動指定位址分配)
可以安排自己的I/O任務以及減少GC的影響。
結論：
當physical memory 不足時，訓練時間會增長、I/O量大
原因為access pattern 很 sparse: 3~5% 使用大於2個vector，
page的換入利用率很低: 6~12%
也因為R/W為1:1，確認了SSD是DLRM訓練的瓶頸
throughput在SLC cache耗盡後下降，寫入量達到SSD容量後再次下降，而後受SSD的GC影響。
I/O分析則是使用更大的size以及使用順序寫入會可以減少GC影響以及獲得穩定的I/O延遲。
### 10/15Meeting

os.environ['MASTER_ADDR']=主機IP
os.environ['MASTER_PORT']=主機PORT

***shut down the firewall***
sudo systemctl stop firewalld
***shut down the firewall and keep it while reboot
sudo systemctl disable firewalld
***while running the program to verify whether it connect successfully***
telnet <IP> <PORT>

#!/bin/bash
export GLOO_SOCKET_IFNAME=enp0s31f6  ///網卡資訊

    time python3 dlrm_s_pytorch.py \
        --arch-sparse-feature-size=16 \
        --arch-mlp-bot="13-512-256-64-16" \
        --arch-mlp-top="512-256-1" \
        --data-generation=dataset \
        --data-set=kaggle \
        --raw-data-file=./criteo-kaggle/origin_train.txt \ ///training_data
        --processed-data-file=./input/kaggleAdDisplayChallenge_processed.npz \
        --loss-function=bce \
        --round-targets=True \
        --learning-rate=0.1 \
        --mini-batch-size=2 \ //batch size 
        --print-freq=1024 \
        --print-time \
        --test-mini-batch-size=16384 \
        --test-num-workers=16 \
        --rank=1 \
        --world-size=2 \
        --dist-backend="gloo" \
        --debug-mode
pid=$(ps -au | grep -m 1 blktrace | awk '{print $2}')
#kill -2 $pid

in server1
real 0m55.384s
user 3m1.492s
sys 0m2.996s

in server2
real 0m53.339s
user 3m0.926s
sys  0m2.715s

### 10/18Meeting
blktrace教程：https://blog.csdn.net/QTM_Gitee/article/details/126928506
Write the shell script to manipulate the queue of usage in SSD of disk.

#!/bin/bash

# 設定監控時間間隔（秒）
interval=10

# 設定監控持續時間（秒），或者可以根據需要設定為無限循環
duration=3600

# 設定輸出文件的路徑
output_file="iostat_output.txt"

# 開始執行iostat並將輸出重定向到文件
iostat -x $interval $((duration / interval)) > "$output_file" &

# 取得iostat的進程ID
iostat_pid=$!

# 開始執行Python執行檔，假設它的名稱為your_python_script.py
python your_python_script.py

# 等待Python執行檔完成
wait

# 終止iostat進程
kill $iostat_pid

### 10/19Meeting
1.改寫成data generator
2.測試一下 小資料集上的
單機訓練時間是否>雙機訓練時間
3.跑小資料集的雙機BLKTRACE

### 10/22Experiment

single machine
### with preprocessing
real 0m29.097s
user 0m53.966s
sys  0m2.159s

###without preprocessing
real 0m11.629s
user 0m38.735s
sys  0m1.912s

double machine in distributed training system with small dataset
###with preprocessing
\\\host machine
real 0m51.507s
user 2m58.407s
sys  0m2.912s

\\\another machine
real 0m50.190s
user 2m58.895s
sys  0m2.677s

###without preprocessing
\\\host machine
real 0m38.417s
user 2m44.658s
sys  0m2.613s

\\\another machine
real 0m35.617s
user 2m44.101s
sys  0m2.592s

hyperparameter:
11GB Dataset
epoch = 1
workers = 12 
lr = 0.1
loss = bce

double machine in distributed training system with large dataset
###without preprocessing
\\\host machine
real 4m23.454s
user 4m30.993s
sys  0m22.321s


single machine
###without preprocessing
real 0m8.403s
user 0m36.462s
sys  0.396s

### 10/23群聯月會
2.鑒於先前建沂提到的 VM 環境問題，因此我們建立一個實體機的研究環境。
而這是我們的硬體設備環境，
相較於先前的VM，目前的硬體設備的記憶體空間較小，為原先的1/7。我們想實驗是否可以依賴較小的記憶體與較快速的SSD去加速模型訓練時間。

3.我們分別使用大小資料集在雙機與單機上訓練，而這兩個表格為訓練時間的結果。
可以發現目前為止單機訓練時間比雙機快，並且我們也在實驗時發現，
在大資料集狀況下，大部分的時間都是專注於data preprocessing。因此我們特別拿出來做比較，
而data preprocessing部分實驗數據會在下次月會報告。

4.那我們日後的實驗都會著重於在實體機上進行，
並且我們想要增加epoch數量去增加模型複雜度，
用來儲存更多模型所需要的參數。
另外會研究 pytorch framework裡面的 dataloader, datagenerator API ，
這兩個部分主要的功能都是減少記憶體的負擔成本，
可以實現在記憶體不足存取整體訓練資料實仍然可以將資料分批load進memory，
一個是用於training一個是用於preprocessing。
我們會往這兩塊去看他們的實作對於分散式I/O的影響。
因為這兩塊是Pytorch裡面原本的功能，
那麼之後的研究可能就不會限於DLRM，我們可能會多方面的嘗試不同Model
**Q&&A**:
Data Generator, Data Loader 是否會有不同sequential造成不同的efficiency?
Searching for the answer.
### predo List
copy dataset to SSD //already done
set dataset path in python code
11GigaBytes dataset之preprocessing training time.
training time of epoch = 1 and 100
blktrace and iostat of SSD

### 11/18 改成分開儲存.npz檔案

 for counting in counts_generator(d_path, d_file):
            print("start counts")
            if os.path.exists(d_path + o_filename + "test" + ".npz"):
                np.savez(d_path + o_filename + "test" + ".npz",
                     counts = counting,
                     allow_pickle=True,
                     append=False)
            else:
                np.savez(d_path + o_filename + "test" + ".npz",
                     counts = counting,
                     allow_pickle=True,
                     append=True)
for i in range(7):
    for X_cat, X_int, y in data_generator(i, npzfile, d_path, d_file, batch_size):
        print("start Xcat Xint Y")
        print(d_path + o_filename + "test" + ".npz")
        print(X_cat.shape, X_int.shape, y.shape)
        np.savez(d_path + o_filename + "test" + ".npz",
                X_cat=X_cat,
                X_int=X_int,
                y=y,
                allow_pickle=True,
                append=True)
        print("finish!")

### 11/20 突然想到
去NCKU後，CCU的VPN帳號???how to access the server in the lab
VM現在是有問題嗎？我只要連5分鐘就會斷線一次QQ


### 12/5:


### 網路設定:
啟用網卡：
如果網卡處於停用狀態，啟用它：
bash
sudo ip link set dev eth0 up
請確保替換 eth0 為你的實際網卡名稱
新增 IP 和子網遮罩：
假設你要新增 IP 地址 192.168.1.2，子網遮罩 255.255.255.0：

bash
sudo ip addr add 192.168.1.2/24 dev eth0
請將 eth0 替換為你系統中的實際網卡名稱。

新增網關：
假設你要新增網關 192.168.1.1：

bash
sudo ip route add default via 192.168.1.1

新增DNS

bash
sudo resolvectl dns enp0s31f6 140.123.1.100

### 12/6Meeting:
blktrace 抓 進去硬碟前的log分析

ssd problem:
1.買新的SSD
2.清掉?
==>SSD型號?(為了知道是哪顆)
清掉(?)
查一下可不可以使用linux的指令

### 12/12:

[    0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-6.2.0-37-generic root=/dev/mapper/vgubuntu-root ro lockdown=0 quiet splash vt.handoff=7
[    0.000000] Malformed early option 'lockdown'
[    0.000000] Kernel is locked down from EFI Secure Boot mode; see man kernel_lockdown.7
[    0.023481] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-6.2.0-37-generic root=/dev/mapper/vgubuntu-root ro lockdown=0 quiet splash vt.handoff=7
[    0.073457] LSM: initializing lsm=lockdown,capability,landlock,yama,integrity,apparmor
[    0.608671] Lockdown: swapper/0: hibernation is restricted; see man kernel_lockdown.7
[    3.797355] Lockdown: systemd: /dev/mem,kmem,port is restricted; see man kernel_lockdown.7
[   64.950599] Lockdown: systemd-logind: hibernation is restricted; see man kernel_lockdown.7
[ 5649.930331] Lockdown: blktrace: debugfs access is restricted; see man kernel_lockdown.7

CHATGPT

取消 Secure Boot 模式通常需要在系統的 UEFI/BIOS 設置中進行。以下是一般步驟，請注意這些步驟可能會因製造商和型號而異：

進入 UEFI/BIOS 設置：

通常，在開機時按下或長按 DEL、F2、F10、F12 或 ESC 鍵可以進入 UEFI/BIOS 設置。這取決於你的電腦製造商。
尋找 Secure Boot 選項：

在 UEFI/BIOS 設置中，尋找類似 "Secure Boot" 或 "UEFI Secure Boot" 的選項。
禁用 Secure Boot：

進入 Secure Boot 選項後，將其設置為 "Disabled" 或 "Off"。
保存並退出：

在設置更改後，請保存並退出 UEFI/BIOS 設置。
重新啟動系統：

在重新啟動系統後，確保你的系統不再處於 Secure Boot 模式。
請注意，取消 Secure Boot 可能會影響系統的安全性，因此建議在進行此操作之前了解相關的風險。此外，某些操作可能需要管理員權限或密碼。

如果你無法找到相關的 Secure Boot 選項，建議查閱你電腦的製造商手冊或在網上搜索相應的步驟。每個製造商的 UEFI/BIOS 設置略有不同。

網路:

看起來你的系統正在使用 systemd，這是現代 Linux 系統中的一個常見初始化系統。對於自動設定 IP 地址、子網遮罩、網關和 DNS，你可以使用 systemd-networkd 服務。以下是配置的步驟：

創建一個 .network 文件，用於定義你的網絡配置。這裡假設網絡接口為 eth0。請根據你實際的網絡接口名稱進行調整。

bash
Copy code
sudo nano /etc/systemd/network/eth0.network
在 .network 文件中添加以下配置。請替換 <ip_address>, <subnet_mask>, <gateway_address>, <dns_address> 為你實際的數值。

plaintext
Copy code
[Network]
Address=<ip_address>/<subnet_mask>
Gateway=<gateway_address>
DNS=<dns_address>
例如：

[Network]
Address=192.168.1.2/24
Gateway=192.168.1.1
DNS=8.8.8.8
保存文件並退出。

重新啟動 systemd-networkd 服務以應用新的配置：

bash
Copy code
sudo systemctl restart systemd-networkd
這樣就完成了對於 systemd-networkd 的配置。請確保配置的信息是正確的，以避免網絡連接問題。

### 12/14Meeting:
blktrace intro:https://developer.aliyun.com/article/698568

windows OS 分區
==>host已刪除 尚未重新開機
==>server2 尚未刪除 尚未重新開機
自動化啟用網卡

cat /etc/netplan/01-network-manager-all.yaml
sudo vim /etc/netplan/01-network-manager-all.yaml

ip address 需更換:
server host :140.123.103.13
server 2 :140.123.103.11

network:
  version: 2
  renderer: networkd
  ethernets:
    enp0s31f6:
      dhcp4: no
      addresses:
        - 140.123.103.13/24
      routes:
        - to: 0.0.0.0/0
          via: 140.123.103.250
      nameservers:
        addresses: [140.123.1.100] 

sudo apt-get install netplan.io
sudo chmod 600 /etc/netplan/01-network-manager-all.yaml
sudo netplan apply

再來就是重新開機測試是否開機自動啟用網卡成功

sudo blktrace -w 1000 -d /dev/mapper/vgubuntu-root -o - | blkparse -i - -d vgubuntu-root
\\blktrace:
\\ -w -1000: 1000S
\\ -d : device
\\ -o -: stdout output
\\blkparse:
\\ -i -: stdin input
\\ -d : output file name

### 實驗執行順序:
先啟用blktrace，在host端執行dlrm_multi.sh，在server2執行dlrm_multi.sh。
若shut down，需要去./criteo....中，執行./rmFile.sh刪除產生的preprocessing file

### 12/14 data preprocessing in small dataset:

btt -i vgubuntu-root -l vgubuntu-root_latency



btt命令的輸出，該命令用於在Linux中測量塊I/O（輸入/輸出）延遲。
輸出顯示了不同塊I/O操作階段的延遲統計信息。以下是信息的詳細分解：
所有設備部分：

Q2Qdm：完成整個I/O請求所需的時間（從提交到完成）。
Q2Cdm：將I/O請求提交到存儲層直到I/O完成所需的時間。
對於每個指標（MIN、AVG、MAX、N），它提供了所有設備的值。

設備開銷部分：

Q2G：將I/O請求排隊在塊層直到到達存儲層所需的時間。
G2I：在存儲層中的I/O請求開始處理（I/O開始）所需的時間。
Q2M：將I/O請求提交到存儲層直到開始處理所需的時間。
I2D：將I/O請求處理到標記為存儲層完成所需的時間。
D2C：將I/O請求標記為存儲層完成直到到達塊層所需的時間。

這些指標提供了有關I/O操作不同階段的洞察。
對於每個指標，它顯示了所有設備的值。這些值包括最小（MIN）、平均（AVG）和最大（MAX）延遲，以及樣本數（N）。
這些信息對於診斷系統上與磁盤I/O相關的性能問題可能很有用。如果你有具體問題，或者有特定方面需要更多信息，請隨時提問！



training risk to fix:


圖示化blktrace的mbps與iops:
使用gnuplot套件。

vim plot.gp

配合更改blktrace所產出的file name

set terminal png
set output 'output.png'

set title 'I/O Performance'
set xlabel 'Timestamp'
set ylabel 'MBps/IOPS'

plot '253,0_mbps_fp.dat' using 1:2 with lines title 'MBps', \
     '253,0_iops_fp.dat' using 1:2 with lines title 'IOPS'

再使用

gnuplot plot.gp

產生了output.png


blktrace的blkiomon指令可以產生各階段的 histogram

### 1/12:
host:


server2:


### 2/20:
3.7GB



## source code:
https://github.com/facebookresearch/dlrm/tree/main

## Meeting Video
https://youtu.be/9YSiixl_V8A

### ToDoList

sequential shuffle 投影片在p.1之前(先前做過的投影片) done
前情提要 dlrm + blktrace done
這時間伺服器跟訓練上的所有問題
硬體設備比較表格 done
資料集差異 done
3.7GB斷電 done
結果分析(硬體設備) done