Day 11 我有對這台 Arista 7150 立過一個預測：轉發模式切成 store-and-forward，64 到 1518 bytes 的延遲要多爬約 1163 ns，兩種模式的斜率差 0.8 ns/byte。今天換模式量，結算這兩個數字。

模式切換的生效方式：不需要 reload

先確認這台有哪些選項：

只有兩個轉發模式。Day 11 提過的 fragment-free 與 adaptive，這台沒有。

切成 store-and-forward，立刻量 1518 bytes：

（428 ns 是還沒扣網卡跟線材的原始值，跟 Day 6 量到的是同一個數字。）

兩種模式的九點掃描結果

Day 7 那六個長度，加上後來補的 160、192、224 bytes。環境除了轉發模式，其他都跟之前一樣。

cut-through 那一欄從頭到尾都是 428.0 ns，store-and-forward 隨封包變長往上爬。

160、192、224 bytes 這三列的直連欄沒有另外量，是套用 Day 5 量過的那條平線（64 到 1518 bytes 全是 60.0 ns）。cut-through 與 store-and-forward 兩欄都是實際量到的。

Day 11 預測值與實測值的結算

爬升差 43 ns，3.7%，Day 11 的預測大致成立。少掉的那 43 ns 跟下一節的轉折點有關。

轉折點的位置：落在 160 與 192 bytes 之間

那個 1163 ns 是純算的，1454 bytes * 0.8 ns/byte，算的時候假設整條線從 64 bytes 就開始爬。實際量到的不是這樣。

九點掃描那張圖最反直覺的是前三列。64、128、160 bytes 三個長度，兩種模式量到的值一樣。要到 192 bytes 才分得出來，而且一分出來就是 56 ns。

我原本以為轉折會是平滑的。用 256 bytes 以上四個點擬了一條直線，推算 160、192、224 bytes 的差值（store-and-forward 減 cut-through）會是 22、48、74 ns，然後補量這三點：

160 bytes 那點預測 22 ns，實測 0 ns，式子當場作廢。

所以現在只寫得出三句，而且三句都是直接讀資料：

1. 160 bytes 以下（64／128／160），兩種轉發模式量到的值相同。
2. 192 bytes 以上分得出來，轉折點落在 160 與 192 之間，範圍 32 bytes。
3. 256 bytes 以上是乾淨的線性區。

160 到 256 bytes 這一段的相鄰斜率是 0.000、1.750、0.250、0.625 ns/byte，不是平滑過渡。 所以下面報斜率的時候，取樣範圍要一起報，不能把這一段跟線性區混在一起算。

報斜率要連取樣範圍一起報

同一組資料，換幾個點來擬就是不同的斜率：

差別是加入幾個還沒開始爬的點。要跟理論的 0.8 比，就用線性區的 0.8069，兩者幾乎一樣。只寫「斜率 0.79」不講是哪幾個點，下一個人重跑就對不起來。

Day 7 判別法的適用範圍限制

Day 7 給過一個可以每天跑的判別法：量 64 與 1518 bytes 兩個點，相減超過 100 ns 就是被切成 store-and-forward。今天有了對照組，可以說它到底有多安全：

100 ns 這個門檻離兩邊都非常遠，幾乎不會判錯。

但 64 跟 1518 bytes 這兩個端點不能換。今天量到 160 bytes 以下兩種模式一樣，所以有人為了省時間把掃描改成 64 跟 128 bytes，這個判別法會失效且不報錯，每天照常回報「一切正常」。要量就量到 1518 bytes。

還有兩件要寫進變更流程：

第一，切回去之後要重量一次確認。我切回 default switch forwarding-mode 之後重量 1518 bytes，中位數回到 428.0 ns，才算數。show running-config 說它回去了，那只是意圖。

第二，這個旋鈕不用 reload。它可以在營運時間被改掉，而且不會留下任何重啟痕跡。變更紀錄之外唯一抓得到它的，就是那兩個點的量測。

明天回到交換器本身，看它有哪幾個計數器值得盯。