How to find your "hidden" AC / DC Loadline values

[FlyingScot]

The IA Domain Loadline settings (AC_LL and DC_LL for short) are two of the most important settings when it comes to CPU voltage management. Regardless of how you influence these two settings when you set up your BIOS configuration, it's always a good idea to check these values when in Windows. To do this, use one of the following procedures:

Use the HWiNFO64 application:

Step 1: Make sure that the Summary screens open with the application. One way to do this is to uncheck the two boxes shown in the screenshot below:

Step 2: When the Summary screen opens, click on Central Processer(s) to expand the list of options. Click on the processor (see highlights below) and scroll down the list of information until you get to the IA Domain Loadline (AC/DC). Note the information shown for this line item. The GT Domain Loadline is for the iGPU (for CPU's with an iGPU) and is not relevant when tuning a CPU’s voltage curve.

Use the OCCT application:

Step 1: Open the OCCT application and then click on the SYSTEM INFO tile on the left of the screen.

Step 2: Make sure your CPU is highlighted...and then click on the SHOW DETAILS button towards the bottom of the screen.

Step 3: Scroll down the list of details until you see the IA Domain Loadline (AC/DC) information.

 

[wroger196157202e2]

FlyingScot....Is this right for my IA Domain Loadline(for 13500), it looks way higher than I would have thought.
UPDATE: Yeah, it's high CPU Lite Load was on Auto and showing 18 which should be 1.40 but with MSI's crazy ratios it was actually doing 21 which is 1.7. Took CPU Lite Load down to 12(which should be 15) and brought it down to 1.1. Man what a difference that one setting makes(and yes I started by reading Citay's pinned guide). Good post by SGT Morogan over on overclocker's forum: https://www.overclock.net/threads/msi-lite-load-and-mapping-to-cpu-ac-dc-load-lines.1805086/ about MSI's crazy Lite Load ratios.

 

[wroger196157202e2]

still experimenting with CPU lite load currently down to 8 which drops it to 0.70 mohm. this is going to take some time and testing to find the right one i believe.

 

[FlyingScot]

The neatest explanation I have come across regarding Intel’s Loadline mechanism (which includes the three BIOS settings AC_LL, DC_LL and Loadline Calibration Control (“LLC“ for short)) is courtesy of BuildZoid’s latest set of videos (as of August 2024) on Raptor Lake tuning, and one video that focuses on the role of the LLC setting.

Redirecting readers to this thread:

https://forum-en.msi.com/index.php?threads/guide-almost-everything-you-need-to-know-about-raptor-lake-voltage-power-temperature-tuning.404785/post-2292101

 

[wroger196157202e2]

The neatest little explanation I have come across of AC_LL, DC_LL and LLC (i.e. the least number of words) is courtesy of Mr. BZ's latest LLC video.

LLC is a multiplier that alters the amount the motherboard VRM compensates for Vdroop between the VRM and the CPU Die.
LLC Mode 1 = 100% compensation. LLC Mode 8 = Little to no compensation.
Lower compensation = lower voltage sent to CPU.
Note: The CPU does not know what the LLC setting is set to.

AC_LL tells the CPU how much Vdroop to expect and therefore how much to adjust the VID voltage request by.
Lower AC_LL = Lower VID.
Note: If the AC_LL does not match the impedance rating for the current LLC setting, the CPU may get a little surprise when it receives less (or more) than it was expecting. If the variance gets too far out of whack, the CPU might get a little upset. [Perhaps even triggering CEP???] However, many users do not have the impedance matched perfectly and yet have no issues at all. Again, as long as they are close enough.

DC_LL tells the CPU how to "guesstimate" the actual power usage so it doesn't need to keep polling the VRM for this information. The super-fast switching frequency of Intel's VID requests might make this even impossible or very expensive to achieve, so the DC_LL is a constant that is used to adjust/calibrate the math. EDIT: You also match the DC_LL to the LLC, but mainly just as a byproduct of trial and error.
DC_LL is used to adjust (i.e. lower) the VID to match the actual voltage received (as per VR OUT and/or Vcore). It has no effect on real voltages.
Note: If the DC_LL value is significantly off then it's likely that your Power (TDP) readout in HWInfo, as well as the VID value, will read on the high side. You will also prematurely hit your PL1/PL2 limiters. It's best to keep VID and VCore/VR OUT within a +/-5% tolerance to avoid any major discrepancies.

EDIT: AC_LL and LLC need to be close enough for no nasty surprises as far as the CPU is concerned, but the DC_LL also needs to be matched to the LLC for reporting and power usage calculations. In regards to their relative importance when being matching to the LLC, the AC_LL is much more important than the DC_LL, but the system may still be rock solid even if neither are matched. It's really only CEP that throws a tantrum if AC and DC are not balanced to each other (I believe). I think we're trying to nail that one down as to the exact point it gets upset. I hope that makes sense. I don't want to confuse people.

It's possible that your LLC impedance is too far out of alignment with you AC_LL at 30. You should try raising both values until CEP behaves. [This is just a theory, but no harm in trying] If that doesn't work, it's possible that one of the settings you have changed back and forth got an Auto value stuck somewhere - due to a BIOS bug. The only way to really know would be to first try reloading a profile and if that doesn't work then resetting to Optimized defaults. Then just make the changes you want to keep and no more. I have seen so many issues like this that it's hard to to believe that this is not what is happening to some people, and why they remain the odd man out.

Bonus Info.
I believe most desktop motherboard VRMs are tuned for 110 mOhm impedance as the default.
The latest Intel Defaults assume this when they set the AC_LL = 110, DC_LL = 110 and the LLC = 110 (MSI Mode 8).
I'm not 1000% sure of the above statement, so someone chime in if I have too grossly simplified it.

FlyingScot.....Thanks for the simpler explanations. Since MSI finally released the Beta BIOS with 0x129 for my Z690-A Pro DDR5 yesterday, I flashed my system last night to it. Obviously, it resets BIOS to default settings. Everything at Auto is where it should be except CPU Lite Load was 1.70 mohms again. Took it down to 1.10 mohms (like BuildZoid said in the vid). Looking at actual Intel specs for 13th and 14th CPUs, 1.10 is the default for my CPU. Have no idea why MSI set it to 1.7 as that is default for a 35W CPU. I've included the link to the technical manual for the 13th and 14th CPUs if you and CItay(or others) want to take a gander at it.

Sign in to your account

edc.intel.com

 

[FlyingScot]

FlyingScot.....Thanks for the simpler explanations. Since MSI finally released the Beta BIOS with 0x129 for my Z690-A Pro DDR5 yesterday, I flashed my system last night to it. Obviously, it resets BIOS to default settings. Everything at Auto is where it should be except CPU Lite Load was 1.70 mohms again. Took it down to 1.10 mohms (like BuildZoid said in the vid). Looking at actual Intel specs for 13th and 14th CPUs, 1.10 is the default for my CPU. Have no idea why MSI set it to 1.7 as that is default for a 35W CPU. I've included the link to the technical manual for the 13th and 14th CPUs if you and CItay(or others) want to take a gander at it.

Sign in to your account

edc.intel.com

That is very strange. It's almost like it detected your CPU as a laptop version. I guess it must be a BIOS bug. It's like a repeat of what Gigabyte did with their very first BIOS release around the time of 0x125 being pushed out. And they quickly pulled it.

It's a good thing you caught it. It's incredible when you think about the sloppiness going on. We hear of CPUs dying because of too much voltage. So what do the motherboard vendors (and Intel) do? They push out updates to drive your voltages even higher! It's a mad mad world we live in, ain't it?

 

[wroger196157202e2]

That is very strange. It's almost like it detected your CPU as a laptop version. I guess it must be a BIOS bug. It's like a repeat of what Gigabyte did with their very first BIOS release around the time of 0x125 being pushed out. And they quickly pulled it.

It's a good thing you caught it. It's incredible when you think about the sloppiness going on. We hear of CPUs dying because of too much voltage. So what do the motherboard vendors (and Intel) do? They push out updates to drive your voltages even higher! It's a mad mad world we live in, ain't it?

Agree it's a mad, mad world for sure. Even though I know my CPU is a rebranded Alder Lake, I started watching it and the motherboard as soon as this issue came to light months ago. And of course following you, Citay, and all the others up here as well as checking/watching the valid youtubers and trying to dodge the clickbait up there. Even though I may never have an issue, at least I know I have taken every precaution necessary, especially since Intel has said the issue affects 65W and up but will not say exactly which ones and only pointed toward half the SKUs.

 

[FlyingScot]

Agree it's a mad, mad world for sure. Even though I know my CPU is a rebranded Alder Lake, I started watching it and the motherboard as soon as this issue came to light months ago. And of course following you, Citay, and all the others up here as well as checking/watching the valid youtubers and trying to dodge the clickbait up there. Even though I may never have an issue, at least I know I have taken every precaution necessary, especially since Intel has said the issue affects 65W and up but will not say exactly which ones and only pointed toward half the SKUs.

Your point is well taken. I think if I were in your shoes I would not take anything for granted, even if you do only have an Alder Lake die. I myself have a 12700KF that I plan to load into a Z790 as soon as I can stomach there pricing. I'm holding out for a Carbon model, but I really don't like the idea of spending more than $200 on one. But even though I just have an Alder Lake to tune, I'm like you; I want to know everything that's going on with this platform. Some of what we have already learnt has direct applicability to the Alder Lake chips. And you also get to prepare for an upgrade to Raptor Lake when the prices of these chips inevitably falls to affordable levels.

 

[valentinosgsx159202dc]

FlyingScot.....Thanks for the simpler explanations. Since MSI finally released the Beta BIOS with 0x129 for my Z690-A Pro DDR5 yesterday, I flashed my system last night to it. Obviously, it resets BIOS to default settings. Everything at Auto is where it should be except CPU Lite Load was 1.70 mohms again. Took it down to 1.10 mohms (like BuildZoid said in the vid). Looking at actual Intel specs for 13th and 14th CPUs, 1.10 is the default for my CPU. Have no idea why MSI set it to 1.7 as that is default for a 35W CPU. I've included the link to the technical manual for the 13th and 14th CPUs if you and CItay(or others) want to take a gander at it.

Sign in to your account

edc.intel.com

Hi mate. It sure changed to 1700/1700, same here for my 13600K and Z790 PRO. I suppose that is the correct value for low power CPUs with the new limits implemented because it was working fine like this and got undervolted as before. Eventually I ended up changing LLC mode and AC/DC along it... but still, it was working as is but with higher voltages as expected.

 

[FlyingScot]

Hi mate. It sure changed to 1700/1700, same here for my 13600K and Z790 PRO. I suppose that is the correct value for low power CPUs with the new limits implemented because it was working fine like this and got undervolted as before. Eventually I ended up changing LLC mode and AC/DC along it... but still, it was working as is but with higher voltages as expected.

Man, who knew? You learn something new every day!
Thanks for sharing!

 

[wroger196157202e2]

BZ just released a new video of him checking an MSI Z690-A DDR4 and it looks like MSI Vcore has weird behavior compared to Gigabyte

 

[FlyingScot]

BZ just released a new video of him checking an MSI Z690-A DDR4 and it looks like MSI Vcore has weird behavior compared to Gigabyte

We actually started discussing that video over here earlier today; you might want to check out those conclusions.

https://forum-en.msi.com/index.php?threads/different-undervolting-methods-with-ia-cep-enabled-and-how-they-compare-to-lite-load.400984/post-2277634

Cheers!

 

[sergey14f902d0]

Note: If the DC_LL value is significantly off then it's likely that your Power (TDP) readout in HWInfo, as well as the VID value, will read on the high side. You will also prematurely hit your PL1/PL2 limiters.

DC_LL tells the CPU how to "guesstimate" the actual power usage so it doesn't need to keep polling the VRM for this information.

Hello. Thank you very much, FlyingScot, for good explanation in the first post of this thread! I want to pass to everybody my idea...
I tried to cheat CPU limits and CEP... and looks like I managed it.
PL1 = PL 2 = 253 W
ICC Max = 307A
LLC - Medium (proper AC/DC LL should be 55)
AC LL - 45
DC LL - 100
Adaptive offset -0.120V
Result:
1. VID is much lower than VR out and Vcore. I am really getting more than 253 W and 307A out of my CPU (because DC LL is not set according to LLC setting) but CPU limits "thinking" that they provide right limits according to Intel specs. VR out max is 1.3 V - according to monitoring during benchmarking. Everybody happy.
2. CEP also happy because VID request never exceeds VR out. CEP can do what it should do - prevent undershoots of the V. Performance of CPU does not suffer because CEP is not stretching clocks.

What do you think, guys, about such way of settings?

 

[FlyingScot]

Hello. Thank you very much, FlyingScot, for good explanation in the first post of this thread! I want to pass to everybody my idea...
I tried to cheat CPU limits and CEP... and looks like I managed it.
PL1 = PL 2 = 253 W
ICC Max = 307A
LLC - Medium (proper AC/DC LL should be 55)
AC LL - 45
DC LL - 100
Adaptive offset -0.120V
Result:
1. VID is much lower than VR out and Vcore. I am really getting more than 253 W and 307A out of my CPU (because DC LL is not set according to LLC setting) but CPU limits "thinking" that they provide right limits according to Intel specs. VR out max is 1.3 V - according to monitoring during benchmarking. Everybody happy.
2. CEP also happy because VID request never exceeds VR out. CEP can do what it should do - prevent undershoots of the V. Performance of CPU does not suffer because CEP is not stretching clocks.

What do you think, guys, about such way of settings?

It’s been a while since I thought about this stuff, so let me walk through this setup for a moment.
Assuming your assumption that LLC “medium” = 55 impedance is correct (or close enough) then:

VID is lowered by a negative offset via the higher DC_LL than AC_LL.
VID is lowered by a negative offset via the manual UV.
Vcore/VR VOUT is lowered by the sneaky undervolt as a result of a lower AC_LL than the estimated LLC equivalent impedance.
Vcore/VR VOUT is lowered by the manual UV.

Net result is that VID is reported to HWInfo as artificially low.
Net result is that TDP calculations will be lower than actual, which allows the CPU to slightly exceed the PL1/PL2 limits. Not sure if IccMax is also cheated.
CEP compares VID to Vcore. I believe we all now agree (on this forum) that DC_LL has no effect on CEP. However, AC_LL is within 67% of LLC impedance, so CEP is happy.

From my perspective, there’s nothing unusual or concerning about your setup. Although, I personally would prefer to try and get my VID in line with my Vcore for accuracy of reporting. But the effect on PL2 is relatively small and therefore not much of a concern.

BTW, I did see a need to slightly rework my original post when it comes to my description of DC_LL. I don’t think what I changed has a bearing on your setup and understanding, but others might have been slightly misled depending upon their DC_LL starting position. So I clarified that point.

 

[sergey14f902d0]

VID is lowered by a negative offset via the higher DC_LL than AC_LL.

... via the higher DC LL then should be according to LLC, I believe.
CPU predict VID by AC LL, but reports it by DC LL and never know real LLC. Funny.
AC LL helps to predict V droop and manages REAL VID request but LLC only decide which V droop we will have in VRM in did.
DC LL only tells CPU how to report VID, REAL VID request doesn`t change at all. Does CPU report this data to operating system only? How it is connected to real limits for CPU then?

Net result is that TDP calculations will be lower than actual, which allows the CPU to slightly exceed the PL1/PL2 limits. Not sure if IccMax is also cheated.

V constant, power limits exceeded. It is impossible without A raise. Right?

 

[sergey14f902d0]

CEP compares VID to Vcore. I believe we all now agree (on this forum) that DC_LL has no effect on CEP.

CEP compares VID and Vcore, right.
Where from CEP takes VID reports?
Actual power usage calculated using VID or Vcore? VID reported to CEP and for power calculation coming from different sources?

 

[FlyingScot]

.. via the higher DC LL then should be according to LLC, I believe.

Yes, it should be DC_LL vs LLC instead of AC_LL. My mistake.

CPU predict VID by AC LL, but reports it by DC LL and never know real LLC. Funny.
AC LL helps to predict V droop and manages REAL VID request but LLC only decide which V droop we will have in VRM in did.

If I understand you correctly then your statements are correct.

DC LL only tells CPU how to report VID, REAL VID request doesn`t change at all. Does CPU report this data to operating system only? How it is connected to real limits for CPU then?

That one confuses me so I plan to do some testing. I currently work off the assumption that VID + AC_LL gets sent to VRM then VID + DC_LL gets reported to OS and CPU's internal PL1/PL2 limit logic.

V constant, power limits exceeded. It is impossible without A raise. Right?

Not sure what you mean... CPU logic checks VID x current (amps) against PL1/PL2 instead of Vcore x current.

CEP compares VID and Vcore, right.

Yes, but maybe not Vcore. Maybe internal voltage, which is more accurate, e.g. 30mV lower. But the trend line will be the same, so for the purpose of tracking behavior, at some point Vcore (real voltage + 30mV) will be too low and CEP wil step in.

Where from CEP takes VID reports?

It would be the same VID + AC_LL that gets sent to the VRM. If the VRM sends back much lower voltage, CEP will likely be triggered.

Actual power usage calculated using VID or Vcore?

To keep it simple, just stick with VID + DC_LL gets reported to OS and CPU's internal PL1/PL2 limit logic...and I believe is used to calculate CPU Package Power that will show in HWInfo. Real power usage (likely hidden) may be higher or lower depending on how far apart (and in what direction) VID is from Vcore.

 

[sergey14f902d0]

Not sure if IccMax is also cheated.

not really cheated according to my today tests.

AC_LL is within 67% of LLC impedance, so CEP is happy.

but not fully happy. I am losing about 500 points in CB23 with CEP Enabled. still not sure should I disable it or not. What is your opinion?

 

[FlyingScot]

not really cheated according to my today tests.

but not fully happy. I am losing about 500 points in CB23 with CEP Enabled. still not sure should I disable it or not. What is your opinion?

What LCC value are you using?
What CPU?
Depending on CPU, 500 points can be a variance from run to run due to background processes.
Watch the average effective frequencies from run to run. Make sure it's reproducible. CEP on/off.

 

[sergey14f902d0]

DC LL only tells CPU how to report VID, REAL VID request doesn`t change at all.

That one confuses me so I plan to do some testing. I currently work off the assumption that VID + AC_LL gets sent to VRM then VID + DC_LL gets reported to OS and CPU's internal PL1/PL2 limit logic.

About what is your confusion? From your original post:

It [DC LL] has no effect on real voltages. But it can have an impact on power consumption limits.