Data centre PUE: what ITU-T L.1302 says, and who actually holds the figure

How much did your data centre consume last month? How much of that went to the IT load, and how much to cooling? And what measurements back that figure up — which instrument, at which point, on what date? Whoever runs a hall, or buys capacity in one, hears the first question in every serious negotiation. The second, almost never — yet it is the one that decides whether the first answer holds up to scrutiny or is a guess repeated from memory for a year.

A 2015 recommendation, still in force

There is a public method for answering with a verifiable figure: ITU-T Recommendation L.1302 (11/2015), Assessment of energy efficiency on infrastructure in data centres and telecom centres, approved on 29 November 2015 by Study Group 5 and still the only edition in force, as verified on the official ITU page. The scope, verbatim: “This Recommendation specifies an energy efficiency assessment methodology of the infrastructure of data centres and telecom centres under running conditions” — it specifies an assessment methodology for the energy efficiency of data centre and telecom centre infrastructure in operation, not at design stage or initial commissioning. It covers three distinct scopes: the whole data centre, a part of it, and, separately, the power feeding system and the cooling system.

L.1302 doesn’t invent PUE: it fixes the method

The definition of PUE that L.1302 adopts comes from another source, stated in clause 3.1.3: “Ratio of the data centre total energy consumption to information technology equipment energy consumption, calculated, measured or assessed across the same period” — the source cited is ISO/IEC 30134-2. What L.1302 adds is the part a specification actually needs: where to measure and how often. The formula, in clause 7.5: PUE = E_DC/E_IT. If it is not practicable to measure the energy at every IT input terminal, the document allows a calculated figure: E_IT = E_AR × η_IT-PDU, with the transport efficiency derived from the voltage drop between the array cabinet and the IT rack — a declared approximation, not a measured one. For part of a hall there is pPUE = EpDC/E_IT (clause 7.6); for cooling alone the standard does not use EER, because “it is difficult to measure online cooling system parameters, such as output air volume and energy efficiency ratio (EER)”, and recommends CLF = E_C/E_IT instead (clause 9.5) — a declared substitute, not an equivalent to EER.

Twelve months, not a snapshot

Clause 7.2 sets the period: “The assessment period should be of twelve months, considering that the cooling system energy efficiency varies according to the outside temperature” — the assessment period should be twelve months, because cooling efficiency varies with outdoor temperature and power feeding efficiency with load rate. If the period is shorter, the standard does not forbid it but conditions it: “a justification of the assessment period used is required and should be documented in the final report.” On frequency: continuous measurement at least every 30 minutes; if measurement is discontinuous, still every 30 minutes when it happens, with an assessment at least hourly and at least twice a day for at least three days a month — again with a written justification required. Instruments carry their own accuracy table (clause 7.1): temperature ±0.5°C, humidity ±5.0%, voltage and current ±1.0%, power ±3.0%, energy Class 1 under IEC 62053-21. And the conditions of measurement — temperature, humidity, load rate — “need to be documented in the energy efficiency report”: written into the record, not left inside the final number alone.

Five different places

The method is ten years old. The problem, in the pattern we find recurring on a site visit, is not the formula: it is that the data the formula asks for sits in five different places, and none of the five answers on its own. General meter readings sit with billing or admin. Uninterruptible power supply and switchboard data sit in the supervisory system — often proprietary, often not exportable into a format a third party can read. Temperatures and air-conditioner loads sit in the BMS. The IT equipment inventory and its rated draw sit in a spreadsheet in the IT department, updated whenever someone remembers to. Supply contracts and service levels sit with admin, in yet another drawer. A PUE calculated from measurements taken by five systems that don’t talk to each other is a figure nobody can reconstruct a year later — which is exactly why L.1302 asks for twelve months, documented conditions, and a written justification every time the full method is not followed.

Without a point, a date and an instrument, it isn’t a verifiable measurement

A PUE figure without a declared measurement point, the date of the reading and the instrument it was taken with cannot be verified — the same holds for energy as for any other acceptance measurement. We wrote about this regarding instrument calibration: a Class 1 energy meter with no record of calibration, or no known date for its last check, produces a plausible figure, not a traceable one. L.1302 requires instrument accuracy as a clause-level requirement; it does not require — the text is silent on it — traceable calibration of the meter itself. That is a clause to add separately, if the declared PUE is meant to withstand an independent audit.

See the service · Talk to an engineer

What we don’t know

Compliance with ITU-T recommendations is voluntary, as the text itself states up front: “Compliance with this Recommendation is voluntary.” L.1302 has no non-integral appendices — unlike other recommendations in the same series, its calculation formulas all sit in the normative body (clauses 7.5, 8.5, 9.5), not in an annex declared non-binding. We are not asserting an Italian or EU obligation to measure PUE for every data centre: at EU level there is a reporting obligation above 500 kW of installed IT power, with its own methodology set out in delegated regulation (EU) 2024/1364 — we have written about it here — but that is a different regime, with a distinct threshold and technical references — including the EN 50600-4 series, from the same family we have already written about for its availability classes, a paid text we have not read: L.1302 is a voluntary method, useful below that threshold too, not a substitute for it.

Two threads, applied to this account

The first thread is specifying the method, not the number: measurement points on every branch L.1302 treats as distinct — HV/MV/LV input, UPS output to the IT load, the cooling switchboard — with the chosen frequency (continuous at 30 minutes, or discontinuous with a written justification), the instrument with its accuracy class and calibration certificate, the format each system exports the data in, and the single archive everything flows into. At acceptance, we verify that every declared measurement exists, tied to an identified point and a date — not a PUE handed over as a single figure with no supporting trail.

The second thread is what makes that data useful beyond the first report. General meters, electrical supervision, the BMS, the equipment inventory and supply contracts stop being five separate archives and become, for a data centre, together with CSIDIA, the group’s other company, a single model, on which an AI runs the diagnosis: on a data centre, diagnosis is not one month’s reading, it is the comparison across successive months referred to the same measurement points — a CLF that dips in July but not in January, a PUE that climbs while the IT load stays flat. Within the client’s own perimeter: on-premise, on autonomous machines with no deep integration into the existing network, or a dedicated cloud with a data centre in Italy, always with shared management between the two teams.

The site visit, at no cost, produces a list of your measurement points — with, for each one, what it measures, with which instrument, how often, and where the data ends up today. Including the boxes that stay empty: that list is yours to keep even if we don’t go on to work together.