Cutting Data Center Cooling Energy Without Leaking Secrets
Cooling accounts for 30–40% of data center electricity use. Operators need to cut that cooling demand and total facility energy for the same computational workload on standard hardware, without making sensitive data easier to infer. Processors adjust voltage and clock speed to control chip heat and power, but these adjustments can turn data-dependent power use into measurable timing differences; researchers demonstrated cryptographic key theft this way in Hertzbleed (2022). Restricting clock speeds limits energy-saving options, and attackers can still exploit timing differences caused by power-dependent decisions about where tasks run. The challenge is to manage processor power or remove heat more efficiently without creating or widening leaks through timing, clock speed, power use or task scheduling.
Borrowing the aorta’s elastic storage, we buffer a server rack’s power and heat pulses so warm-liquid cooling can save energy without adding new clues about private computations.
How it works
Processors change power use as they work on different data. Automatic speed and cooling adjustments can turn those changes into clues an attacker can measure; locking processor speed removes one route for leakage but costs energy. We propose borrowing the aorta’s way of smoothing heartbeats: store part of each pulse and release it between pulses. A rack-level electrical store supplies bursts of power and recharges between them. A warm liquid loop absorbs heat as coolant boils, while a wax-based heat store melts near 48°C to spread heat release over time. We choose both buffers’ response times to smooth the pulse patterns measured in leakage tests. Processors follow a public, clock-based speed schedule with workload-responsive feedback disabled, and cooling controls use weather and planned rack capacity rather than live computation data. The buffers spread energy over time; they do not hide total consumption. The energy savings come from warm-liquid cooling, which reduces fan and refrigeration work, while the buffers support operation without data-responsive controls.
Borrowing Valiant load balancing from communication networks, we randomly deal frozen work across coolant branches to bound heat concentration and reduce the extra cooling kept for hot spots.
How it works
Data centers keep extra cooling capacity because too much hot work can land on one coolant branch, by accident or by design. We borrow a network-routing method that spreads traffic independently of its contents. First, the dispatcher freezes a batch of jobs, each with a bounded energy demand. Only then does it generate a fresh secret shuffle and deal the jobs across coolant branches, with job counts differing by at most one. A submitter therefore cannot tailor a job to its assigned branch. Equal job counts alone do not guarantee equal heat: we combine the shuffle’s mathematics with measured cooling-system behavior to calculate a high-probability limit on the hottest branch’s temperature above the average. Operators use that limit to reduce only the cooling reserve held for uneven heat, while preserving other safety margins and keeping CPU speed and scheduling settings fixed. Whole-facility meters confirm that lower pump and fan energy exceeds the extra energy spent distributing the work.
Borrowing the holding-basin principle from wastewater treatment, we pool fixed amounts of scheduled computer work and use only the total level and public schedules to adjust server speed, cutting energy use without exposing secret-dependent activity.
How it works
A shared server can reveal clues about private calculations when its speed changes in response to their power use. Keeping speed fixed blocks that route but limits energy savings. Wastewater plants offer another approach: collect uneven inflows in a basin, then release them at a controlled rate. Here, each batch job contributes a fixed allotment of execution tokens to a shared work reservoir. The controller uses only its coarse total level, the clock and public schedules or forecasts to choose among speed settings tested to avoid automatic power- or heat-driven slowdowns. It never reads tenant identity, live power or job completion. If a job finishes early, declared operator work or filler consumes its remaining tokens on schedule; each tenant keeps a fixed share that nobody else can borrow. Private execution therefore cannot change the token level or a neighbor’s allocation. An offline energy table guides speed selection to cut electricity for both computing and cooling, while allowing delay-tolerant jobs to meet their public deadlines.