Power Of Limits
Totaly Pavlina
I see in HWinfo this but on Google I can't find an explanation of what these are, can someone help me to understand? The Intel explanation isn't very clear.
CPU PL1 should be equal to TDP, but it's not, my TDP is 45 W and PL1 is 56 W, so I don't understand this. Apart from that, from what I understood, if I go over 56 W for 28 sec, algorithm will limit the power, but I can't understand the Unlimited and Unlocked. Unlimited means that the CPU will run in its turbo modes all the time? Can someone explain me every part of these 4 lines?
This is all part of a feature provided by Intel (and more recently AMD) on their x86 CPUs which allows the firmware (or OS) to control power consumption limits for the processor, thus allowing better control of system power consumption.
The 'long duration' power limit places an upper limit on the power consumption of the CPU over extended periods of time. Your understanding is correct that the 28 second time window is how long the CPU can run over that limit. Most CPUs can in fact have this safely set above their TDP, but the cooling system needs to be able to handle a TDP equal to this limit to avoid causing damage to the CPU.
The 'short duration' power limit puts an upper limit on how much power the CPU can use when the long duration limit is not being enforced. I'm not entirely sure myself what 'unlimited' means here. It could be a marker that this is applied at all times (IOW, you can't go over this limit), or that this limit is just unused (not likely).
In both cases, 'unlocked' means that the values can still be changed by the system (or firmware). Most CPU configuration items like this can be 'locked' once set by writing a 1 to a specific bit in another register to prevent those values from being changed until the CPU is reset. This functionality is used a lot on embedded systems with very strict power or thermal envelopes to ensure that user software cannot cause problems for the user.
The third listed limit is, I believe, upper bounds for what you can set for the time windows and power limits. The fourth should be the physical upper limit on power consumption actually enforced by the CPU.
I have an Intel Core i9-7900X processor and a ASUS PRIME X299-A motherboard. I have configured the motherboard to use the default power limits for the processor (140 W TDP), intending to use XTU to override them at the OS level. With the pre-release XTU version 6.3.0.35 available on the ASUS website, setting the Turbo Boost Power Max works as expected. However, with the latest version, 6.3.0.54, from the Download Center, setting the power no longer works. Although I can change the Turbo Boost Power Max to "unlimited," when I run a stress test like Prime95, the reported package power is limited to 140 W, and I observe a frequency reduction.
After I apply these settings, the XTU UI shows the new values. However, when I run a stress test like Prime95 v28.10 ("Small FFT") or Intel Math Kernel Library Benchmark ("linpack/runme_xeon64.bat"), the package TDP in the XTU monitor never exceeds 140 W, and the frequency is reduced. When I use the earlier XTU 6.3.0.35 from ASUS, the power consumption in LINPACK is observed to reach 170+ W, and the frequency remains at the maximum turbo frequency.
I would like to request the following test; set your BIOS to default and try not to modify additional BIOS settings, then load the XTU from -Extreme-Tuning-Utility-Intel-XTU-?product=66427 Download Intel Extreme Tuning Utility (Intel XTU) one more time and test again. If you still observe the issue, please confirm which XTU value you modified and we will continue reviewing this matter.
I used the XTU 6.3.0.56 that you linked and did not see any difference. However, regarding BIOS settings, I did find something of importance in reproducing this issue. In the default (factory reset) state, my ASUS X299-A (BIOS 0402) boots with the power limits disabled (set to 4 kW). In this state, I was able to use XTU to set the power limit to 140 W and also to clear it again. However, if the system boots with a power limit initially configured, then XTU versions other than 6.3.0.35 are not able to change the power limit. I have tried two different ways to get power limits set on boot; on my motherboard, I can either change the "CPU frequency" to "AUTO" or explicitly set PL1 in "CPU Internal Power Management." In both cases, XTU is unable to change the power limit after booting. The parameter I am adjusting in XTU is called "Turbo Boost Power Max."
On one hand, I have found a workaround for the issue, as I can boot without power limits and then impose them later at the OS layer. On the other hand, I feel there is still a software defect worth investigating, since I had no issue with the earlier XTU 6.3.0.35.
I have filed this matter with our internal team, we have reviewed this matter at this stage the recommendation we can provide for you is to stay with the XTU provided by ASUS since this is the customized version for your specific motherboard. Our Intel Extreme Tuning Utility is a generic version that we are constantly working on improve it, if there are more versions available in the future you should be able to find it here: Drivers & Software
Intel does not verify all solutions, including but not limited to any file transfers that may appear in this community. Accordingly, Intel disclaims all express and implied warranties, including without limitation, the implied warranties of merchantability, fitness for a particular purpose, and non-infringement, as well as any warranty arising from course of performance, course of dealing, or usage in trade.
Can someone help me make sense of the limits on do until? I understand the Timeout is basically how long the Flow action will run until it stops, but Count is what gets me. Does it run "100" times immediately? Are they spaced out? Do I need to incorporate some delays?
For reference, my Flow below has a Do Until a SharePoint List column meets the criteria. The column is tied to previous Flow steps for multiple Approvals. Ideally I'd like the Do Until to check the column every couple of hours.
Would you be able to confirm if the below flow is set correctly to trigger further actions when the file is no longer checked out to anyone? Currently my flow continues to run even though is not checked out anymore.
Now approver can take say 3 days to approver. What should be the limits of Do until ? If I set to 100 and P1M [I guess 1M is 1 month].. will flow execute 100 occurrences in a month? What I have seen is that flow executes these occurrences within few minutes itself.
cheers! 1. the event organizer can decide on WKG enforcement or not for a specific event? 2. but still where is the definition from zwiftpower for WKG. How is it calculated? why is this information not easy to find!
Since the change from ZwiftPower to CE there have been some issues where WKG disqualifications have been issued. Mostly this has been where Clubs have been permitted to run non CE governed races and then apply disqualifications to anyone exceeding the race entry limits, usually by more than 0.2wkg.
As Gordon has suggested if a race is being run under CE regulations then the rule should be - If you are able to enter the category you will NOT be disqualified for exceeding the category limits [but hopefully you will be upgraded as a result of your new power, as you have been].
thanks for the reply! both Ian and Gordon. Sounds correct, and something they are sorting out, the entire top 10 for a climbing event got WKG based on 20 min power (though all were well under limits for the entire event) :). The lack of clarity is a problem for riders, with event organizers applying different rules makes it even more so. Hopefully the new system fixes this and zwiftpower publish an easy to find definition for each showing clearly upper and lower limits. The present system is like getting a speeding ticket when you cant see what the speed limit is
Thanks to FW open sourcing their EC firmware (here: GitHub - FrameworkComputer/EmbeddedController: Embedded Controller firmware for the Framework Laptop ), I managed to find a few lines of code that caught my interest (in file: EmbeddedController-hx20-hx30\board\hx30\cpu_power.c
Why do I want all this?
To get better performance. It seems that every Pcore at 4.7 GHz can consume about 22-24W of power, at all-core boost its around 18-20W and every Ecore can consume about 4-6W of power. That equals to roughly 120 watts, so the CPU is throttled down to 25% of its potential in terms of power.
In terms of performance, it seems to be capable of boosting Pcores to 3.8 GHz under all core load and Ecores likely to 3.4 GHz - this scenario should take some 80-90W.
When presented with 55W limit (what the heatsink can cool as of now, Pcores boost to 3.4-3.5 GHz and Ecores to 3 GHz
Under 30W limit, Pcores maintain about 2.5 GHz and Ecores 2.6 GHz.
There are plentiful custom projects that have potential for improved cooling. Imagine someone uses liquid metal. Imagine that someone who is using their old FW board as a desktop with eGPU can easily DIY some extra heatsink to provide extra watts of cooling, experiment with water cooling and with power limiters removed, get 40-50% performance boost?
You can also see, that the code changes power limits based on how much power the system has available from power supply and battery. Such that the system will not brown out, when trying to use more power than an PD power supply can deliver. Or that the battery can deliver when running exclusively on battery.
The answer to that would be, because they are of the opinion it is needed either for simple stability or for the longterm stability. How close to practical limits those numbers are or if those numbers are also influenced by requirements from Intel we do not now. But reducing those numbers down to stay within the power that is actually available to the hardware seems very reasonable and necessary.
But you can also see, that the code defines a console command that can override ALL power levels, including PL1.
So a first step could be to get access to the console (over the EC uart for example, no need to flash the firmware) where you can observe how those values change and even manually override them and turn off any automatic changes by the logic you quoted. This way, if you wanted to play around with the power limits you can do this in sort of a trial run. If that shows fruitful and you decide that you want to risk leaving manufacturer ranges, you can still try to build firmware to permanently change this.