• Welcome to Overclockers Forums! Join us to reply in threads, receive reduced ads, and to customize your site experience!

12700k quick n' dirty undervolting/downclocking

Overclockers is supported by our readers. When you click a link to make a purchase, we may earn a commission. Learn More.

Max0r

Member
Joined
Oct 18, 2005
Location
Chicago Burbs
My main reason for posting this here is so if anyone who knows something about this is so-inclined, I am open to suggestions/insight that can be offered.

My plan has been and still is to see how far I can undervolt, and maybe even underclock, to minimize wattage being pulled by this 12700k, to minimize heating up my ezbake oven of a room this summer. Similar to what I did with my GPU, I'll probably end up mapping out a bunch of potential stability points, working my way down in voltage until I get obvious instability, then downclocking, and pushing down voltage even more. In preparation for this I thought I'd try to learn what I need to know through edumacation.

After about a combined 2-5 hours watching some videos, reading some stuff, that goes into all the different mechanisms/settings of Alder Lake, I've come to two conclusions.

1) If you need a good sleep aid, nothing will beat watching these videos.
2) Unless you plan on getting an unofficial bachelor's degree in Alder Lake tweaking, best to just stick to some quick n' dirty methods.

So I've begun in earnest trying to use the lowest effort method to map out minimum voltages for different clocks on the p-cores, and maybe I'll even mess with the e-cores, but they're so god damn efficient to begin with, why bother underclocking those. I know I'm probably leaving some wattage savings on the table, and some clock rates on the table, by doing it the easy way, but if it's literally 200 times easier to do it this way, I think I'm fine with that.

For initial testing I'm messing with Intel XTU, using the usual adaptive voltage with the processor doing its usual per-core automatic core ratio adjustment based on utilization. The only thing I'm changing is the voltage offset, which I can see is affecting the voltages of all states from idle to full load. When going into the MSI BIOS, it appears that using the adaptive voltage + offset method, and entering in a minus offset, is leading to similar/same results as what I'm doing in XTU.

2022-04-12_105753.png

So I've been slowly easing into a voltage offset down, switching between Cinebench R23 and Prime95 small FFTs with AVX enabled. So far haven't run into any problems.

My main concern is potential instability at idle & how to test for that. It seems the minimum core ratio at idle is 5x. And the voltage offset certainly affects all the individual ratios. This is good. I like the idea of being able to save power at all levels of CPU draw. However, it also massively complicates things when it comes to squeezing out every last bit of power savings or overclock, especially since how do you stability test those lower core multiplier ratios? I can't figure out how to manually set them below 36x on the p-cores. Instead, it seems like the default thing to do would just be load-testing increasingly lowered voltage offsets until finding the potential stability limit, and then the only thing to do would be to use the system normally or let it sit at idle and just wait until something goes wrong. If it never does, it's "stable" and if it does, then the voltage can be bumped up one notch. This to me seems like a horrible way of going about things, but I can't think of anything better.
Post magically merged:

This is where I'm at right now and still pushing lower on the voltages. I decided to occasionally test at 36x just to see if the voltage curve is stable for "maximum underclocking" on the p-cores at whatever offset I'm testing. But this screenshot is from 47x.

2022-04-12_112041.png
Post magically merged:

This is testing -0.040v btw, and here's a screenshot for testing 36x.
2022-04-12_112555.png

2022-04-12_112503.png
 
Last edited:
I can't say I have any advice (surprised? :p). You have the right idea in process and testing to me (as clumsy as that 'idle' testing is). To me, what method you use (offset, adaptive, etc.) is a matter of personal preference and how you want the machine to behave. A 'fixed' voltage isn't the answer as it won't drop on idle, but adaptive and offset are both candidates for the job.

I'm interested to see some before and after benchmarks when you're done to see how much power was saved versus how much performance is lost (I don't imagine too much).
 
I'm interested to see some before and after benchmarks when you're done to see how much power was saved versus how much performance is lost (I don't imagine too much).
Yes I shall do that. I'd be interested as well :p

Have you tried using the voltage frequency curve, should be accessible in that BIOS somewhere
I can't find any such curve in the BIOS. The closest thing I could find is this:
Advanced_Offet_Mode_00.png
Advanced_Offet_Mode.png

Doesn't seem too advanced to me. I wonder if it interpolates the voltage in the ratios between the ones offered there to tweak. This may certainly allow some extra tweaking if only certain ratios/voltages are giving problems, but most are fine at a given overall offset.

I found one other thing of potential interest. Apparently you can also manually set each individual core target ratio. I don't know if this ratio is for when the core is at full load or all the time, but it will be something to mess with later.


Per_Core.png

With this mode, the lowest possible setting is 4x. So this might be a way to test idle modes, however horrendously tedious that would be.
 
-0.085v offset, Prime95 -- so far haven't noticed any instability in prime95 or cinebench. It's been in the 60's outside all day. I had the window open, shade down, house central air running into here (~72 degrees) no AC, computer was off for 7-9 hours while I slept. Room didn't even go below 76 degrees >_< It did reach almost 80 while I was testing before I went to sleep. Flipping on the air was a lifesaver. I'd like to open the window fully now but it's going to rain a lot soon and I haven't yet built cardboard pieces to fit over the desk/PC area in front of the window to block rain before I notice it and put the shade down ;)
2022-04-13_003653.png
2022-04-13_003626.png
Post magically merged:

Interesting. I just noticed that Hwinfo shows the offset. Never knew it did that. This is actually useful because sometimes if I change the multiplier it will change back to 0 offset without me noticing it until I see the VID or temperature/wattage readings are off.
Post magically merged:

I spoke too soon. Hwinfo isn't updating the offset when I change it, even though the VIDs and wattage are changing. However, I don't know if the wattage is calculated based on VID or actual readings.
 
Last edited:
I ran into an interesting complication regarding the e-cores. It appears that the faster the p-cores are compared to the e-cores, such as if the p-cores are at 47x and the e-cores are at 36x, the lower the prime95 utilization of the e-cores. Thus, from a prime95 perspective, to properly test the e-cores I must set affinity to them only and run a 4-core test on prime95, in order to achieve 99%+ utilization. Cinebench appears to be loading them fully regardless though.

If the p-cores are matched to the e-cores at 36x, the utilization is higher than when the p-cores are at 47x, but still not that close to 100%.
 
E-cores usually OC up to 4.0-4.1GHz and nothing more. There are exceptions but I wouldn't count on more. P-cores should run at something like 4.7GHz 1.15V. One of my 12600K can make 4.7GHz at 1.1V. I wasn't testing the other one. My 12900K seems to need higher voltages and is not overclocking really high. More like typical 5.2GHz on ambient temps while 2 cores can boost at auto up to 5.5GHz.
I like how these chips run at lower voltages and lower clocks. Something like 4.6-4.7GHz is more than enough for gaming or anything else and can make it use significantly less power, heat up less and run quiet (or with a small cooler).

I wanted to run long stability tests on 12600K but the motherboard has some weird problems and I had to make RMA. I wonder if they test it right. It's crashing after about 1-1.5h in everything at auto/stock settings. Like CPU, FPU, cache, RAM, or any other test. There are even some PCIe errors.
 
Last edited:
One thing that kind of annoys me is that depending on how many cores are being worked it will change the VID to the cores. For instance, if all 12 are being pushed, the VID will go higher, to something like for example 1.128 peak. On the other hand, if I'm only working 1 core, it may go as low as 1.103. This seems like a pretty big difference to me. But I don't know whether this is only a change in requested voltage or if it correlates well with an actual voltage reading.

When I looked in the MSI BIOS menu, I found that a LLC curve can be chosen, but the problem is, not a single one of them is flat. They all either slope up or down, however slightly. But then again, maybe that's not as much of a complication as I may think.
Post magically merged:

It may be possible, perhaps, that the increase in voltage being requested is to compensate for an inevitable voltage drop that would occur if more of the cores are being juiced up on that rail. But whether such an inevitability actually exists, I would not know. So maybe this is just to compensate for potential/actual voltage drops. But if so, maybe it's an unnecessary compensation, and even a compensation that could provide a FALSE sense of stability, when in fact instability may occur under load situations or even non-load situations when not as many cores are being worked and the voltage is, perhaps in actuality, lower, thus being more likely, potentially, to be unstable.
Post magically merged:

It may be possible, perhaps, that the increase in voltage being requested is to compensate for an inevitable voltage drop that would occur if more of the cores are being juiced up on that rail. But whether such an inevitability actually exists, I would not know. So maybe this is just to compensate for potential/actual voltage drops. But if so, maybe it's an unnecessary compensation, and even a compensation that could provide a FALSE sense of stability, when in fact instability may occur under load situations or even non-load situations when not as many cores are being worked and the voltage is, perhaps in actuality, lower, thus being more likely, potentially, to be unstable.
Haha, this brings everything back to that "overshoot/undershoot" thing that occurs during state changes where in the transition between load/idle states, it may be possible to dip into potential instability for just a brief moment. Of course, messing with that stuff is way beyond what I'm intending to do, and can probably be compensated for in an obtuse way, just by doing a voltage bump if any problems are run into.
 
Last edited:
Yes... vdroop. LLC prevents that sag. Set it (not the curve, a value) to where it doesn't budge when you load all cores/threads.

We've worked with vdroop for generations. It's a part of the Intel spec. However, when overclocking, that spec can cause instability. Nit sure about this endeavor... but I set it to where there's no/minimal change between idle and load voltage.
 
Finally got my first crash. The setting was 47x P-cores, 36x E-cores -0.135 V. The test that triggered it was Prime95 Small FFTs all cores. The main screen got the

This report has been interrupted by another crash at -0.130 V, same test/settings. I am now beginning to type this as I'm running the test at -0.125 V. If I cannot get this setting to crash with this test over the next 2-3+ hours, I will go back to -0.130 V and try other testing methods to see if they can fail.

This is the current test running:
2022-04-13_072105.png

The voltages are hovering very close to what they were @ -0.130 V which on the frozen off-screen was 1.159 p-core, 1.157 e-core. Interestingly it's showing slightly less power draw than the previous test. It may be possible the watt measurement is a real measurement, because I notice as the system heats up over time, it pulls a bit more from the wall, so I'm assuming that's a slight reduction in efficiency on the PSU or maybe even other components. Perhaps before things have a chance to heat up that number will be a couple watts lower.

Aside from trying different tests to see how reliably they generate fails compared to each other, I also want to try to isolate whether the crash occurred on the p-cores or e-cores, which will require further testing.

What I do know, however, is that going down to -0.135 V is a very reliable way to initiate total freezes quickly with prime 95 full blast 47 pcore 36 ecore.
 
Some interesting general findings.

1. Using Intel XTU's Core Voltage Offset setting is not fully precise, at least not within the context of the general configuration I'm doing, adaptive + offset.
Sometimes, a given setting will behave as if it was 1 notch higher or lower, or half a notch. If you continue to apply new core voltage offsets, and at some point, after applying, instead of it displaying the new offset setting and instead saying "Undefined" it is likely that this phenomenon will happen next time a new setting is applied. If this "Undefined" thing doesn't happen, then each notch should behave normally relative to each other notch of the setting.

As such, the most precise thing to do when recording data is to note 3 things:
1. The XTU Core Voltage Offset setting
2. Average core VIDs for full load
3. Average Vcore motherboard reading

This will more exactly determine what the "actual setting" is moreso than just the Core Voltage Offset, although that is still step #1 and should be accurate within one notch or "0.005v" wiggle room.

All that being said, if I describe a setting by the -0.1XX V offset, it's still a decent way to talk about it, it just might be + or - 0.005 V

2. So far, an all core full AVX (except 512) enabled Small FFT test in Prime95 is the most reliable way to crash this thing compared to Cinebench & Prime NonAVX.

I've thusfar compared this test to Cinebench R23 and Prime95 all core Small FFT with AVX fully disabled.

So far, Cinebench by far requires the heaviest undervolting, by several notches, compared to Prime95, to initiate crashes reliably in a short time. Thus, it leads me to believe it's an inferior full load test. However, because it does drop load regularly between each drawing, while Prime95 doesn't lower loads as often or by as much, it might be more useful for testing state changes, but I believe there's a testing software out there that does this more intentionally and thus would probably be more effective.

I also tried fully disabling AVX on prime95 to see what would happen. It would appear this causes Prime95 to require undervolting a lot lower than with AVX to initiate crashes, but it still crashes things more easily than Cinebench.

In order to reliably initiate crashes quickly with Prime95 + all teh trimmings, generally required an offset of -0.130 V to -0.140 V which will look something like this or 1 notch lower:
1649941279462.png


Without AVX on Prime95, going to -0.150 V resulted in a quick crash. -0.140 V or -0.145 V looks something like this (it should be noted VID/Vcore go significantly lower at the same setting without AVX) and this screenshot is about what it looks like when it takes 21 minutes to crash
1649941413028.png


I'd say I had to get to at least -0.165 V to -0.170 V to get a quick loss of stability with Cinebench R23. This is a screenshot of what I'm currently testing which is -0.160 V. It's been running over 15 minutes without a crash yet.
1649941692453.png
 
I should add that although Prime95 without AVX does crash more easily at any given voltage offset setting than Cinebench R23, it's doing so with Vcore and Core VIDs significantly lower than Cinebench. Nonetheless, its VID/Vcore is also much much lower than Prime95 with AVX enabled, and it still requires a much lower offset to crash. So Prime95 AVX causes the voltages to be much higher than Prime95 Non-AVX at any given setting, while still crashing much more easily. Cinebench R23 causes the voltages to be much higher than Prime95 with no AVX, but crashes less easily, and indeed I doubt it would even be possible to test Cinebench R23 at the same voltages as Prime95 without AVX without insta-crashing well before getting down to those voltages.

So it could be said that Cinebench can crash at higher actual voltages than Prime95 NO-AVX, while Prime95 AVX can crash at higher actual voltages than Prime95 NO-AVX.

I am curious about one thing related to AVX. It's quite possible that none of my typical usage will involve AVX or perhaps not involve using it much. If, and this is a very big if, the only thing that can crash a configuration (remember I haven't tested low multiplier, idle, etc states or common usage or state switching yet), would be either Prime95 and/or heavy AVX usage (I don't know how heavily Cinebench R23 uses AVX compared to Prime95), then perhaps it is worth using Prime95 with NO AVX stability as a guidepost for 24/7 configs rather than Prime95 WITH AVX.
Post magically merged:



Finally, an update on my progress so far. I had to dial back the Intel XTU Core Voltage Offset all the way back to -0.110 V -- Prime95 was still crashing again and again as I backed off from -0.135 V, but over time it took longer and longer, sometimes taking 2-3 hours. Finally, at -0.110 V it remained stable for 15+ hours before I stopped testing.

1649943092228.png

For those who actually know anything about this stuff, what commentary would you have on the Core VIDs vs the Vcore readout from the mobo? Which one more accurately portrays the "actual undervolt"?



Edit: 1 comment to add, mainly just for my own reference in this timeline. So far I've done a lot of stuff on this desktop at heavy undervolts, browser stuff, games, a bit of video recording other random stuff. Mostly while tests were running, but sometimes tests were not running, or I was only testing e-cores, or just 1-4 cores. I have not yet experienced a single crash during anything but an all-core load testing situation. That being said, I didn't do a lot of test time on stuff like 8 pcores full load without e-cores. Still, I'm seeing so far that lower multipliers/idle/etc has not yet initiated a crash as far as I know. This may not be very significant yet, as I didn't spend a lot of time running these configurations in normal usage, idle, etc. scenarios.
 
Last edited:
Core VID, VID in general, we've defined as "Voltage I Demand". In other words, for a given frequency, that's the voltage the processor REQUESTS for a given multiplier. Vcore is the ACTUAL voltage it's getting. There's a thread here from a while back discussing this too. :)

I don't recall what board you have (no signature, no mention I caught here), but if you have voltage read points... use them (software can be inaccurate).

This isn't the one I'm talking about but should help (Bobnova was involved with the original) - https://www.overclockers.com/forums...ween-core-voltage-and-vid.642427/post-8058278
 
I don't recall what board you have (no signature, no mention I caught here),
Yea.... I gotta fix that. I will later... it's about damn time. If it makes any difference it's a MSI MPG Z690 EDGE WIFI DDR4.

With regard to the voltages, I definitely noticed that the most useful relativistic number when it came to figuring out where to expect crashes or how fast to expect them, with a given test method, was the Vcore. See, the problem is, for a long time I didn't even notice that Vcore readout on Hwinfo which really pissed me off because all I saw was VID.

The 2nd question is, and I'm sure this will be unanswerable without either using testing hardware or schematics, should the Vcore be representing the "final product" of core voltage after all regulation mechanisms have been parsed through, or is there a decent likelihood that the Vcore reading may represent a voltage that, even if coming after many regulation mechanisms, still is before certain regulation mechanisms and may end up getting altered intentionally after that reading?
 
You didn't read that thread did ya? :p

VCore is the voltage the processor is at (which logically thinking is AFTER the regulation mechanisms). VID is what the processor REQUESTS, VCore is what it's actually getting.
 
You didn't read that thread did ya? :p

VCore is supposed to be the voltage the processor gets AFTER. VID is what the processor REQUESTS, VCore is what it's actually getting.
I did, but I was worried that there might be some known exceptions. :eek:
 
As I understand it, your offset depends on the VID for a given multiplier. So when you change it, the VID changes and so would Vcore.

For example...

45x VID = 1.000 + offset = Vcore
46x VID = 1.025 + offset = Vcore
47x VID = 1.050 + offset = Vcore

So it makes sense that you're seeing different voltages for different multipliers with the same offset.
 
As I understand it, your offset depends on the VID for a given multiplier. So when you change it, the VID changes and so would Vcore.

For example...

45x VID = 1.000 + offset = Vcore
46x VID = 1.025 + offset = Vcore
47x VID = 1.050 + offset = Vcore

So it makes sense that you're seeing different voltages for different multipliers with the same offset.

Core freq multipliers, unless I've done something horribly wrong, are constant in my testing. What differs is both the Vcore and VID readings when using a given core voltage offset, by as much as the result of +1 or -1 notch in the core voltage offset setting, all in XTU of course. So sometimes the resulting voltage readings/VID coming from say for example -0.135 V offset, would look more like a -0.140 V or -0.130 V setting, or somewhere halfway to either one.

As far as I can tell all the testing involves 47x P-cores and 36x E-cores.

So for the time being I'm just chalking it up to a slight lack of precision when it comes to using those settings, or, there is some mediating regulation going on that is regulating differently at different times based on different conditions, slightly altering things, even if the setting itself is technically precise. All in all, just a slight inconvenience.
Post magically merged:

While typing out my response Cinebench R23 finally crashed after 1 hour and 43 minutes. This was at XTU's -0.160 V core voltage offset on standard adaptive voltage.

This is about what Hwinfo looked like at that setting:
1649947403658.png

Only difference is average Vcore was 1.112 V for the crashed setting (I saw it on the other monitor under average after the crash). VIDs were almost identical.

Testing Cinebench R23 with the voltage offset bumped off 1 notch, -0.155 V which looks like this:
1649947556364.png
 
Last edited:
Core freq multipliers, unless I've done something horribly wrong, are constant in my testing.
Right. I said VID/Vcore changes when you change the CPU multiplier (as you too said in the sentence after the one I quoted above). See my previous post for a visual example of what I mean.


... that said, I think you're spot on saying the resolution of your testing is a part of that difference as well. 0.005 volts is absolutely tiny, especially with how software monitoring works. If you're not using a MM, then readings can vary over the resolution you're trying to fine-tune.
 
Well, it's been almost 4 and a half hours on Cinebench without any issue yet. So -0.155 V or shall we say 1.117 Vcore may be Cinebench R23 stable, knowing full well it wouldn't even come close to being Prime95 without AVX stable, and even further from being Prime95 AVX stable. But, I just wanted to compare these two methods.

2022_04-14_0210 Cinebench R23 Stable 4.5 Hours -0.155 V.png

Does anyone know any potentially good CPU testing software I might be missing out on? Once I've come closer to possibly finding a good 24/7 config to try out, I might try some other tests to see if they can cause problems, especially if they test the state changes and multiplier changes, stuff besides just full load burn, although the full burn is still good too just to see how different softwares stack up against Big Daddy Prime 95.

I shall now test 36x at -0.110 V on Prime95 Small FFTs all core HT AVX/AVX2 enabled. At the 15+ hour stable 47x on this offset, VID was averaging 1.177 V and Vcore was averaging 1.154 V. At 36x VID is 1.096 V and Vcore is 1.080 V

1649964573913.png

The results of 36x testing within the context of the 47x tests will likely shape how things proceed from here. It cannot definitively tell me what the stability of all the frequencies between 36/47 are, nor the ones below, nor idle, nor state changes, frequency changes, voltage changes between those, etc. But, it might at least suggest certain things depending on how it goes.
 
Back