Summary

  • draft-ietf-bmwg-powerbench-03 beschreibt ein kontrolliertes Laborverfahren mit externem Leistungsmesser. Es ist weder Betriebs-Energiemanagement noch Produktzertifizierung.
  • Idle+ sendet bidirektional ein Paket pro Sekunde über jede aktive Schnittstelle. Schon dieser minimale Reiz kann die Forwarding Plane aktivieren; Messbedingungen sind deshalb nicht mit internen Power States gleichzusetzen.
  • Für einen belastbaren Vergleich müssen Zähler und Nenner denselben Vertrag teilen: vorab gewählte Lastgewichte, tatsächlich weitergeleiteter Verkehr, Gerätekonfiguration, Messgenauigkeit, Stabilisierung und Mittelungsfenster.

Die Zahl ist exakt, das Messobjekt womöglich nicht

Ein Leistungsmesser zeigt 212,4 Watt. Ein zweiter Bericht nennt 210,9 Watt. Die Nachkommastelle suggeriert, das zweite Gerät sei effizienter. Doch vielleicht verwendete Bericht A drei Laststufen mit IMIX, Bericht B Gesamtkapazität als Zähler; vielleicht lief bei A Telemetrie, bei B nicht; vielleicht maß einer nach zwei Minuten und der andere nach einem vollständigen Wärmezyklus.

Der PowerBench-Entwurf in Revision 03 versucht, solche Zahlen nicht zu verbieten, sondern ihr Messobjekt zu identifizieren. Ein Resultat besteht aus Gerät, Programm, Port- und Optikpopulation, Verkehr, Lastprofil, Umwelt, Instrument und Zeit.

Sein Status bleibt dabei begrenzt. Der Datatracker führt ihn als aktiven BMWG-Arbeitsgruppenentwurf, Revision 03 vom 30. September 2026. Der Kopf nennt Standards Track als Ziel; die eingefrorene Dokumenten-API enthält kein intended level. Es ist kein RFC, keine IESG-Genehmigung und kein Nachweis für ein bestimmtes Produkt.

Ein Paket pro Sekunde ist eine Zustandsprobe

Base misst Werkseinstellungen nach dem Booten, aktive Baugruppen, aber keine Transceiver. Idle bedeutet vollständig für Weiterleitung konfiguriert, alle Schnittstellen up, jedoch kein Verkehr. Idle+ fügt auf jeder aktiven Schnittstelle 1 pps in beiden Richtungen hinzu. Typical nutzt einen angegebenen Anteil des maximalen Durchsatzes mit RFC-6985-IMIX. Die Lastprüfung nennt Rate, Ports und Linecards.

Das einzelne Paket soll die Forwarding Plane aktivieren, ohne messbare dynamische Paketverarbeitungsleistung zu erzeugen. Es kann dennoch Pipeline, Takt, Speicher oder Kühlung über eine Schwelle schieben. Zwei „Idle“-Werte können damit verschiedene ausführbare Maschinen beschreiben.

Revision 03 trennt daher Messbedingung und Power State. Ein DUT kann zwischen Bedingungen im selben Zustand bleiben oder innerhalb einer Bedingung wechseln. Ist ein Zustand beobachtbar oder konfiguriert, sollte der Bericht Zustand und Nachweismechanismus nennen. Er bleibt Zusatzkontext.

Auch Kontroll-, Management-, Telemetrie- und thermische Prozesse dürfen unter Idle und Idle+ laufen. Ihr Zustand muss dokumentiert werden. Wer sie nur in einem Versuch abschaltet, hat das Messobjekt verändert, auch wenn die Modellnummer gleich bleibt.

Gegenüber Revision 02 ist die Kausalität vorsichtiger formuliert. Idle+ verlässt nicht automatisch den Low-Power-Modus; die Differenz kann eine Zustandsänderung erfassen. Der Messwert zeigt einen Effekt, nicht von selbst dessen Ursache.

T/P enthält eine Geschäftsentscheidung

Der Energy Efficiency Ratio lautet EER = T/P. T ist die gewichtete Summe von Schnittstellendurchsätzen bei mehreren Laststufen; P ist die gleich gewichtete Summe der Leistungsmessungen. Lasten und Faktoren müssen vorab feststehen.

Als Beispiel nennt der Entwurf 100, 30 und 0 Prozent mit Gewichten 0,1, 0,8 und 0,1. Zugang, Kern und Rechenzentrum dürfen andere Profile verwenden. Damit wird nicht bloß gerechnet: Die Gewichte bestimmen, welche Betriebswirklichkeit der Score wertschätzt.

Optional kann Gesamtkapazität statt gewichteter Kapazität in den Zähler eingehen. Der Wert bleibt proportional, beantwortet aber eine andere Frage. Beide Varianten in derselben Gbit/s/W-Spalte zu sortieren, verwechselt Dezimalgenauigkeit mit semantischer Vergleichbarkeit.

Pakete müssen außerdem am richtigen Port austreten. Standard ist Nullverlust nach der Non-Drop-Rate-Logik von RFC 2544. Jede Nichtnull-Toleranz ist offenzulegen und zu begründen. Ein zitiertes Verfahren disqualifiziert das Ergebnis, wenn das Gerät nicht zur vollen NDR-Last zurückkehrt.

So verhindert die Methode, dass der Nenner sinkt, weil der Zähler vernichtet wurde. Nicht erledigte Arbeit ist keine Effizienz.

Der Messbereich endet am Stromeingang

Der externe Zähler misst die elektrische Aufnahme am DUT-Eingang. Externe Gebäudekühlung liegt außerhalb. Interne Lüfter und Wärmeregelung liegen innerhalb, weshalb Temperaturänderungen relevant bleiben.

Vorgeschrieben sind 23–27 °C, 25–75 Prozent relative Feuchte und 812–1060 hPa. Revision 03 verlangt eine für den Leistungsbereich geeignete Genauigkeitsspezifikation und deren Angabe pro Test.

Ein Unterschied von einem Watt kann kleiner sein als die kombinierte Unsicherheit aus Gerät, Bereich und Mittelung. Dann existiert eine numerische Reihenfolge, aber kein metrologisch belastbares Ranking. Instrument-ID, Bereich, Genauigkeit, Rohwerte und vorhandene Kalibrierung gehören deshalb in die Beweiskette.

Der Entwurf grenzt sich ausdrücklich von operativem Monitoring und Energiemanagement ab. Laborwerte können Betriebsdaten ergänzen. Sie beweisen weder Standortverbrauch noch Kühlung, Jahreslast, Redundanz, Strommix oder Kohlenstoffwirkung.

Zwei Zeitfenster gehören in jeden Wert

Nach einer Laständerung füllen sich Queues, Caches erwärmen sich, Takte und Lüfter reagieren. PowerBench trennt die Stabilisierung – von Anwendung der Last oder Konfiguration bis zum Messbeginn – vom Messintervall, über das der Wert gemittelt wird. Auch die Mittelungsmethode und abweichende Fenster je Last sind anzugeben.

Eine Einheitsdauer gibt es nicht. Das ist praktisch, aber es verschiebt Verantwortung in die Dokumentation. Ein anderes Labor muss erkennen können, ob es denselben thermischen und softwareseitigen Abschnitt beobachtet hat.

Beim Vergleich einer Softwareversion mit ihrer Vorgängerin ist dies besonders wichtig. Optiken, Karten, Hintergrundprozesse, Trace, Umwelt und Zeit müssen gleich bleiben, sonst wird dem Versionslabel eine fremde Ursache zugeschrieben.

Programmierbarkeit macht den Compiler zum Gerätebestandteil

Für P4-, FPGA- und ähnliche Datenebenen ergänzt Revision 03 installiertes Programm oder Workload, Compiler-/Toolchain-Version sowie eine grobe Beschreibung von Tabellen und zustandsbehafteten Operationen.

Dasselbe Chassis kann nach der Kompilierung eine andere Forwarding-Maschine sein. Tabellen, Matches, Zähler und Register ändern Speicher- und Pipeline-Aktivität. Modell, Betriebssystem und Portzahl reichen als Identität nicht mehr.

Der Ergebnispass muss Hardware, Software, Linecards, enabled und active Ports, Schnittstellen, Transceiver, Einstellungen, Auslastung, Trace, Programm, Compiler, Umwelt, Instrument und Fenster verbinden.

Die Historie zeigt hinter den Änderungen einen gemeinsamen Zweck: Laborumfang, Messgenauigkeit, Eingangsgrenze, programmierbaren Kontext, Bedingung versus Zustand und vorsichtigere Kausalität offenzulegen. Das verbessert den Bericht, nicht automatisch das Produkt.

Die eingefrorenen Quellen enthalten keine benannte Messung, Implementierung, Interoperabilität, Einführung, Flotteneinsparung oder Kohlenstoffreduktion. PowerBench bevorzugt viele transparent unsichere Datenpunkte gegenüber wenigen beinahe unmachbaren Idealtests. Vergleichbarkeit entsteht folglich durch sichtbare Unterschiede.

Quellen und Grenzen

Verwendet wurden Text, HTML, XML, Datatracker und Historie, Revision 02, RFC 2544, RFC 6985, RFC 6988, RFC 7460 und der GREEN-Terminologieentwurf. Private Labordaten wurden nicht genutzt.