コンテンツにスキップ

測定の取り方

How the measurements are taken の翻訳です。内容が異なる場合は英語の 原文が優先されます。

どの測定ページも、数値をどう取ったか、そしてそれが何を意味しないかを書いています。このページは、 それらに共通することをまとめたものです:試験台、数値を読む場所、ツール、各種の数値の計算、そして すべてのページが守るルール。どれにも、そうする理由を添えています。方法のない数値は何の証拠にもならず、 いちばん見栄えのよい数値ほど、主張とは別のものを測っていることが多いからです。

試験台

互いにルーティングされた 2 台の XGS 3300 と 1 台の XGS 136、そして真ん中の機器に 10 Gbit/s で接続した PC。各実行のウィンドウを撮影している試験台のページ(英語)の とおりです:

リンク 接続元 接続先 媒体
PC PC の 10GBASE-T NIC 2 台目の XGS 3300 の F1 銅線、10 Gbit/s
光ファイバー 2 台目の XGS 3300 のモジュールポート A1 1 台目の XGS 3300 の F1 光ファイバー、10 Gbit/s
ギガビットリンク 2 台目の XGS 3300 の Port8 XGS 136 の Port8 銅線、1 Gbit/s
何を なぜ
すべてのトンネルの両端にハードウェアの相手を置く。 2026-10-17 までは、測定したトンネルの遠端は ESP をソフトウェアで処理するファイアウォールでした。そのため数値が機器ではなくそのファイアウォールのものである可能性がありました。
各リンクを LAN ブリッジの外の独自の /30 に置き、通過ルールと静的ルートを設定する。 トラフィックは機器の横をスイッチされるのではなく、機器を通ってルーティングされます。ネットワーク上のほかの何もその経路を共有しません。
公開テストサーバーを遠端にしない。 それは他人のサーバーで、洪水のように見えるものは拒否されます。拒否された 1 行が、実行されていない 3 件の「ダウンロード」を表に残したことがあります。並列や繰り返しの処理はすべて試験台上の遠端に向けます。

数値を読む場所

受信側、遠端で - 機器自身のカウンターからは決して読まない。 ハードウェアに載った接続は コプロセッサの中でポートからポートへ流れ、ホストには届きません。pf の状態、インターフェースの カウンター、それをもとにしたすべてのグラフは増えなくなります。すべてが動いているときにゼロを示す計器は 計器ではありません - そんなゼロを、実際には起きていない崩壊と読んだルールが実行を止めたことがあります。

送信側ではなく受信側の数値。 iperf3 は両方を出力します。送信側はソケットに書き込んだ量を、 受信側は届いた量を数えます。スループットは後者だけです。

実行されたことがわかってから行を読む - カウンターが動いただけでなく、バイトを受信したこと。

ツール

ツール ここで測るもの なぜこれか
iperf3 - 送信は PC の WSL 上の 3.20、受信は Windows 版 iperf3、機器のホスト上のサーバーは 3.22(OPNsense のパッケージ) スループット、TCP ストリーム 1 本または 4 本、1 回 10 秒 各実行の両端で同じツールを使い、バージョンを明記します。PC にクライアントが 2 つあるのは、WSL のミラーモードのネットワークが 1500 バイトを超えるフレームを外へは出すが中へは入れないためです。PC が 1500 を超えて受信した実行は、Windows 版で測り直すまですべて 0.00 bit/s でした
HTTPS 上の curl と SHA-256 完全性の長時間試験:ランダムなバイトからなる 1 GiB のファイルを何時間も繰り返し取得 TLS は認証されないレコードをすべて拒否し、ファイルのハッシュをサーバーのものと照合すれば丸ごと通過したものも捕まえられます。スループットだけではバイトが正しかったかは何もわかりません
フラグメント禁止ビット付き、決まったサイズの ping あるサイズのフレームが経路を通るか、そして往復時間 経路の MTU と、そもそも受信するポートかどうかを調べる最も素朴な試験
sysctl CPU(kern.cp_time)、ドライバー自身のカウンター(dev.octep.0.*、dev.npuep.0.*)、TCP ホストキャッシュの消去(net.inet.tcp.hostcache.purgenow) カーネル自身の数値を、毎回同じ方法で読む
pfctl pf の状態と、そのパケット数・バイト数 ホストのファイアウォールが見たものを、ハードウェアが見たものと並べるため
コプロセッサ自身の統計、ドライバー経由で読み取り ハードウェアが転送したもの:回線から来たフレーム、自らが回線に送り返したフレーム、各接続のカウント ホストにはもう見えないトラフィックの唯一の証人
mvsw スイッチチップのレジスタ:ポートのフレーム上限、エラーカウンター スイッチにしか見えないエラーと上限を、そのレジスタから読む
shot-run.ps1 各測定コマンドを専用のコンソールウィンドウで実行し、終了時にそのウィンドウ自身のピクセルで撮影 証拠は当時の画面そのものであって、後から打ち直した文字の再現ではありません。デスクトップのほかのものは写りません
tools/mark-images.py 所有者とライセンス(CC BY 4.0)を各写真の下の帯に入れ、マークのない原本は別に保管 ページの外に出た画像でも、誰のものかがわかる
tools/readme-art.py 各機器の完成度を、ファミリーのページのテーブルから計算 下の計算を参照。ページがほかの値を書けばチェックが失敗します

各実行を動かすスクリプトは、その実行のページに名前を挙げています。

計算

数値 計算方法 なぜ
スループット、1 回の実行 実行中の受信側のビット毎秒、iperf3 が出力したとおり 受信側のカウントが届いた量
スループット、長時間試験 成功したパスで受信したバイト × 8 を、最初のパスの開始から最後のパスの終了までの秒数で割る 何時間にもわたる平均で、失敗は配送済みとして数えない
CPU 使用率 実行の前後に kern.cp_time を読み、差分から 使用率 = (合計 − アイドル)÷ 合計 実行全体でかかったコスト。top を一瞥しても一瞬しかわからない
ハードウェアで処理したフレームの割合 実行中にコプロセッサが回線から受信したフレーム(RX_WIRE)のうち、自ら回線に送り返した割合(FROM_WIRE_TO_WIRE):6,657,897 のうち 6,630,528 で 99.6 % 転送したハードウェア自身が数えたもので、ホストの沈黙からの推測ではない
信頼できるカウンター 事前にわかっている量と照合する:PC はちょうど 4,000,000,000 バイトを送り、コプロセッサのカウントと pf のカウントの合計が回線を通った量に一致しなければならない - 274 万パケット中 14 パケットの差で一致した カウンターは独立に数えたものと一致してはじめて信頼される。この方法で 2 つの誤りが見つかった
完全性試験の結果 失敗したパス(curl の終了コード)、ファイルが異なったパス(ハッシュ)、そしてバイト数 両方がゼロのときだけ合格
機器の完成度 ファミリーのページのテーブルの各行に完了率と重みがあり、完成度 = Σ(完了率 × 重み)÷ N。重みの合計は N で、取り消し線の値は数えない 重み付けの対象からずれようのない割合:tools/readme-art.py が計算し、ページや README が別の値を書けばチェックが失敗します

すべてのページが守るルール

ルール なぜ
どう取ったか、そして何を意味しないかをすべてのページに 数値の限界は数値の一部です:機器自身のホストで終わるストリームは、PC、転送、リンク、そのホストの受信経路のうち最も小さいものを測っており、転送の上限ではありません。上限を測るには遠端の機器の奥にマシンが必要です
ビルドを明記する - ドライバーのコミットまたはチェックサム 数値はそれを生んだコードに属する
実行の終了時にウィンドウをすべて撮影する 数値のコピーではなく実行そのものを誰でも見られます。ラボのアドレスは画像に残し、シリアル番号とハードウェアアドレスはぼかします
実行の前に、ホストが学習したものを忘れさせる - TCP ホストキャッシュと PC の経路 MTU キャッシュ ある実行で学習した経路 MTU が次に持ち越され、パス全体が 500 バイトのセグメントで走って破棄されたことがある
測定で失敗したことを書き残す 失敗 - 学習された MTU、WSL が落としたフレーム - こそ、ページがその測り方をした理由であり、次の測定はそれを避ける
撤回した数値は削除せず取り消し線を引き、訂正を横に置く 読者は何がなぜ変わったかを見られる
ベンダーの数値はベンダーのものと明記し、私たちの数値と並べる 理想的な条件での Keysight-Ixia BreakingPoint によるもので、MTU、ポート、双方向を数えるかは示されていません:ここで取った数値と同じ種類ではありません

数値のある場所

すべての測定を機器別・日付別に:測定(英語)。