最近對公司的嵌入式設備做了一個網絡性能測試，如何確定網絡性能的瓶頸在哪裏，以及網絡性能影響因素有哪些，有些心得記錄在此。
一般評判網絡性能都是看數據下載上傳的速度。現在主流的帶寬有2種，100Mbps和1000Mbps，2者理論上可以達到的下載最大速度分別爲12.5MB/s和125MB/s。
設備的網絡性能如何，影響因素很多，受所在局域網網絡狀況，對端設備性能影響很大，而且不同的應用程序測試速度也會有所不同。
那麼該如何來分析設備的性能瓶頸？
對於嵌入式設備，測試網絡性能一般是看從局域網內的PC服務器上下載上傳數據速度。這裏我們假設對端設備（PC服務器）性能夠高，可以達到最大帶寬。
分析影響網絡性能因素，以下載爲例，我的想法，可以從數據整個的流程來分析，就像一條河流，判斷最終水流速度受哪些影響，可以看水流經過的地段哪裏寬哪裏窄。
（以下分析都假設是在1000M帶寬網絡環境中，使用1000M phy和1000M mac，mac是synopsys的gmac）
在數據下載中，數據的流程圖如下：
從數據由對端設備發出，按照先後順序我們來分析，對於網絡性能的影響因素：
（1）局域網網絡狀況
數據由對端設備到測試設備可能會經過很多個路由器，如果當前局域網網絡狀況差，數據量大，路由器轉發負載比較大，就有可能造成我們下載數據轉發慢，在該環節影響我們的網絡性能。
如果想要一個理想網絡環境的性能測試，獲取一個可以達到的最大性能，可以採用測試設備與對端設備直連的方式，排除局域網能其他設備數據包的影響。
（2）phy芯片
phy作爲OSI網絡模型的最底物理層，是一個數據收發器。phy不存在性能問題，這一點我問過一些phy芯片技術支持，只要提供給phy正確的工作時鐘（GMII 125MHZ，MII 25MHZ，RMII 50MHZ）
它就可以達到它所支持的最大帶寬，也就是說對於phy只有通或者不通，而沒有快慢問題。
（3）mac core模塊
mac控制器內部邏輯中跟數據收發相關的模塊有3個：mac core，mtl， dma。
mac core部分功能在於提供與phy芯片相連的接口，在phy完成自動協商後，軟件上會根據phy的協商狀態來配置mac core，如配置其工作模式（GMII MII RMII），數據包過濾模式，流控，CRC校驗，傳輸調度（Rx/Tx優先級）等。
mac core在與phy配合正確配置後，與phy類似，就可以達到其所支持的最大帶寬，只有通或者不通，而沒有快慢。
所以mac core不會對網絡性能造成影響。
這裏有一點需要記錄下，之前有同事說對於工作在GMII模式下的phy與mac core，就一定要供125MHZ時鐘嘛，低一點，速率是不是低一點也可以工作。
這個是不行的。最簡單答案就是協議規定GMII的phy mac clk必須爲125MHZ。
其實仔細想想，原因也簡單，數據傳輸的clk很重要的作用是來保證其採樣正確性，如果兩端clk不一致，一端的數據採樣肯定就不對了。
（4）mtl模塊
mtl是mac內部的傳輸層，mtl提供了2個FIFO在mac core和dma之間，Rx FIFO和Tx FIFO。在mac core和dma之間起到緩衝區作用，因爲mac core和dma是不同的時鐘域，也就是mac core和dma的工作時鐘肯定是不同。
FIFO由外部的一個two-ports RAM提供，一個port連接dma的clk和data，一個port連接mac core的clk和data。所以FIFO性能決定於dma和mac core的性能，它應該不會主動影響網絡性能。
（5）dma模塊
dma模塊完成了mac跟系統內存之間的數據傳輸。其工作時鐘的高低會影響dma的搬運性能。
但是由於mac內部dma是隻進行網絡數據搬運，沒有其他數據通道，即使其clk比ddr cpu低，其也可能完全滿足對於最大帶寬的要求。
這個可以通過改變dma clk來看其對網絡性能的影響來進行判斷。
如果測試發現網絡性能受到dma影響，可以採用提高emac的dma clk方式來提高網絡性能。
（6）ddr內存
ddr的帶寬對網絡性能也是有影響的。
mac的dma跟內存進行數據搬運，dma是設備具有的一種仲裁能力，設備具有這種仲裁能力，能夠搶佔總線，獲取總線的控制權，直接完成對內存的讀寫操作。
如果有多個設備對內存發起讀寫，如cpu mac dc等，這些主設備來搶佔總線控制權，在同一個時刻，只能有一個設備獲取總線控制權，對內存讀寫。
內存帶寬指的是內存的數據位寬X內存頻率，就是1s的數據傳輸量。
對於軟件來說數據位寬是硬件做死，可以通過提高內存頻率，也就是讓3個主設備在1s內有可以獲取到更多的次數的總線控制權，來提高網絡性能。
也可以分析哪些設備在進行內存讀寫，將一些暫時不用的設備disable。
如何來確定內存是否對當前網絡性能有影響，還是採用數據通路上其他模塊不變，修改ddr clk，看對網絡性能是否有影響來判斷。
（7）cpu
根據我之前的性能測試記錄，cpu性能對嵌入式設備網絡性能影響最大。
可以想象，cpu因爲要進行多任務切換，還要處理大量異步中斷。在我的測試環境下cpu 800MHZ + ddr 800MHZ +dma 4000MHZ，性能影響最大就是cpu。
我們可以進行一個計算。在1000M環境下，假設外部網絡速度 ddr性能 dma性能都達到峯值，給到ddr中的數據速率是125MB/s。
mac的dma intr模塊是按照一數據包一中斷進行設計，按照網絡最大MTU計算，一個數據包在1500 bytes左右。
那麼125MB/s就應該產生： 125X1024X1024/1500 = 89478 intr/s
一秒鐘產生8.9萬個intr，這還只是接收數據intr，還不包括髮送請求intr和一些控制數據intr。
那麼這些intr對於cpu來說處理的過來嗎，根據我的實際測試，arm A8處理器800MHZ，實際處理的網絡intr只有1.9萬左右每秒。
因爲mac driver中採用的是遍歷整個dma的描述符鏈表，將所有數據包收下，所以這保證了在丟中斷的情況並不會發生丟數據的現象。
但這還是說明了cpu過載。
這裏cpu過載的原因，cpu頻率是一個原因，提高cpu的clk肯定是有作用的。其次，其他外設intr，這個是不可避免的。最後，很重要的一點就是複雜的網絡協議棧處理，在收到數據後，cpu還需要對數據包進行拆封，層層剝離。
這裏我也就可以理解現在一些硬件協議棧處理模塊以及網上大牛對於網絡協議棧優化的初衷了，都是因爲嵌入式設備cpu性能不夠啊！
（8）app
上面已經將整個數據流程中硬件模塊分析完了，但是在實際應用中我卻發現，對於同樣的網絡環境，設備。使用不同的工具，所測試出來的速度是不同的。這是什麼原因，我想到了下面這一點。
假設我們的網絡環境非常好，設備ddr dma cpu性能足夠，1000M帶寬下可以達到12.5MB/s下載速度。但是要注意，這個12.5MB/s必須要保證我的測試程序完全佔有cpu進行數據傳輸纔可能達到的速度。
而對於跑在kernel之上的app，是不可能完全佔有cpu的，kernel進行進程調度，如果系統中有10個進程，我們的下載測試程序，在1s內也只能有1/10s進行下載。
這我就可以理解不同測試工具測試速度的差別了，單進程程序下載速度肯定是要慢於多進程程序的下載速度，因爲多進程測試程序對於cpu的佔有率更高。
以上純屬個人實驗總結分析，才疏學淺，不足之處敬請大家指正，共同學習進步。