前八天量了很多數字，現在回頭看，裡面只有一個是網路的延遲，其他全部在驗儀器。

八天數字的歸屬：只有一個屬於網路

表上八列，只有一列是網路。 其餘七列全部在回答「這套儀器可不可信」。儀器沒驗過的話，那個 363 只是一個數字，你沒有任何理由相信它。

換個說法，Day 2 我就拿 ping 量過那台交換器，得到 163 µs。那個數字同樣「量得到」，同樣可以填進報告。差別在於前面八天讓我知道它量到的是管理 CPU，跟轉發無關。

奈秒尺度下失效的三個等號

八天裡有三次我先把預期寫下來再去量，三次量出來都跟預期不一樣。而且不一樣的方式是同一種。

第一次：以為主機一加壓，ping 的延遲就會變差。

結果分布幾乎沒動。那台伺服器有 26 核，而我的負載只有兩個執行緒，它們根本沒有碰到同一顆 CPU。「有負載」不等於「會競爭」。 要把兩邊釘在同一顆核上，數字才變。

第二次：以為兩支工具同時用一張卡會撞車。

一支在發、一支在收，完全沒有干擾。我把「同一張卡」當成「同一個資源」，但網卡的發送跟接收是各自獨立的硬體路徑。

第三次：以為封包變長，量到的延遲就會跟著變長。

六個長度量出來連 1 ns 都沒動。序列化那一千多 ns 確實存在，只是兩邊的時戳打在 frame 的同一個位置，相減的時候它就被抵消掉了。

三次都是同一種錯

每一次都是把兩件事當成一件。它們平常看起來一樣，到了奈秒尺度才分得出來。

這三個等號在一般的網路工作裡幾乎都成立，所以它們變成了直覺。但到了奈秒的尺度，每一個都得先量過才算數。所以低延遲這件事，多半是在把很多平常不用分開的東西分開。

還有一次差點算錯，而且錯了也看不出來：我原本打算用中位數去拉線材那條斜率。 中位數看起來比較穩，一般情況下也確實比較穩，但硬體時戳只落在 4 ns 的格線上，而那三個點總共只跨了兩格多。算出來會是漂亮的 4.000，跟真值差兩成。 資料只跨兩三格的時候，中位數會被格線吸住，拉斜率要改用平均值。

全部數字的對照表

交換器那 363，比 ping 的一格還小。 這就是為什麼前面那些工作躲不掉，不做的話根本量不到。

三條門檻與它們的推導

先講三個門檻，全部是從上面那些數字推出來的：

第一條沒有容許帶，因為 Day 8 那十八個中位數全部是 60.0，它不會自己漂。第二條有 ±12 ns，因為那是交換器自己多帶進來的抖動，由直連那組的全距 16 和過交換器那組 28 相減出來的。容許帶要不要給、給多少，看的是那個數字怎麼來的。

再講兩條做法，比門檻更重要：

一、先驗儀器，再量待測物：開頭那張表八列有七列在做這件事。任何一個延遲數字，在你能說出「儀器自己佔多少」之前，都不能拿去比較。

二、設定檔說的不算數，量到的才算：show running-config 描述的是意圖，數字描述的是行為。這兩件事在大部分時候一致，而它們不一致的時候，正好就是你最需要知道真相的時候。

明天回到設備前面。前八天證明的是「這台在做 cut-through」，明天把它切成 store-and-forward，同樣掃六個長度。照 Day 11 的算法，1518 跟 64 的差應該從現在的不到 1 ns 跳到 1163 ns 左右，這也剛好驗證上面第三條門檻抓不抓得到。