一個封包從伺服器出去、經過一台交換器、到另一台伺服器，這段時間花在哪裡？拆開來是四塊，性質差很多，如果分不清楚，監控就會盯錯東西。

延遲的四塊：序列化、傳播、佇列、處理

四塊裡會自己變的只有佇列。 這篇先把算得出來的算完。

序列化：位元數除以線速

10G 一秒推 10 的 10 次方個位元，一個 byte 0.8 ns。容易漏掉的是：線上跑的不只有 frame，前面有 preamble 7 bytes 加 SFD 1 byte，後面要留 IFG 12 bytes，這 20 bytes 一樣要花時間推上線。

這張表是算的不是量的，純除法，可以直接當基準。讓我意外的是 64 bytes 那列：開銷吃掉 24%，84 個 byte 裡有 20 個不是資料。行情那種小封包全落在這一區，估時間不能只算 frame 本身。

傳播：每公尺乘上折射率

真空裡光一公尺 3.34 ns。封包不走真空，光纖折射率大概 1.47，訊號在裡面就慢了 1.47 倍，一公尺變成 4.9 ns，取整當 5 ns 用，第一天提的就是這個。DAC 銅纜不能套，每公尺 4.3 到 5.0 ns 都有，這種東西我不查表，我手上這三條同型號的 DAC 量出來是 4.96 ns/m。

實驗室裡幾公尺的線，傳播只有幾十 ns。拉到機房之間就不一樣，100 公尺光纖是 490 ns，比 Day 6 量到的 363 ns 還大。

佇列與處理：只能量，算不出來

處理沒有公式可以算，只能自己量。cut-through 只讀到 header 就轉發，我本來以為這塊很小。

7150 的 port-to-port 延遲中位數  ：約 363 ns
64 bytes 在 10G 上的序列化       ：51 ns
所以「處理」至少佔                ：312 ns

量出來 312 是下限，推法是把序列化整個扣掉：佇列在這組數據裡幾乎不計，量到的最大值只比中位數高十幾奈秒；交換器內部的傳播是板子上幾公分，可以忽略；而 cut-through 最多也只會等到讀完 header，扣掉整個 frame 的序列化其實扣多了，312 才會是下限。所以 363 ns 裡，至少有 86% 是處理，是序列化的六倍以上。這塊固定，但不小。

佇列是唯一會自己變的。前三塊只要拓撲、線速、轉發模式不動就不會動；佇列取決於當下有多少人在搶同一個出口，所以算不出來，你翻遍整個 datasheet 也沒有這個數字。而且它不是慢慢變，同一秒之內出口被塞滿再空掉，看平均值完全看不出來。

即時告警的選擇：四塊裡只有佇列會自己變

即時告警盯佇列就好。 盯總延遲也行，但延遲一上升你還要判斷是哪一塊變了，而那三塊本來就不會動，答案每次都一樣。

我盯佇列的方式是看 LANZ，這是 Arista 的佇列深度監看功能：佇列長度超過設定值就記下來，不用等平均值反應過來。門檻要訂多少這篇不能講，基線沒量出來之前訂的都是猜的。現在能講的是判斷方向：

明天講 multicast，行情資料為什麼走多播，還有在維運上會遇到什麼問題。