Summary

  • La revisión 03 de draft-ietf-bmwg-powerbench define un contrato de laboratorio para medir dispositivos de red. No es un sistema de gestión energética en producción ni certifica un ganador.
  • El EER se expresa como T/P, pero T y P son sumas ponderadas sobre cargas elegidas de antemano. Cambiar niveles, pesos o usar capacidad total en lugar de ponderada cambia la pregunta.
  • La condición Idle+ envía un paquete por segundo en ambos sentidos por cada interfaz activa. Puede activar el plano de reenvío y demuestra que una condición de medida no equivale a un Power State universal.

Primero se elige la pregunta; después aparece el número

El Energy Efficiency Ratio de PowerBench cabe en una línea: EER = T/P. El resultado se expresa en Gbps/W y parece listo para ordenar una tabla de compra. Sin embargo, T no es “el rendimiento” sin más y P no es “el consumo” sin más.

T suma capacidad de interfaces con ponderaciones para varios niveles de carga. P suma las lecturas de potencia en esos mismos niveles y con los mismos coeficientes. La revisión 03 pone como ejemplo cargas de 100 %, 30 % y 0 %, con pesos de 0,1, 0,8 y 0,1, pero permite perfiles distintos para acceso, núcleo y centros de datos.

Un perfil que valora mucho el 30 % representa una red. Uno dominado por el reposo representa otra. Ambos pueden estar bien ejecutados. No contestan la misma pregunta. Además, el borrador permite sustituir la capacidad ponderada por la capacidad total de interfaces. El valor obtenido es proporcional, pero el numerador ya cambió. Mezclarlo con el primero en una sola columna crea una clasificación matemática de contratos incompatibles.

El trabajo útil tampoco se presume. Los paquetes deben salir por el puerto correcto. El requisito por defecto es pérdida cero, coherente con el Non-Drop Rate de RFC 2544. Toda tolerancia distinta de cero debe declararse y justificarse. Reducir vatios descartando tráfico sería una buena optimización del denominador y un fracaso completo del servicio.

Por eso la fracción peligrosa no es una fórmula incorrecta. Es una fórmula correcta a la que se le han quitado las decisiones que construyeron sus dos términos.

Un paquete por segundo separa dos reposos

PowerBench usa cinco condiciones. Base mide el equipo recién arrancado con configuración de fábrica, componentes activos y sin transceptores. Idle lo deja totalmente configurado para reenviar, con todas las interfaces levantadas, pero sin tráfico. Idle+ introduce el flujo mínimo: un paquete por segundo, bidireccional, en todas las interfaces activas. Typical aplica un porcentaje declarado del rendimiento máximo con mezcla de tamaños RFC 6985 IMIX. La prueba cargada trabaja sobre puertos o tarjetas específicos.

El paquete por segundo pretende activar el plano de reenvío sin añadir potencia dinámica medible por procesamiento. Es pequeño en volumen y grande en significado. Un componente puede salir de un estado de bajo consumo; pueden cambiar canalizaciones, relojes, ventiladores o tareas internas. Dos informes llamados “idle” quedan separados por una transición real.

La revisión 03 aclara que Base, Idle, Idle+, Typical y carga son condiciones de medida, no Power States del DUT. El dispositivo puede conservar estado entre condiciones o cambiar dentro de una. Si el estado es observable o fue configurado de forma explícita, debe añadirse al informe junto con el mecanismo usado para verificarlo. No sustituye la prueba.

La nueva redacción corrige una presunción de la revisión 02. En vez de afirmar que Idle+ saca al equipo de su modo de bajo consumo, dice que la diferencia puede capturar una transición. Ese verbo protege la causalidad: el medidor observa un cambio; para identificar su origen hacen falta más datos.

Los procesos de control, gestión, telemetría y regulación térmica pueden permanecer activos en Idle e Idle+. Su estado debe constar. Apagarlos para una prueba y mantenerlos en otra altera el objeto comparado aunque el nombre comercial del equipo no cambie.

El medidor tiene una frontera física y una incertidumbre

El montaje conecta un generador de tráfico y un medidor externo al DUT. El medidor observa la potencia eléctrica en la entrada del equipo. No incluye la refrigeración externa del edificio. La disipación sigue importando porque los ventiladores internos consumen dentro de la frontera y la temperatura modifica su actividad.

Las condiciones prescritas son 23–27 °C, 25–75 % de humedad relativa y 812–1060 hPa. La revisión 03 exige además documentar una precisión apropiada para el rango de potencia y reproducir esa especificación en el informe.

Dos lecturas distintas no garantizan dos rendimientos distinguibles. Si la separación es menor que la incertidumbre combinada del instrumento, rango y promediado, ordenar los equipos sería una decisión administrativa, no una conclusión metrológica. Conviene conservar instrumento, rango, precisión, lecturas crudas y evidencia de calibración disponible.

La frontera también limita la interpretación empresarial. Un equipo que consume menos en su entrada no ha demostrado el consumo total del emplazamiento. Tampoco ha demostrado carbono, coste eléctrico, refrigeración, redundancia ni rendimiento anual. La revisión 03 declara expresamente que su método es de laboratorio y no un marco operativo de supervisión o gestión energética.

Esta comisión, por tanto, no repite la cuestión más amplia de atribución verde. Analiza cuándo dos ensayos del mismo tipo pueden compararse. El laboratorio crea una referencia; producción conserva su propia realidad.

El tiempo puede mover el denominador

Al aplicar una carga, el equipo atraviesa un transitorio. Se llenan colas, se calientan componentes, cambian relojes, actúan ventiladores y convergen procesos. Una lectura tomada de inmediato y otra tras diez minutos pueden ser fieles y describir regímenes distintos.

PowerBench exige informar el intervalo de estabilización —desde la aplicación de carga o configuración hasta el inicio de la medida— y el intervalo de medida o ventana de promedio. También debe constar el método de promedio y, si cambia, cada valor por nivel de carga.

No fija una duración universal. La flexibilidad evita prescribir un tiempo absurdo para todas las clases de equipo, pero convierte la transparencia en requisito de comparabilidad. Otro laboratorio debe poder decidir si su ventana atraviesa la misma dinámica térmica y de software.

En comparaciones longitudinales, el problema se vuelve de causalidad. Medir el mismo equipo antes y después de una actualización puede mostrar una mejora real. Pero hay que congelar ópticas, tarjetas, programa, procesos, trazas, ambiente y ventanas. De lo contrario, el número de versión recibe crédito por cambios ajenos.

En un plano programable, el compilador forma parte del DUT

La revisión 03 añade para P4, FPGA y otros planos programables el programa o carga instalada, la versión del compilador o cadena de herramientas y una descripción de tablas u operaciones con estado. Es una corrección de identidad: el mismo chasis puede implementar otra máquina de reenvío después de compilar.

Profundidad de tablas, patrones de coincidencia, contadores, registros y operaciones con estado cambian accesos a memoria y actividad de canalización. Modelo, firmware y puertos ya no bastan para reproducir el objeto probado.

El informe completo funciona como un pasaporte: hardware, software, tarjetas, puertos habilitados y activos, transceptores, ajustes, utilización, traza, programa, compilador, ambiente, medidor, intervalos y resultado. El nombre PowerBench sin ese pasaporte puede circular mucho más lejos que la evidencia que lo produjo.

Una revisión que fortalece el informe, no el resultado

El historial del Datatracker fecha la revisión 03 el 30 de septiembre de 2026, tres meses después de la revisión 02. La página del documento lo mantiene como Internet-Draft activo de BMWG. El encabezado propone Standards Track; la API congelada no registra nivel previsto. No es RFC ni aprobación final.

Las adiciones —alcance de laboratorio, precisión del medidor, frontera de entrada, contexto programable, distinción condición/estado y lenguaje causal más prudente— mejoran la auditabilidad. No aportan mediciones de un producto nombrado, despliegue, interoperabilidad, ahorro de flota o reducción de carbono. Ninguna fuente congelada contiene esos resultados.

El propio borrador prefiere muchos puntos con incertidumbre declarada a unos pocos ensayos tan prescritos que apenas existan. La consecuencia es clara: la comparabilidad no nace de borrar las diferencias, sino de exponerlas.

Fuentes y límites

Se revisaron el texto, HTML y XML de la revisión 03, Datatracker, historial, revisión 02, RFC 2544, RFC 6985, RFC 6988, RFC 7460 y el borrador terminológico GREEN. No se usaron datos privados ni resultados de proveedores.