Summary

  • draft-ietf-bmwg-powerbench-03 が定めるのは、外部電力計と制御されたトラフィックを使う実験室手法である。本番の電力管理や製品認定を定める文書ではない。
  • Idle+ は全アクティブ・インターフェースに双方向 1 pps を与える。ほぼ無負荷でも転送面が起動し得るため、Base、Idle、Idle+、Typical、負荷試験は Power State そのものではなく測定条件である。
  • EER の T/P を比べるには、負荷水準と重み、正しいポートへの無損失転送、機器・プログラム構成、電力計精度、安定化区間、平均窓を同じ証拠束に残す必要がある。

名前が同じでも、動いている回路は同じとは限らない

完全に設定済みの装置で全インターフェースを up にし、利用者トラフィックをゼロにする。これが Idle である。次に、すべてのアクティブ・インターフェースへ双方向で毎秒 1 パケットを流す。これが Idle+ だ。

1 pps は、パケット処理による動的消費を測定可能なほど増やさず、転送面だけを起動させる最小トレースとして選ばれている。帯域グラフではほぼ見えない。しかし内部では、パイプライン、クロック、メモリー、光部品、ファンの条件が変わる可能性がある。

PowerBench 第 03 版が追加した重要な整理は、測定条件と Power State を分けることだ。Base、Idle、Idle+、Typical、Power with Traffic Load は実験者が適用する条件である。装置は二つの条件で同じ内部状態を保つことも、一つの条件の途中で状態を移ることもある。

状態を外部から観測できる、または明示的に設定した場合は、状態名だけでなく設定・確認方法も報告する。ただし、それは補助情報であり、標準化された手順の代わりにはならない。

この修正は因果関係を守る。第 02 版には Idle+ が装置を「低電力モード」から出すように読める表現があった。第 03 版は、差分が低電力状態からの遷移を捉える場合があると改めた。ワット差は観測であって、原因名ではない。

文書の権威も限定されている。Datatrackerでは BMWG の active Internet-Draft で、03 は 2026 年 9 月 30 日に提出された。ヘッダーは Standards Track を意図すると記す一方、凍結した文書 APIの intended level は空である。RFC でも承認済み標準でもなく、特定製品の試験合格証でもない。

分子は「最大性能」ではなく、選択した利用像である

Energy Efficiency Ratio は EER = T/P、単位は Gbps/Watt である。だが T は単一の最大値ではない。複数のトラフィック水準におけるインターフェース・スループットを、あらかじめ決めた係数で重み付けした合計だ。P も同じ水準と係数による電力の加重合計である。

草案は 100%、30%、0% の負荷と、0.1、0.8、0.1 の重みを例示する。アクセス・ルーター、コア、データセンター・スイッチで別の値を使える。30% を中心にした比率は、アイドル中心の比率とは異なる運用像を評価する。

さらに、加重容量の代わりに全インターフェース容量を使う選択肢がある。結果は比例するが、分子は別物だ。両者を一つの「Gbps/W」列に混ぜれば、装置ではなく計算規約を順位付けすることになる。

パケットは正しいポートから出なければならない。既定は RFC 2544 の Non-Drop Rate に沿うゼロ損失で、損失を許すなら値と理由を明示する。参照手順ではフル NDR 負荷に戻れない結果は失格になる。仕事を捨てて分母だけ下げることは効率ではない。

Typical は最大スループットの明示割合と RFC 6985 IMIX を用いる。負荷試験ではポートやラインカードも指定する。パケット長、レート、方向、ポート配置が変われば、同じ 30% でも処理負担は変わる。

電力計が支配できる範囲

電力計は DUT の電源入力に置かれ、そこで引かれる電力を測る。外部冷却設備は含まない。内部ファンや熱制御は入力側にあるため含まれ、温度変化も結果へ影響する。

環境条件は 23〜27 ℃、相対湿度 25〜75%、気圧 812〜1060 hPa とされる。第 03 版は、測定レンジに適した電力計精度を文書化し、各試験結果へ記載するよう求めた。

数値が違うことと、区別可能であることは同じではない。1 W の差が計器精度や平均方法の不確かさより小さければ、順位は表示できても測定からは導けない。計器識別、レンジ、精度仕様、生データ、利用可能な校正記録を残す理由がここにある。

第 03 版は方法の境界も明文化した。これは制御された実験室ベンチマークであり、本番のエネルギー監視・管理フレームワークではない。結果は運用測定の参照にはなるが、実トラフィック、冗長性、施設冷却、電源構成、年間変動を代理しない。

したがって、本稿の対象は炭素削減の帰属ではない。ラボ内で二つの電力効率報告を比べるための条件である。施設やネットワーク全体の結論には別の証拠が必要だ。

安定化と平均化は、隠れた二本の時間軸である

負荷を加えた直後、装置は定常ではない。キャッシュやキューが変わり、温度が上がり、ファンが反応し、制御処理が収束する。短い窓は瞬間を、長い窓は別の運転点を示す。

PowerBench は、負荷・構成の適用から測定開始までの安定化区間と、報告値を算出する測定区間を分けて記録する。平均方法も必要で、負荷水準ごとに異なるなら個別に報告する。

全機器に同じ秒数を強制しないのは現実的である。その代わり、比較責任は開示へ移る。別ラボが同じ熱・ソフトウェア挙動を捉えたか判断できる情報が要る。

同一装置をソフトウェア更新の前後で測る縦断比較でも、時間は重要だ。光部品、カード、バックグラウンド処理、トレース、環境と窓が揃わなければ、バージョン番号へ他の変化を帰属してしまう。

プログラム可能な装置では、コンパイラーも構成部品になる

第 03 版は P4 や FPGA などについて、インストールしたプログラムまたはワークロード、コンパイラー／ツールチェーン版、テーブルや状態付き処理の概要を報告項目へ加えた。

同じ筐体でも、再コンパイル後には別の転送機械として振る舞える。テーブル深度、照合形式、カウンター、レジスター、状態操作はメモリー・アクセスとパイプライン活動を変える。モデル名、OS、ポート数だけでは測定対象を一意にできない。

結果には実行パスポートが必要になる。ハードウェア、ソフトウェア、ラインカード、enabled/active ポート、インターフェースとトランシーバー、設定、利用率、トレース、プログラム、コンパイラー、環境、計器、時間窓を束ねて初めて再現可能な対象になる。

第 03 版が作ったのは勝者ではなく、報告規律である

履歴を見ると、第 03 版は 02 の約三か月後に到着した。実験室と運用管理の分離、電力計精度、入力境界、プログラム可能性、条件と状態の分離、因果表現の慎重化という変更は、一つの方向を向いている。

それでも、凍結資料は特定製品の数値、実装、相互接続試験、導入、フリート節電、炭素削減を示さない。PowerBench 自身も、完璧に規定されてほとんど存在しない少数結果より、不確かさを開示した多数結果を重視する。

だから比較可能性は、差を消すことではなく、差を見える形で保存することから生まれる。

情報源と限界

根拠は第 03 版のテキスト、HTML、XML、Datatracker と履歴、第 02 版、RFC 2544、RFC 6985、RFC 6988、RFC 7460、GREEN 用語草案である。非公開の製品・ラボ資料は使っていない。