低延遲網路上線之後，要確認延遲沒有變慢，靠的是可重現的量法、實測的基線，以及依基線訂出的門檻。這份手冊把 30 天的實測整理成這三部分，涵蓋量測儀器、交換器、伺服器與防火牆，文末附上主題索引。維運上有三個原則：

1. 先驗儀器，再量待測物：量延遲要用硬體時戳（hardware timestamping），每次正式量測前先跑直連校正，結果要跟儀器自己的基線一致（這套環境是 3 m DAC、中位數 60.0 ns）；對不上代表儀器或線材變了，這時量到的數字都不能用。
2. 看分布，不看平均：延遲要看中位數、p99、p99.9 跟抖動，平均值會被少數極慢的請求拉高，看不出大多數請求的狀況；判定門檻要大於同一組設定重複量測的起伏，不然設定沒變也會被判成變慢。
3. 設定失效不會出現錯誤或斷線：設定被改掉或重開機後沒套用，服務照常運作，只有延遲變長，例如 kernel bypass 沒生效時，程式會改走 kernel 的網路堆疊，收發延遲變成好幾倍（這套環境從 1.21 µs 變成 4.16 µs）。這類問題只能靠巡檢跟變更驗證抓到。

量法與基線

評估一項設定調整（例如改網卡參數、換中斷綁定）的效果時，前後比較照這四點做：

1. 能來回切換設定的環境（實驗室或維護時段），照「調整前、調整後、調整後、調整前」的順序各量一輪，前後對稱，基準值隨時間的變動會在兩邊互相抵消；正式環境不會只為了量測把設定改回去，就在調整前緊接著量一輪當基準，調整後再量一輪。
2. 不能拿幾天前的數字當基準：即使設定沒有任何改動，基準值也會隨時間變動，這套環境隔不到一小時再量一次，中位數就差了約 2%。
3. 調整前後用同一支量測腳本、同一組參數，結果跟當下的設定（開機參數、網卡參數、中斷綁定）存成同一份紀錄，數字變了才查得出是哪個設定改了。
4. 驗證流量的封包速率要照正式環境的尖峰設，有些設定只在封包密的時候才有影響。例如 interrupt coalescing（讓多個封包共用一次中斷），這套環境每 1 ms 一個請求時量不出差別；請求改成每 20 µs 一個、關掉 busy poll 之後，rx-usecs 從 0 調到 100，中位數就從 4.35 µs 拉長到約 150 µs。要關掉 busy poll，是因為封包間隔比它的輪詢時間（這台 50 µs）短時，程式在輪詢中就把封包收走，不用等中斷，coalescing 影響不到延遲。

告警等級

後面三張檢查表的等級分兩級：

P2 裡的「同一時段」是把開盤那幾分鐘跟盤中分開比：開盤的尖峰混進整天的數字，盤中的門檻會被拉高，盤中的異常就抓不到。

交換器的檢查與門檻

表中幾項的判讀方式：

1. LANZ 是 Arista 交換器的佇列監看功能，佇列深度以 segment 計（這台一個 segment 是 480 bytes），超過門檻才會留下紀錄。
2. 錯誤計數不設累積門檻，增加就告警，因為 cut-through 在收完整個 frame、驗完 CRC 之前就開始轉發，壞掉的 frame 不會在這台交換器被擋下，會一路轉送到後面的設備跟伺服器。已知有問題、還在等待維修的鏈路例外，改用錯誤率門檻，不然每個錯誤都通報會造成告警疲勞；鏈路修好之後，門檻要改回增量大於 0。
3. 計數器要看兩次讀數的差值；Uptime 比兩次讀數的間隔短，代表中間重開過，Last clearing 的時間比間隔短，代表計數器被清過，這兩種情況的差值都不能用。
4. 換線、換模組這類計畫內的作業，事先在監控系統標上維護時段，時段內 link 狀態變化跟錯誤計數只記錄、不通報，作業完成後照頻率表把設定跟核准過的基線比，再跑直連校正並重新量受影響的延遲基線。

伺服器的檢查與門檻

表中幾項的判讀方式：

1. 這些參數在重新開機、更新 kernel、驅動或 BIOS 之後可能被重設為預設值，延遲變長卻不會出現錯誤或斷線，這幾種事件都要列為比對設定基線的觸發條件。
2. kernel 跟 Onload 預設模式靠中斷喚醒程式，中斷跟程式放同一顆 CPU 延遲比較低，通常是因為不用跨 CPU 喚醒；exasock 從程式啟動就一直輪詢，kernel 的網卡驅動卻照樣為每個封包觸發中斷，放在程式那顆會打斷輪詢，所以網卡中斷要放別顆。
3. irqbalance 開著會重新分配中斷，綁好的位置會被改掉，要停用或把這些中斷排除。
4. Onload 在資源不夠、建不起加速的 socket 時，預設會自動改用 kernel 的 socket，程式收不到錯誤，延遲卻回到 kernel 的水準；EF_NO_FAIL 設成 0，建不起來時才會把錯誤回報給程式。
5. 輪詢模式的程式會讓所在的 CPU 使用率一直接近 100%，這是正常的，CPU 使用率告警要排除這幾顆。

防火牆的檢查與門檻

表中幾項的判讀方式：

1. 有硬體加速的防火牆，新 session 開頭的封包通常由 CPU 處理（這台 UDP 是前兩個），建立完成後才交給加速晶片轉發，所以行情與下單的連線要在開盤前完成建立並確認加速狀態。
2. policy 關掉硬體加速，或套用 proxy 模式的安全檢查（例如防毒、網頁過濾），session 都不會被加速，所以這兩項要列進設定基線。
3. UDP session 閒置超過逾時（這台是 180 秒）會被刪掉，下一個封包要重新建立 session，開頭的封包又改由 CPU 處理。交易時段可能閒置這麼久的 UDP 單播流量，要把防火牆上這類流量的閒置逾時調得比最長的閒置時間長（這台是在對應的 firewall service custom 上設 udp-idle-timer）；行情多播通常會定時送 heartbeat，不會閒置這麼久。
4. 防火牆 CPU 跟 session 建立速率是間接指標：沒被加速的封包都要由 CPU 處理，這兩項突然升高，代表可能有大量流量沒被加速。

檢查頻率與變更驗證

變更前後的延遲照下表判定（交換器 port-to-port 照量法表的容許範圍）：

門檻怎麼訂、判定之後怎麼做：

1. 門檻取重複量測起伏的兩倍以上：同一組設定、什麼都沒改，再量一輪本來就會有起伏，這組門檻是依這套環境程式放在隔離的 CPU 時的起伏訂的（中位數 2.1%、p99 3.3%、p99.9 4.6%、PDV 18.7%）。
2. 程式所在的 CPU 還跑著其他工作時，起伏會大很多（這套環境 p99.9 差到 12.2%），門檻不能照抄，要在那台機器上重複量幾輪，用實測的起伏來訂。
3. 判定通過，就把變更後存下的設定跟量測紀錄核准為新基線；沒通過就 rollback，並確認所有項目都回到變更前的狀態。

常見的判讀錯誤

1. 平均值描述不了分成兩群的分布：延遲分成兩群時（例如程式在量測途中換了 CPU），平均值會落在兩群中間，不代表任何一群的實際延遲；要先找出分群的原因，再分開統計。
2. 最大值容易被量測剛開始的請求拉高：剛開始時快取、位址解析或連線狀態通常還沒建立，前幾個請求特別慢；看最慢的延遲之前，要先排除開頭的幾個請求（這套環境是每輪最前面兩個）。
3. discards 是 0 不代表沒有擁塞：discards 只算被丟掉的封包，佇列堆積造成的延遲不會留在 discards 裡，要看交換器的佇列紀錄（Arista 是 LANZ）。
4. 設定檔只代表意圖，量到的才是實際行為：變更設定或 rollback 之後，都要重新量測，確認延遲符合預期。
5. ping 不適合判斷低延遲網路：ping 最小只顯示到 1 µs，比低延遲交換器數百 ns 的轉發延遲還大，ping 通也只代表對方的 kernel 有回應。延遲要用網卡在收發封包當下打的硬體時戳量，不受伺服器軟體排程影響；服務能不能用，要對服務實際使用的 TCP 或 UDP port 送出請求，確認程式有回應。
6. tcpdump 抓不到封包不代表沒有流量：走 kernel bypass 的程式收發不經過 kernel，tcpdump、ss 都看不到，要改用 onload_stackdump、exasock-stat 跟交換器的 port 計數器確認。

結論與導入步驟

這 30 天的實測顯示，交換器轉發一個封包約 363 ns，伺服器收發是 1.21 到 4.16 µs，防火牆加速時也要約 4.1 µs，延遲主要花在伺服器跟防火牆，調校的重點也在這兩段；交換器轉發的延遲幾乎固定，監控重點是錯誤、丟包跟佇列。這份手冊的基線與門檻都來自這套實驗環境（Arista 7150、ExaNIC X25、Solarflare X4522、FortiOS 7.6.7 的 FortiGate 201G），不能直接套用到其他環境。要在其他環境建立同樣的量測與監控，建議依下列步驟導入：

1. 準備有硬體時戳的量測網卡，先跑直連校正，確認儀器本身的延遲。
2. 照上面的量法，量出交換器、伺服器、防火牆各自的基線，連同當時的設定一起存。
3. 同一組設定重複量幾輪，用實測的起伏訂變更驗證的門檻；跟過去 30 天比的告警門檻，要先收集滿 30 天的紀錄才能啟用。
4. 把設定比對跟計數器檢查寫成巡檢腳本，每天開盤前執行；計數器另外交給監控系統每分鐘取樣。
5. 每次變更前後先跑直連校正，再各量一輪延遲，照前面的門檻判定，通過後把變更後的設定跟量測紀錄核准為新的基線。

設備、韌體版本或線材一有變更，就回到第 2 步，重新建立基線並調整門檻。

索引