Most servers ship on a balanced firmware profile that is nobody's optimum - it leaves latency on the table for performance workloads and burns watts you do not need on idle ones. With UK electricity among the most expensive in Europe, the firmware power profile is both a performance lever and a line on the energy bill. This is how our engineers tune BIOS/UEFI power and performance settings for UK customers, and how to decide which way to push.
Start from the goal: latency, throughput or watts
There is no universally correct profile - there is only the right profile for what the server does. A latency-sensitive trading or real-time application wants every core held at high frequency with deep sleep states disabled, accepting higher idle power. A batch-throughput or virtualisation host wants turbo and all cores working, tuned for sustained all-core performance. A lightly-loaded file or print server wants aggressive power saving so it sips electricity when idle. Decide which of those three you are optimising for before you touch a single setting.
Vendors expose this as named system profiles - Dell calls them System Profiles in iDRAC/BIOS, HPE exposes Workload Profiles in UEFI - and those presets are a sensible starting point. The value is in understanding what they change underneath so you can adjust from the closest preset rather than guessing.
C-states: the idle-power versus latency trade
C-states are CPU sleep states. Deeper C-states cut idle power substantially but add a small wake-up latency when work arrives. For an efficiency-first server that idles much of the day, leave C-states enabled - this is where most of the real-world energy saving lives. For a latency-critical server where consistent microsecond response matters, restrict or disable the deeper C-states so cores never have to wake up, at the cost of higher constant draw.
The mistake is treating C-states as always-on or always-off dogma. They are the single biggest dial between energy efficiency and tail latency, and the right setting depends entirely on whether idle power or wake-up latency costs you more.
Turbo, P-states and the all-core question
Turbo (and the P-state governor behind it) lets cores boost above base frequency when thermal and power budget allow. For bursty or single-threaded work, turbo is free performance - leave it on. For sustained all-core workloads the picture is subtler: maximum turbo on every core raises power and heat and can cause the clock to sag back under thermal limits, so a profile tuned for steady all-core frequency sometimes delivers more consistent throughput than one chasing peak boost.
The energy angle is direct: running cores flat-out at maximum frequency is disproportionately power-hungry, because power rises faster than performance at the top of the frequency curve. For throughput work that is not latency-bound, a slightly lower sustained frequency can cut watts noticeably for a small performance cost - which, at UK energy prices over a server's life, is real money.
- •Performance profile: C-states off, turbo on, max sustained frequency - lowest latency, highest watts
- •Balanced profile: moderate C-states, turbo on - good general-purpose default
- •Power-saving profile: deep C-states, frequency capped - lowest watts for idle-heavy servers
- •Always confirm the change in iDRAC/iLO power telemetry rather than trusting the label
Memory, NUMA and the settings people forget
Power profiles are not only about cores. Sub-NUMA clustering and NUMA node presentation affect how memory latency behaves and should match the workload - exposing NUMA topology helps databases and virtualisation schedule locally. Memory frequency and the controller's own power management interact with the CPU profile, and on some platforms an aggressive power-saving profile will also throttle memory and PCIe links. If you have tuned the CPU for performance, make sure the firmware is not quietly power-capping the memory or I/O underneath it.
Get the underlying hardware right first - balanced memory population and the correct CPU - then tune firmware on top. Our server configuration service sets these profiles to the workload before delivery so the box arrives tuned, not on a generic default.
Validate with telemetry, then standardise
Never trust the profile name - measure. iDRAC and iLO both expose live power draw and per-core frequency, so apply a profile, run the real workload, and read the actual watts and latency back. Tune from there, then standardise the chosen profile across the fleet so behaviour is predictable and the energy footprint is known. A documented, measured profile is worth far more than a vendor preset chosen blind.
When you are ready to set this up at scale, build the platform in our configurator and let us pre-tune it. For vendor-specific firmware walkthroughs, use our Dell PowerEdge and HPE ProLiant configurators as the starting point for the exact model.