這 30 天要寫的是低延遲網路的維運,不是設備設定教學。
低延遲環境有個很煩的地方:東西慢下來的時候通常沒人會通知你,而且你手上不一定有數字可以證明它真的慢了。ping 在這裡幫不上忙,它量的是來回時間,誤差比你想量的東西還大。
所以我想先把量測弄清楚。用 ExaNIC 的硬體時戳量 Arista 7150 的單向延遲,再拉一台十年前的 3750 當對照組,看 cut-through 跟 store-and-forward 差多少。有了這個基準,後面才有辦法談交換器要盯什麼、RHEL 網卡要調什麼。
每篇最後我都會寫這件事在維運上要幹嘛。
這 30 天不是設備設定教學,我想弄清楚的是另一個問題:低延遲網路的設備調整完、驗收過、上線了,然後呢?能保證它下週還是一樣快嗎?如果真的慢了,我沒把握自己說得...
昨天說今天要從 ping 開始,看它到底差多少。動手之前我猜大概十倍。量完是幾百倍。而且量完才發現,這個工具回答的根本是另一個問題。 環境 一台 RHEL...
昨天量到 ping 的顯示下限是 1 微秒。今天使用有硬體時戳的ExaNIC X25的兩個 port 用一條 3 公尺 DAC 直接對接。同一個封包用兩種時戳各...
今天把兩千個封包抓下來,想看清楚時戳打在封包的哪個位置。 兩千個封包,一個都沒掉 先講結果: exanic-capture: received=2000 cor...
昨天說今天要換封包長度,看時戳是打在 frame 的開頭還是結尾。 先講我原本怎麼想 : 一個 64 bytes 的封包推上 10G 的線要 51.2 奈秒,1...
今天要來說 Day 2 那篇留下的一筆帳。當時我寫「整段轉發時間塞得進 ping 的一個顯示格子裡,差幾倍我今天不算,因為手上還沒有實測值」,現在實測值有了。...
昨天量到 7150 轉發一個封包約 363 奈秒。那個數字只證明它快,沒有證明它用什麼方式在快。 一台 store-and-forward 的交換器也可以很快,...
昨天說今天要把這幾天的量測包成可以重跑的東西。 前七天每一次量都是手打指令。麻煩還是其次,真正的問題是兩次量的條件不保證一樣:上次是幾公尺的線、跑了幾筆、byp...
一個封包從伺服器出去、經過一台交換器、到另一台伺服器,這段時間花在哪裡?拆開來是四塊,性質差很多,如果分不清楚,監控就會盯錯東西。 延遲的四塊:序列化、傳播、佇...
一份行情要送給機房裡幾十台機器。最直覺的做法是一台一台送,每台一份。這樣為什麼不行? 用昨天的算式就看得出來,取 1518 bytes 這種最大的 frame...