[F] Undervolting in BIOS/UEFI

Can we have access to the BIOS/UEFI CPU voltage offset settings please? To allow us to overclock and undervolt etc?

To explain what this means to other people, our CPU’s are throttled at 7 watts. Watts are calculated from multiplying current by voltage, and Intel designs a very safe voltage for all their CPU’s within the median range by which they can operate. However as all chips vary somewhat in their manufacturing some are fully capable of running at lower voltages, and still produce the same GHz. Thus when it’s baseline is set to using less voltage it produces more GHz before reaching the 7 watt throttling limit. This secures more raw processing power, better battery life, and better temperatures! It’s essentially fine tuning your V to be it’s best within it’s own limits.

It would also be nice to get access to the same for the GPU.

And FYI, no computer comes pre-tuned. It’s like buying a guitar, you have to make those fine adjustments yourself!

Would be great to have that option in the bios instead of using 3rd party tools


Yes. Yes. Yes. Yes. Yes.


Hope I explained it sufficiently after all your help :joy::joy:




Now let’s get some beer :beers:


Can’t we just use a third party application like Throttlestop or Intel XTU? Personally I’m using Throttlestop on my ASUS Zenbook for undervolt and it works very well.

I wouldn’t consider the Intel XTU as a 3rd party application. Since it is the official application from Intel for their CPUs.
This is definitely worth a try.

I have used this. But it would be nice to not use software to achieve results, and I imagine they must have had some kind of BIOS way of achieving this during manufacturing?


I suppose you’re right, but in my opinion between XTU and ThrottleStop, I’d have to say ThrottleStop is much better because you can set it up in a way that keeps the undervolt settings permanent and also have it set on reboot.

It would be nice to have 1 less program that needs to be running in the background.

1 Like

I thought the program just sets the parameters and then you can just quit the program. I.e. You don’t need to keep it running in the background. You just need it to run (and then quit) on startup. Maybe I’m wrong

When it’s done within BIOS aka UEFI, that is one less program to worry about.
Not to mention on how much more stable that way of overclocking / underclocking is…

1 Like

Intel XTU keeps forgetting the profile personally. However I am very new to this type of tinkering.

But intuitively I feel it’s unusual that intel can block tinkering with the CPU in the BIOS, but then provide you software to do the same thing anyway regardless of whether they blocked it in the BIOS. It seems odd to do that and subsequently offer that software.

1 Like

It seems that I’ve been hearing from some folks using XTU that it can be unstable especially waking up from sleep. It would be nice not to have to rely on software to do this.

1 Like

@Helios / @iKirin / @nawthor, do you think we could merge this thread and the one below?

if there were some way to have @Niloc and @iKirin moderate it as a wiki, we could use combine these and have it as kind of like a most wanted bios options kind of thing.

for my part, i’d like to see some options that would allow us to tweak the Intel Dynamic Platform & Thermal Framework config.

You can set throttlestop to launch at startup, apply undervolts and quit the process quite painlessly.

but i find that it doesn’t consume very much resources, so i leave it running in the background to switch profiles when i go from plugged in to battery.

if you want to tweak the wattage, however, you’ll need to do some finangling with XTU and its not always reliable.

There are two ways to go about it, one more harmless and one more radical. You could either work on the ACPI layer by, for instance, patching the differentiated/secondary description tables. One approach would be to completely override the cpu descriptor with another cpu (ie i5) of the same family, or even enforcing the generated P and C states. This will have to go before the OS commences (via the bootloader perhaps). This could be perhaps ideal in this case . The latter approach is to modify the firmware parameters directly, and therefore can be considered way more risky, however more resilient/persistent