Summary

  • draft-ietf-bmwg-powerbench-03 定义的是受控实验室方法，不是生产能耗管理系统，也不是产品排行榜；它把外部输入功率表与明确的设备、流量及环境条件绑定在一起。
  • “Idle+” 会在每个活动接口上双向发送每秒一个包。这个刺激很小，却可能唤醒转发平面，因此 Base、Idle、Idle+、Typical 与带载测量是测试条件，不是通用的设备功率状态。
  • 能源效率比 T/P 的两侧都要有凭据：分子是预先声明权重并实际成功转发的吞吐，分母是带有仪表精度、稳定等待期与平均窗口的输入功率。

一个包把“空闲”拆成了两种事实

先把路由器完整配置好，让所有接口保持 up，却不送任何业务流量，等功率表稳定。这是草案里的 Idle。随后，在每个活动接口上双向发送每秒一个包。这条最小轨迹被设计成足以激活转发平面，又不引入可测的动态包处理功耗。这是 Idle+。

两次实验之间，流量差得几乎看不见，硬件边界却可能已经跨过。某个组件退出低功率状态，转发流水线开始工作，风扇、光模块或后台进程进入另一种节奏。若两份报告都只写“空闲”，一个没有包，另一个有最小轨迹，那么两个瓦特数并不是同一命题。

这正是 2026 年 9 月 30 日发布的 PowerBench 第 03 版最有价值的地方。它不是替行业收集一个漂亮的能耗数字，而是在数字周围建立一份可比较合同。

状态也要说清楚。Datatracker 页面显示它是 BMWG 的活动工作组 Internet-Draft；文档页眉写着拟定 Standards Track，但冻结的文档 API没有填入 intended-level 值。它不是 RFC，不是已经批准的标准，也没有证明任何已命名设备通过了测试。

测量条件不是设备状态

草案列出五类条件。Base 是设备启动完毕、板卡与组件开启、保持工厂设置且不插收发器；Idle 是具备完整转发配置、接口全开但没有流量；Idle+ 加入每秒一个包；Typical 使用明确比例的最大吞吐，例如 30%，并采用 RFC 6985 的 IMIX 包长分布；Power with Traffic Load 则把指定速率送到指定端口或线卡。

第 03 版专门增加了一条边界：这些是 measurement conditions，不是 DUT 或内部组件的 Power States。设备可能在两个条件下保持同一内部状态，也可能在一个条件的测量过程中发生状态转换。各厂商定义状态的方式不同；若状态可从外部观察或由测试人员明确配置，报告应写出状态以及配置或验证机制。这些只是补充上下文，不能替代标准测试程序。

这个区别防止标签借来不属于它的权威。把 Idle 当成设备状态，人们容易相信状态名称已经说明一切；把它当成测试条件，就必须继续问：当时加载了什么配置，哪些接口活动，控制面、管理面、遥测和热管理是否运行，流量与窗口如何设定。草案允许这些后台功能在 Idle 与 Idle+ 时保持活动，但要求报告其运行情况。

这也使本文与链路休眠协议保持清楚距离。PowerBench 不负责协商关断，不保存流量工程状态，不证明独立唤醒路径，更不证明恢复后的转发。它用受控刺激观察 DUT。状态变化可能解释读数，却不是读数本身。

T/P 的分子并非天生确定

能源效率比看起来很简单：EER = T/P，单位是 Gbps/Watt。展开之后，答案取决于事先选择的工作负载。

T 是若干流量等级下接口吞吐的加权和，P 是相同等级下功率读数的加权和。等级与权重必须预先确定。草案举例使用 100%、30%、0% 三档和 0.1、0.8、0.1 的权重，也允许接入路由器、核心路由器与数据中心交换机采用不同组合。

这些权重不是结果周围的文书工作，而是在构造结果。偏向高负载的权重回答一种使用情景，偏向空闲的权重回答另一种。草案还允许用接口总容量替代加权容量作为分子；所得数值按比例变化，但已经不是同一个 EER。若采购表把这些结果全塞进一列再排序，精确的小数可能只是不可比合同之间的装饰。

有效工作还必须真正完成。草案要求包从正确端口转发出去。丢掉流量确实能降低功耗，却不能赢得能效测试。默认要求是零丢包，延续 RFC 2544 的 Non-Drop Rate 逻辑；任何非零容忍值都必须声明并说明理由。被引用的测试程序还要求设备能够回到完整 NDR 负载，否则结果失效。

这条规则守住了最基本的现实层：分母不能靠消灭分子来改善。

功率表也有管辖范围

测试把外部功率表放在 DUT 电源输入端，测量进入设备的电功率。它不覆盖机房外部冷却系统。设备散热依然重要，因为风扇和热控制会消耗设备输入功率，温度变化也会改变行为。因此，报告既要留下环境与温度上下文，又不能假装一只表覆盖了整座设施。

实验室范围被规定为 23–27 °C、25%–75% 相对湿度与 812–1060 hPa 气压。功率表还必须具有适用于被测量程的精度说明，第 03 版把这项要求同时加入测试设置与报告格式。

仪表精度不等于校准历史，两者都不自动证明两个结果足以排序。若两台设备只差一瓦，而仪表量程、精度或平均算法产生了更大的不确定性，表格仍能显示先后，证据却不能支撑这个先后。严肃的实验应保存原始读数、仪表身份、适用精度、量程与可得的校准记录。

第 03 版新增的范围声明同样关键：这是实验室基准，不是生产能耗监控或能源管理框架。它可以给实时监测提供参考，却不能替生产网络回答负载结构、冗余政策、冷却开销、软件漂移与电力来源。

时间是测量的一部分

流量或配置改变后，功率不会瞬间进入永恒稳定值。队列填充、缓存预热、频率变化、风扇响应与控制进程都需要时间。立刻读数会抓到瞬态，等待更久又会抓到另一个运行点。两者都不是脱离上下文的真相。

草案因此要求记录两只钟。稳定等待期从施加流量或配置开始，到正式测量开始为止；测量区间则是产生报告功率值的平均窗口。还要说明平均方法，并在不同负载使用不同区间时逐档报告。

第 03 版没有强迫所有设备使用同一时长。设备类别、实现与环境不同，统一时长未必合理。代价是比较更依赖披露：另一家实验室必须能够判断自己的窗口是否覆盖了同类行为。

纵向比较也因此既有价值又有风险。同一机箱在软件升级前后重复测试，可以发现真实变化；但只有硬件、固件、收发器、后台功能、流量轨迹、环境与时间窗口都被保留，差异才能归因于升级。“B 版本更省电”必须是一项受控差异结论，而不是从版本号自动生成的属性。

可编程转发把编译器也带进设备身份

固定功能设备已经需要报告硬件和软件版本。第 03 版又为 P4、FPGA 等可编程数据平面增加了三类上下文：所装程序或工作负载、编译器或工具链版本，以及表项和有状态操作的高层描述。

原因很直接：同一台物理交换机重新编译后，可以成为另一台转发机器。表深、匹配结构、计数器、寄存器和有状态操作都会改变存储访问与流水线活动。只写机箱型号与端口数量，已经不足以标识测试对象。

因此，报告应成为一次受限执行环境的“护照”：硬件、系统软件、线卡、启用与活动端口、接口与收发器、端口设置、利用率、轨迹、可编程负载、编译器、环境、仪表、时间窗口与结果。删掉足够多字段后，“PowerBench”只剩下一个与实际机器脱离的营销名词。

第 03 版修复了证据语法，没有制造赢家

修订历史显示，第 03 版在第 02 版三个月后到来。变更相当集中：增加实验室与生产管理的边界，明确仪表精度与输入功率边界，补入可编程数据平面上下文，并把测量条件与 Power State 分开。旧版把 Idle+ 描述成让设备离开某个“低功率模式”，新版改为更谨慎的“可能捕捉”一次状态转换。

这些修改使结果更可解释，却没有证明哪款设备领先、哪个实现已部署、哪次互操作成功、节省了多少电，更没有给出碳排结果。冻结资料没有这些事实。草案甚至公开接受一种取舍：与其只留下少数极度精确却难以横向比较的实验，不如获得更多带有较高不确定性、但充分披露条件的结果。

这使披露本身成为核心控制。PowerBench 最强之处不是承诺一个万能分数，而是让分数背后的选择难以隐藏。

来源与边界

本文使用冻结的第 03 版文本、HTML 与 XML，Datatracker 页面、API 与历史，第 02 版，以及 RFC 2544、RFC 6985、RFC 6988、RFC 7460 与 GREEN 术语草案。未使用私有实验室数据或厂商结果。