本章將介紹主要測試方案及其具體配置和結果。在介紹實際測量結果之前，將盡可能總結被測設備的特性。最后，將對結果進行分析，并概述由于高速緩存一致性問題造成的延遲方面的主要瓶頸，提出減少延遲的解決方案，并解釋用于發(fā)現(xiàn)和緩解問題的方法。
設備
用于智能設備的 SABRE 板
實際參與所有測試和分析的主要設備是用于智能設備的恩智浦快速工程智能應用藍圖（SABRE）板：它是基于i.MX6四核處理器的開發(fā)板，具有低功耗特性、多媒體和圖形功能的多核處理器。其主要特點：
- 四核 ARM Cortex-A9 （2 CPU)
- 多級內存系統(tǒng)
- 動態(tài)電壓和頻率縮放
- 強大的圖形加速
- 接口靈活性
- 整個設備的集成電源管理
- 先進的硬件支持的安全性
SABRE板提供了低成本開發(fā)平臺，包括i.MX6處理器的所有主要功能以及高速接口和存儲器。它的硬件設計文件和許多附件板都很容易獲得，這些附件板可與SABRE板配合使用，提供額外的功能，如多點觸摸顯示和Wi-Fi連接。
此外，作為恩智浦（NXP）社區(qū)支持的SABRE板，還提供針對Android和Linux的優(yōu)化BSP以及優(yōu)化的視頻、語音和音頻編解碼器。具體來說，還提供了與Yocto項目一起使用的BSP層，可用于獲得工作和優(yōu)化的 Linux 發(fā)行版。
SABRE板為智能設備提供的主要功能包括
- i.MX6 QuadPlus 1 GHz 應用處理器
- 1 GB DDR3，533 MHz
- 8 GB eMMC NAND
- 兩個 SD 卡插槽
- 串行高級技術附件 (SATA) 22 針連接器
- HDMI 連接器
- 兩個低壓差分信號 (LVDS) 連接器
- 液晶顯示器 (LCD) 擴展端口連接器
- 串行攝像頭連接器
- 兩個 3.5 毫米音頻端口（立體聲 HP 和麥克風）
- USB On-The-Go (OTG) 連接器
- 通過 USB uAB 設備連接器調試輸出
- 千兆以太網(wǎng)連接器
- 聯(lián)合測試行動組 (JTAG Joint Test Action Group) 10 針連接器
- mPCIe 連接器
- 3 軸加速計
- 數(shù)字羅盤
商業(yè)設備
測試過程中也使用了商業(yè)設備。雖然不會指明供應商名稱，但下文將介紹主要設備特性，從現(xiàn)在開始，參與基準測試的這兩款設備將被稱為 SBC-1 和 SBC-2。
- SBC-1
- i.MX6 QuadPlus 800 MHz 應用處理器
- 2 GB DDR3
- 8 GB eMMC NAND
- SD 卡插槽
- 2 個 USB 接口
- 觸摸屏
- 通過通用異步收發(fā)器（UART）進行調試
- 3 個千兆以太網(wǎng)連接器
- SBC-2
- i.MX6 QuadPlus 1 GHz 應用處理器
- 1 GB DDR3
- 8 GB eMMC NAND
- SD 卡插槽
- 1 個 USB 接口
- 觸摸屏
- 通過 UART 調試
- 2 個千兆以太網(wǎng)接口
測試方案和結果
測量Linux實時系統(tǒng)的性能時，可以采用不同的方法。最直接的方法是在系統(tǒng)運行將在最終產(chǎn)品中執(zhí)行的實際應用程序時測量實時延遲。當然，采用這種方法可以獲得最可靠的結果，反映真實系統(tǒng)的運行情況。
然而，由于各種原因，并非總能遵循這種方法。事實上，可能會出現(xiàn)這樣的情況：沒有最終的應用程序，或者最終的應用程序無法發(fā)布用于測試。
當最終應用程序無法用于測試時，可使用合成基準來估計系統(tǒng)在不同負載情況下的表現(xiàn)。按照這種方法，要測試系統(tǒng)的實時性能，最重要的步驟之一是定義基準結構，確定正確的 測試場景。
事實上，在沒有實際最終應用程序的情況下，確定由設備執(zhí)行的正確基準很重要，因為在基準測試套件方面有許多選項。有時，如果要制作驗收測試套件，主要目的是評估不同供應商提供的不同硬件平臺，那么創(chuàng)建易于重現(xiàn)的測試用例是非常有用的，這樣當某些功能與預期不符時，供應商就可以執(zhí)行相同的測試。
在這項工作中，可重復性是開發(fā)各種基準的關鍵概念。因此，所有使用的測試程序都選擇了開放源代碼，以便輕松重復所有測試用例。
本節(jié)將詳細介紹主要的測試場景、使用的軟件及其配置。然后，將對獲得的結果進行介紹和分析。
值得注意的是，為了簡單起見，將只報告最有意義的結果，但這并不意味著信息的丟失，因為所制作的匯總圖包含了所有有用的數(shù)據(jù)。
實時任務
圍繞主要目標（即測試實時系統(tǒng)性能），為有效測試設備，需要一個能夠測量調度延遲的實時任務。Linux 實時系統(tǒng)中最常用的調度延遲測量程序是Cyclictest。因此，在測試執(zhí)行期間，所有情況下都使用 Cyclictest模擬了實時進程，除了模擬實時進程外，Cyclictest還幫助收集了本章將要報告的所有延遲信息。
Cyclictest提供了許多可用于創(chuàng)建不同測試場景的選項，但在幾乎所有測試案例中，其選項都保持不變。
具體來說，Cyclictest 的執(zhí)行命令如下
cyclictest -S -l "loops" -m -p 90 -i "interval" -q -h400 > output
Cyclictest 選項
- -S選項
- 在所有線程中保持指定的優(yōu)先級相同。
- 設置線程數(shù)等于可用 CPU 數(shù)。
- 將每個線程分配給特定處理器（親和性）。
- 使用 clock_nanosleep 代替 POSIX 間隔計時器。
- -l 要執(zhí)行的循環(huán)次數(shù)。
- -m 鎖定當前和未來的內存分配，防止內存被分頁到交換區(qū)。
-
- p 90 設置線程優(yōu)先級。
- -i "時間間隔 "設置線程的基本時間間隔，單位為微秒。
- -q 安靜運行測試，退出時打印摘要。
- -h 400 將延遲直方圖輸出到 stdout，400是以微秒為單位的最大跟蹤時間。
通常，當實時應用程序必須在目標硬件上運行時，它的特點是有明確的周期。但是，如果我們有興趣執(zhí)行未完全定性的合成基準，比如本例中的情況，那么了解實時應用程序在不同時間段內的系統(tǒng)運行情況可能會很有趣。
因此，所有執(zhí)行的測試都重復了多次，每次都對實時任務施加了不同的周期。更詳細地說，所有測試都重復執(zhí)行了三次，將實時任務設置為以下周期：
? 100μs
? 1ms
? 10ms
當然，實時任務周期可以通過 Cyclictest -i "interval"選項輕松設置。
選項可以輕松設置實時任務周期，因此只需運行三次帶有不同"interval"值的命令即可。
CPU 幾乎處于空閑狀態(tài)
第一種測試情形，顧名思義，其特點是只運行實時任務，而沒有任何其他特定的CPU負載。事實上，在沒有任何負載的情況下運行 Cyclictest 只能提供延遲的下限。
不過，運行Cyclictest可以幫助了解系統(tǒng)是否運行正常，系統(tǒng)設置是否正確。事實上，正如下面的測試案例所示，如果被測系統(tǒng)設置不當，即使 CPU 處于空閑狀態(tài)，也會出現(xiàn)明顯的調度延遲。
現(xiàn)代Vanilla Linux內核提供了三種主要的搶占選項，以改善系統(tǒng)延遲：
- config_preempt_none： 無強制搶占（通常用于服務器）
- CONFIG_PREEMPT_VOLUNTARY：自愿內核搶占（通常用于臺式機）
- config_preempt： 可搶占的內核（通常用于低延遲桌面）
除了標準Vanilla內核提供的功能外，如果系統(tǒng)需要更多的實時功能，最常用的改進Linux實時功能的策略是在內核源代碼中打上PREEMPT_RT的補丁集，使其更具有搶占式功能。因此，使用PREEMPT_RT補丁的內核會在內核搶占選項中增加一個額外選項，即PREEMPT_RT_FULL或完全搶占內核(RT Fully Preemptible Kernel)。
為了了解配置了PREEMPT_RT_FULL的內核所帶來的主要改進，我們編譯了Sabre主板的基本內核版本，并收集了在該內核上運行的 Cyclictest 的結果。
從下圖可以看出，在無PREEMPT_RT_FULL內核上運行的Cyclictest的最大延遲時間為1.2ms，而在完全搶占式內核（RT）上運行的 Cyclictest 的最大延遲時間僅為 26μs。
測試中使用的不帶PREEMPT_RT_FULL選項的內核已被配置為CONFIG_PREEMPT，即使用標準Linux內核提供的最搶占式選項。
在 4.2 中報告了使用的兩個內核版本，第一個版本指的是啟用了CONFIG_PREEMPT的標準內核，而后者是使用 PREEMPT_RT 和激活了完全搶占式內核 (RT) 選項的內核。
root@imx6qdlsabresd :~# uname -a
Linux imx6qdlsabresd 4.1.44 - fslc+g6c1ad49 #1 SMP PREEMPT Thu Jul
19 15:16:14 UTC 2018 armv7l GNU/Linux
root@imx6qdlsabresd :~# uname -a
Linux imx6qdlsabresd 4.1.38 - rt45 -fslc+gee67fc7 #1 SMP PREEMPT RT
Mon Mar 19 22:27:10 CET 2018 armv7l GNU/Linux
回到實際的內核配置，即啟用PREEMPT_RT_FULL的內核，也就是提供最佳實時功能的內核，其他被測設備也在使用該內核。
下圖顯示了所有內核的最大延遲值。該條形圖是根據(jù)上圖所示的延遲圖繪制的，并考慮了所有內核中的最大延遲值。事實上，在處理實時系統(tǒng)時，最大值通常能提供更多信息，即系統(tǒng)是否會錯過最后期限。
在第一種情況下Sabre電路板的性能略高于其他設備。造成這種性能差異的原因有很多，例如：硬件配置不同、內核版本不同等等。最后，考慮到不同的線程間隔，即實時時間段（100μs、1ms、10ms 和100ms），Sabre主板顯然在線程間隔增加時取得了更好的延遲結果。最后一點可能是合理的，因為當線程間隔增加時，系統(tǒng)的壓力應該較小。
下表提供了有關平均延遲、最小延遲和方差的其他信息，為簡單起見，這些信息僅指 Sabre板，因為它代表了主要的被測設備。
IPC壓力
測量空閑系統(tǒng)的實時延遲用處不大，因為CPU只需處理實時(RT)應用程序。因此，在第二種情況下對CPU施加壓力，以獲得更真實的結果。
正如已經(jīng)分析過的，rt-tests 套件也提供了適用于這種情況的工具，特別是Hackbench實用程序可用作CPU 壓力源來模擬某種系統(tǒng)負載。當然，這種情況遵循了合成基準的理念，創(chuàng)建了更真實的情況，即使用Hackbench來模擬系統(tǒng)負載?；旧?，該測試用例使用實時應用程序來測量延遲，而Hackbench則對內核施加壓力。更詳細地說，測試條件是通過執(zhí)行以下命令創(chuàng)建的：
$ hackbench -P -g 15 -f 25 -l 200 -s 512 \&
$ cyclictest -S -l "loops" -m -p 90 -i "interval" -q -h400 > output
? - P 表示使用進程作為發(fā)送方和接收方。
? -g 15 創(chuàng)建 15 組發(fā)送方/接收方。
? -f 25 規(guī)定每個發(fā)送方和接收方應使用25個文件描述符。
? -l 200 規(guī)定每個發(fā)送方/接收方必須發(fā)送200條信息。
? -s 512 設置每條信息的發(fā)送數(shù)據(jù)量為512字節(jié)。
總之，使用Hackbench和所述選項，Linux內核必須管理15組進程，這些進程使用25x2=50個文件描述符發(fā)送 200條信息，每條信息512字節(jié)。當然，這種測試情況會導致CPU利用率很高，使系統(tǒng)壓力很大。下圖顯示了所有內核和不同線程周期的最大延遲。
同樣在這種情況下，平均而言，Sabre板的性能略高于其他單板計算機。當然，第二個測試案例更加真實，因為使用 Hackbench 模擬了系統(tǒng)負載并達到了較高的 CPU 利用率。
分析所獲得的結果，在這種情況下發(fā)生了一些非常"奇怪"的事情，事實上，間隔時間較短的線程比間隔時間較長的線程表現(xiàn)更好，也就是說，喚醒頻率較低的線程獲得了更高的延遲。由于這種"奇怪"的在這種情況下，看看下圖中 Sabre 板的延遲圖可能會很有趣。
觀察圖4.7b和圖4.7c之間的差異，在最大延遲和可變性方面，所獲得的行為并不容易解釋。事實上，乍一看，當線程的時間間隔較大時，我們可能會期望獲得較低的延遲，也就是說，由于線程的時間間隔較大，CPU 的壓力較小，其性能應該更好。
然而，得到的結果與我們的預期完全相反，經(jīng)過一番調查和分析，我們找到了這種"奇怪"行為的原因，實際動機將在第4.3.1節(jié)中解釋。目前，我們認為造成這種行為的可能原因是緩存丟失問題。事實上，如果實時線程的執(zhí)行頻率較低，而其他進程（Hackbench或內核本身）被允許在中間執(zhí)行，那么當實時線程應該被執(zhí)行時，可能會出現(xiàn)緩存未命中的情況，因為中間執(zhí)行的其他進程已經(jīng)替換了一些緩存行。
參考資料
- 軟件測試精品書籍文檔下載持續(xù)更新 https://github.com/china-testing/python-testing-examples 請點贊，謝謝！
- 本文涉及的python測試開發(fā)庫 謝謝點贊！ https://github.com/china-testing/python_cn_resouce
- python精品書籍下載 https://github.com/china-testing/python_cn_resouce/blob/main/python_good_books.md
- Linux精品書籍下載 https://www.cnblogs.com/testing-/p/17438558.html
網(wǎng)絡壓力
由于現(xiàn)在幾乎所有設備都有網(wǎng)絡連接，因此研究一下系統(tǒng)在網(wǎng)絡負載下的表現(xiàn)可能會很有意義。
當然，系統(tǒng)需要管理網(wǎng)絡連接的情況多種多樣，為此，我們定義并分析了不同的測試用例：具體來說，我們定義了兩個主要基準，每個基準都概括了不同的情況，并將在下文中介紹。
Ping
第一個概述的場景涉及網(wǎng)絡連接，使用著名的Ping網(wǎng)絡實用工具作為背景系統(tǒng)負載。
Ping是一種軟件工具，廣泛用于測試互聯(lián)網(wǎng)協(xié)議（IP）網(wǎng)絡中主機的可達性。Ping使用互聯(lián)網(wǎng)控制消息協(xié)議（ICMP）回波請求來檢查另一臺目標主機的可達性。
下圖顯示了國際標準化組織開放系統(tǒng)互連 (ISO/OSI) 模型，從中不難看出，ICMP 可被視為使用 IP 和以太網(wǎng)幀的第三級協(xié)議，具體來說，它具有以下特性：
- 不是傳輸協(xié)議。
- 不用于在設備間交換數(shù)據(jù)。
- 與傳輸協(xié)議相比，它產(chǎn)生的內核開銷較低。
- 與使用原始IP數(shù)據(jù)包幾乎相同。
總之，Ping 的特性在某種程度上可以用來模擬原始網(wǎng)絡流量，如處理Ethercat、Modbus等網(wǎng)絡協(xié)議時產(chǎn)生的網(wǎng)絡流量。
執(zhí)行以下命令創(chuàng)建實際網(wǎng)絡負載：
$ ping <addr > -l 65500
? -
? -l 65500 設置 ICMP 報文的最大字節(jié)數(shù)。
Ping命令與Cyclictest一起執(zhí)行，以測量實時延遲，下圖報告了所有內核的最大延遲值。分析結果表明，網(wǎng)絡負載對實時性能影響不大，SBC-2設備的最大延遲時間約為70us。SBC-2的性能比其他設備差，但仍然獲得了可以接受的延遲值。
Netcat和磁盤操作
對網(wǎng)絡能力的要求越來越高，為了模擬這種系統(tǒng)負載，使用了實用程序Netcat。它可以使用TCP或用戶數(shù)據(jù)報協(xié)議 (UDP) 通過網(wǎng)絡連接進行讀寫，Netcat 工具還可用于傳輸要保存在存儲設備上的文件。
利用這一功能還進行了其他一些測試，以了解系統(tǒng)在處理網(wǎng)絡負載和磁盤存儲操作帶來的額外壓力時的性能。更詳細地說，嵌入式設備被要求每秒接收并存儲1Mb的數(shù)據(jù)，但在這種情況下，系統(tǒng)并不被要求立即存儲接收到的數(shù)據(jù)，而是讓Linux內核緩存即將到來的數(shù)據(jù)，并自動管理數(shù)據(jù)存儲過程。
下圖顯示了所有內核的最大延遲時間，從中可以看出Sabre電路板的性能優(yōu)于其他設備，在這種情況下，SBC-1的延遲時間最差。
此外，從圖4.9和圖4.10之間的差異可以看出，SBC-2設備的結果比簡單Ping負載情況下的結果要好，但這并不容易解釋。當然，許多參數(shù)都會影響這些結果，但由于延遲時間沒有超過100μs，因此無需進行額外分析即可接受這些結果。
4.2.5 磁盤壓力
盡管Netcat測試已經(jīng)寫入了磁盤，但本測試案例的主要想法是對存儲能力進行高強度的壓力測試。
事實上，在對Linux內核如何管理存儲設備進行分析后，本節(jié)創(chuàng)建的測試通過寫入1Mb的數(shù)據(jù)塊來執(zhí)行，并提交每個數(shù)據(jù)塊以確保其確實寫入磁盤設備。
分析得到的結果：通常情況下，Sabre主板的結果最好，最大延遲約為70us，而SBC-2的延遲值最差，最大延遲為123us，最后，SBC-1沒有超過100 us的調度延遲，在前面提到的兩種設備中處于中間位置。
4.2.6 VLC視頻
最后一個測試場景試圖涵蓋設備必須與實時應用程序一起管理視頻流的使用情況。使用著名的VLC媒體播放器播放分辨率為720x480的MPEG文件，VLC與Cyclictest 模擬的實時進程同時執(zhí)行。
該測試場景僅在Sabre板上進行了測試，下圖顯示了最大延遲：可以看出，當實時線程的周期變大時，延遲會增加，就像 Hackbench 在系統(tǒng)負載時發(fā)生的情況一樣。
4.3 測試分析
在看過各種測試場景及其結果后，可以說幾乎在所有情況下，所分析的系統(tǒng)都能保證延遲不超過100us。然而，在某些情況下，系統(tǒng)會出現(xiàn)更大的延遲和"奇怪"的延遲。特別是當實時應用程序的周期較大時，會出現(xiàn)超過 100us 的延遲。
乍一看，這種情況不容易解釋，因為當實時任務的周期較大時，系統(tǒng)的壓力應該較小。然而，當系統(tǒng)需要處理其他任務時，才會出現(xiàn)較高的延遲時間，也就是說，當系統(tǒng)只需管理實時應用程序而無需處理其他任務時，就不會出現(xiàn)這種 "奇怪 "的行為。
正如預期的那樣，為了更好地了解發(fā)生了什么以及為什么會出現(xiàn)這些 "奇怪 "的行為，我們使用了第 3.3 節(jié)中描述的剖析方法進行了額外的調查。下文將介紹這些進一步的分析，然后將介紹這些問題的一些解決方案，并將獲得的新結果與 "奇怪 "的舊結果進行比較。
4.3.1 緩存一致性問題
為了研究線程周期較長時出現(xiàn)的問題，之前的大多數(shù)測試都是在 DS-5 Streamline后臺運行時重新執(zhí)行的。
通過這種方式，在接受剖析工具帶來的一些開銷的情況下，可以收集到所有需要的信息，從而更好地了解發(fā)生了什么。基本上，在Streamline收集剖析信息時，測試已經(jīng)運行了很多次。
下圖可以看到Streamline，從中可以提取與每個進程的緩存缺失相關的信息（見右上角）。多次運行測試并收集與高速緩存未命中和命中相關的信息，同時考慮到高速緩存的訪問次數(shù)與實時時間段無關，因此可以得到圖 4.14 所示的圖形：它顯示了延遲值與高速緩存未命中百分比的某種 關聯(lián)。
總之，從圖4.14中可以看出，當Cyclictest運行的周期越長，緩存丟失的百分比就越高，延遲也就越長。因此，當允許其他進程在兩次 Cyclictest 執(zhí)行中間運行時，緩存丟失的百分比會增加，延遲也會增大。
4.3.2 可能的解決方案
在前面的測試中，我們發(fā)現(xiàn)當實時線程的運行時間較長時，緩存丟失的比例會增加。盡管所有測試都使用了Cyclictest，使每個線程始終在同一個內核上運行，以避免緩存出現(xiàn)更多問題，但還是出現(xiàn)了這種情況。
不過，即使Cyclictest的線程始終運行在同一個內核上，其他進程和Linux內核本身也可以在每個內核上不一致地運行。
最后一點可以用來改善延遲，方法是限制其他進程和Linux本身只在某些內核上運行，而將其他一些內核空出來，供實時進程使用。
在Linux提供的眾多自定義選項中，還可以設置每個進程在哪個內核中運行。在運行系統(tǒng)中，可以使用taskset命令設置進程的親緣性，并指出任務的進程標識符（PID）和親緣性掩碼，即進程ID和該進程可以運行的內核。
因此，乍一看，我們可以嘗試創(chuàng)建一些shell腳本，使用taskset將所有進程分配到給定數(shù)量的內核上。然而，在使用 Streamline 對系統(tǒng)進行剖析后發(fā)現(xiàn)，一些內核線程并不受 taskset 的影響。
因此，經(jīng)過進一步調查，我們發(fā)現(xiàn)了一種限制整個Linux內核在給定內核數(shù)上運行的替代方法。具體來說，要限制整個Linux內核只在指定的內核上運行，可以使用isolcpus啟動參數(shù)。后者是內核啟動參數(shù)之一，可將某些內核與內核調度隔離開來，也就是說，將某些內核從Linux系統(tǒng)中解放出來是非常有用的。
因此，為了了解如何讓某些內核不受Linux系統(tǒng)的影響，我們重新執(zhí)行了第4.2.3節(jié)中的測試（報告延遲超過 100us 和 "奇怪 "行為的測試），只讓兩個內核執(zhí)行實時任務。更詳細地說，在 Sabre 板的 u-boot 命令行中設置了以下內核參數(shù)：
setenv bootargs '.... isolcpus =2,3'
指定的參數(shù)允許內核只在核心0和核心1上運行，將其他核心留給實時任務。
文章來源：http://www.zghlxwxcb.cn/news/detail-609027.html
從圖中可以看出，當Linux內核僅限于在內核0和內核1上運行時，獲得的最大延遲值明顯減少。事實上，涉及較大周期（1ms和10ms）實時任務的延遲也明顯減少。文章來源地址http://www.zghlxwxcb.cn/news/detail-609027.html
到了這里，關于實時嵌入式Linux設備基準測試快速入門4測試和測量的文章就介紹完了。如果您還想了解更多內容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關文章，希望大家以后多多支持TOY模板網(wǎng)！
