昨天量到 7150 轉發一個封包約 363 奈秒。那個數字只證明它快，沒有證明它用什麼方式在快。

一台 store-and-forward 的交換器也可以很快，只是它快的形狀不一樣。分辨的方法不是看某一個數字大小，是看封包變長的時候那個數字怎麼動。

cut-through        ：延遲幾乎不隨封包變長
store-and-forward  ：延遲隨封包線性增加，因為它要等整個封包收完

在 10G 的線上 1518 bytes 比 64 bytes 多花 1163 奈秒把資料推出去。如果這台是 store-and-forward，那 1163 就會原封不動出現在延遲裡。

雙組量測：六個 frame size 各量直連與過交換器

六個封包長度，每個長度量兩次：一次直連、一次過交換器。相減之後才是交換器自己的部分。

六列一模一樣。 封包從 64 漲到 1518，交換器那一欄的中位數一格都沒動。

這就是 cut-through 的形狀。 它讀到足夠做轉發決定的部分就開始往外送，後面還有多少 byte 沒收完，它不管。

直連那一欄的兩個作用

直連那一欄不是拿來看的，是拿來扣的。

那 60 奈秒是儀器自己的延遲：網卡的收發路徑加上那條線。它跟交換器一點關係都沒有，但它混在每一次量測裡。428 這個數字裡面有七分之一是網卡的，不扣掉就會算到交換器頭上。

更重要的是第二件事。Day 5 量過，直連基線在 64 到 1518 之間是完全平的 60.0。

這條平線本身就是證據。 它證明儀器自己的那 60 奈秒不隨封包長度變，所以過交換器那一欄如果出現任何隨長度的變化，百分之百來自交換器，不可能是儀器自己爬上去的。

沒有先驗這件事，今天這六個 368 就沒有意義。你分不出「交換器沒爬」跟「儀器看不到爬」。

0.0000 的正確讀法：解析度下限，不是真值

那個斜率我不打算就這樣寫進結論，因為它是被儀器的刻度限制住的，不是量到的真值。

Day 5 講過，硬體時戳只落在 4 奈秒的格線上，而中位數永遠是某一條格線。六個中位數全部咬在同一格，算出來當然是 0.0000。 它的意思是「小於一格」，不是「等於零」。所以同一批資料我用平均值重算了一次：

爬升 0.12 奈秒。但這個數字也不能直接報。

看那六個「相減」：367.763、367.730、367.966、368.010、367.978、367.881。它們自己就在 0.28 奈秒的範圍裡上下跳，而且不是單調上升，512 那格比 1518 還高。

六個點自己的標準差是 0.118，而所謂的「爬升」是 0.118。訊號跟雜訊一樣大。

所以正確的說法是：量不到。上界大約 0.3 奈秒。

寫「斜率 0」太肯定，寫「0.00008」是假精度，那個數字整個埋在雜訊裡。能撐住的只有一句：在我的解析度之內，它沒有任何隨封包長度的變化。

與 store-and-forward 理論值的對比

store-and-forward 理論上要爬 ：1163 ns
我量到的爬升                 ：0.12 ns

差了將近一萬倍。這個量級的差距，比我上面那些小數點的爭論重要得多。

一萬倍這種量級的好處是：它讓「我的量測夠不夠準」變成不重要的問題。 就算我的爬升量估錯十倍、百倍，離 1163 還是差得非常遠。

判斷一台設備是不是 cut-through，不需要跟誰吵 0.12 到底是不是真的。你只需要一套分得出「0」和「1163」的量測系統。我手上這套的解析度是 4 奈秒，離要分辨的那個差距還有兩百多倍的餘裕。

所以這題的關卡是有沒有想到要換封包長度量兩次。

判別門檻的推導：兩個端點的中位數差

曲線形狀變了，就是轉發模式被動過。問題是「形狀」沒辦法自動比大小，圖是給人看的。

所以不要盯整條曲線，盯兩個端點的差：

1518 bytes 的中位數 － 64 bytes 的中位數

兩邊的值都是已知的：cut-through 是 0，store-and-forward 會是一千多。門檻訂 100 奈秒，離兩邊都非常遠，不可能判錯。

而且這樣只要量兩個封包長度，不用六個。 成本剩三分之一，判斷力完全一樣。六個點是拿來畫圖說服別人的，兩個點是拿來每天跑的。

頻率不要綁時間，要綁變更。 轉發模式是一項設定，它不會自己變，每天量是浪費。但只要有人動過那台交換器的組態，這兩個點就該重量一次。

還有一句要寫進流程：show running-config 說模式沒改，那不算數。 設定檔描述的是意圖，這兩個數字描述的是行為。低延遲這件事上，只有行為算數。

明天把這幾天的量測包成可以重跑的東西，建立第一組基線。