Time Window for Power Limit

[cyring]

@BugReporterZ : based on https://github.com/cyring/CoreFreq/issues/323#issuecomment-1059777212; a new feature would be to alter the Time Window.

• Specs present the register MSR_PKG_POWER_LIMIT (0x610)

• The scope of this register is the following CPUID architectures:

• As the provider of the Power Limit information aka PL1 PL2; MSR_PKG_POWER_LIMIT is fortunately already implemented in CoreFreq

• Maths are solved as bellow:

I do not read limit values within the specifications.

• What XTU shows is Turbo Boost Power Time Window : I have so far no clue about this register.

See you
CyrIng

[TechieUser2517]

@cyring: the Turbo Boost Power Time Window in XTU appears to be what is otherwise known as Tau time and matches what I can set in bios for my motherboard.

Throttlestop, a closed source application for Windows capable of monitoring low-level CPU information similarly to CoreFreq, as well as writing/reading onto CPU registers to set power limits, reading CPU limit reasons, and so on, allows to set it to very low fractional values and very large values, from 0.0010 to 3670016 seconds; here are some I wrote down:

0.0010 0.0012 0.0015 0.0017 0.0020 0.0024 0.0029 0.0034 0.0039 0.0049 0.0059 0.0068 0.0078 0.0098 0.0117 0.0137 0.0156 0.0195 0.0234 0.0273 0.0313 0.0391 0.0469 0.0547 0.0625 0.0781 0.0938 0.1094 0.1250 0.1563 0.1875 0.2188 0.2500 0.3125 0.3750 0.4375 0.5000 0.6250 0.7500 0.8750 1.00 1.25 1.50 1.75 2.00 2.50 3.00 3.50 4 5 6 7 8 10 12 14 16 20 24 28 32 40 48 56 64 80 96 112 128 160 192 224 256 320 384 448 512 640 768 896 1024 1280 1536 1792 2048 2560 [...] 3670016

A screenshot of the application:

[cyring]

Hi!

• Unit is indeed adapting dynamically. But are you reading wrong values ?

• Getting a 404 from your link!

[ghost]

Sorry about link, not use to Github style, should work now.

Maybe I misunderstood, I was talking about time values which after reading the time unit can be set in a look up table as there are only 128 values. Maybe a picture is better?

[cyring]

Thanks for the GUI hint.

ASCII design was less easy to program, considering various constraints.

Feel free to draw an ASCII (only) suggestion of your willing UI

[ghost]

The GUI has nothing to do with it, it was just demonstrating the "ASCII" text, ie "40.00 secs". I'm sorry if I have upset you, it was my intention to be helpful.

[cyring]

With @BugReporterZ : it took us days to work on this use-case.

I'm opened to program improvements in CoreFreq but Users needs must be very explicit and exhaustive.

As an open source software, CoreFreq is willing PR from other programmers, whatever is the expertise (UI and/or low level). PR should off-course happen on the develop branch.

Regards

[cyring]

@BugReporterZ : Thank you. Those are awesome screenshots which give me a better idea of the range and the unit of values.

Still draft, I'm starting to redesign the front-end before going deep into registers:

[TechieUser2517]

@cyring : by the way—as far as I am aware of, the Time Window for PL2 is supposed to be normally very short (up to 10 milliseconds), but since it is not required for the Turbo Boost implementation, it's almost never configurable or even used in most desktop Intel motherboards.

[cyring]

@BugReporterZ : This Tiger Lake is more appropriate to the Time Window enhancement.

[TechieUser2517]

Power limits and time windows can have their uses on desktop systems, although few people take advantage of them. On my 12700K I set PL1 to 165W, PL2 to 250W and Tau to 5 seconds. The idea is that for short bursts (up to seconds) I want almost unlimited power, but also acceptable efficiency and temperatures for sustained all-core loads.

The 5 seconds time was chosen by observing how time it takes for temperatures to reach TjMax after applying an intense AVX load.

[cyring]

Dump from the i7-1165G

rdmsr -aX 0x610
42820000DD8118
42820000DD8118
42820000DD8118
42820000DD8118
42820000DD8118
42820000DD8118
42820000DD8118
42820000DD8118

TW1 is bit range [23:17] of 0x42820000DD8118
TW1 = 0x6e (110)

Y = 0x0e (14)
Z = 0x03 (3)

TU = 0.000976562 is the Time Unit shown in the 'Power, Current & Thermal'

TW = 2^Y * (1 + Z/4) * TU
TW = 16384 * (1 + 3/4)  * 0.000976562
TW = 28

Time Window of PL1 is 28 seconds

[TechieUser2517]

I get:

rdmsr -X 0x610
42878800598528

rdmsr --decimal --bitfield 21:17 0x610
12

rdmsr --decimal --bitfield 23:22 0x610
1

TU = 0.000976562 
Y = 12
Z = 1

TW = 2^Y * (1 + Z/4) * TU
TW = 4096 * (1 + 1 / 4) *  0.000976562 
TW = 5.0

This is what I set up for my CPU.

[cyring]

@BugReporterZ

• Computing the Time Window bounds with (Y, Z)

For the lowest with (0, 0)

TW = 2^0 * (1 + 0/4) * 0.000976562
TW = 0.000976562 sec.

For the highest with (31, 3)

TW = 2^31 * (1 + 3/4) * 0.000976562
TW = 3,670,014 sec. Huge!

• The BIOS' Time Window of 112 seconds is achieved with (16, 3)

TW = 112 sec = 2^16 * (1 + 3/4) * 0.000976562

• The BIOS' Time Window of 128 seconds is achieved with (17, 0)

TW = 128 sec = 2^17 * (1 + 0/4) * 0.000976562

• So, either (1) I'm presenting in UI two sliders, respectively Y and Z ; either (2) I'm offering an unique slider, like the BIOS, and I'm solving Y and Z in the backend.

[cyring]

Considering Y range 1 ... 31 , Z range 1 ... 3 plus a shareable 0 value, that would give a combination of 94 TW to process in the backend and to display on screen.

[cyring]

ASCII art

UI constraints:

• terminal 80x25: space matters, especially console, ssh, etc
• a window has one left and one right border
• only vertical scrolling is programmed
• cells should be spaced by one space
• looks better with one space border margin

All these constraints leave a practicable width area of 76 characters

Solution with one slider

The full set of TW values is rendered in the window

1. Horizontally in two columns

 ----------------------------------
| <0.000976562> ... <      128.0>
| <      256.0> ... <  3670014.0>
 ----------------------------------

2. Vertically in one column

 ----------------------------------
|         <0.000976562>
|         <       ... >
|         <      128.0>
|         <      256.0>
|         <       ... >
|         <  3670014.0>
 ----------------------------------

Solution with two sliders

Using two parameters and dynamically computing the TW value

 ----------------------------------
|           Y          Z
|
|          <0>        <0>
|          <1>        <1>
|          <2>        <2>
|          <3>        <3>
|          ...
|          <29>
|          <30>
|          <31>
 ----------------------------------
|          TW [#######.#]
 ----------------------------------
|
|  Help: TW = 2^Y * (1 + Z/4) * TU
|  where TU = 0.000976562
 ----------------------------------

Solution in Offset mode

This would be presented in parameter offset

 ----------------------------------
|           Y          Z
|
|         +10
|          +5
|          +4
|          +3         +3
|          +2         +2
|          +1         +1
 ----------------------------------
|         TW [#######.#]
 ----------------------------------
|          -1         -1
|          -2         -2
|          -3         -3
|          -4
|          -5
|         -10
|
|  Help: TW = 2^Y * (1 + Z/4) * TU
|  where TU = 0.000976562
 ----------------------------------

(EDIT) Solution in Profile mode

Each architecture will have its own table of Profile <-> TW associations

 ----------------------------------
|         <      None >
|         <   Minimum >
|         <    Office >
|         <     Gamer >
|         < Scientist >
|         <   Maximum >
|         < Unlimited >
 ----------------------------------

Choice

• My favorite being the Offset mode solution, feel free to suggest a UI design.

[TechieUser2517]

In practical terms I think a single slider with pre-calculated time window values would be less confusing. Users might not generally want much smaller or much larger values than their defaults, so a vertical slider should still be fine, even if it means that for setting extreme values they will have to scroll quite a bit.

Alternative: allow to use +/- keys to cycle through permitted values without bringing out a new slider dialog. However the way settings are applied might have to be rethought. Some settings might be dangerous (causing freezes, etc) if carelessly altered in this way. Additionally there might possibly be unacceptable delays if the settings are immediately applied as they are cycled through.

[cyring]

In practical terms I think a single slider with pre-calculated time window values would be less confusing. Users might not generally want much smaller or much larger values than their defaults, so a vertical slider should still be fine, even if it means that for setting extreme values they will have to scroll quite a bit.

Alternative: allow to use +/- keys to cycle through permitted values without bringing out a new slider dialog. However the way settings are applied might have to be rethought. Some settings might be dangerous (causing freezes, etc) if carelessly altered in this way. Additionally there might possibly be unacceptable delays if the settings are immediately applied as they are cycled through.

Rather than a window, this would be a new view where one can use the +/- keys.

This view could be a curve drawn on two axis.

In addition to the stressing functions applied to the CPUs in the upper area, somehow a X cursor will slide Y and Z on the curve in the bottom area.

My thoughts:

• Time Window is per CPU: thus one curve per CPU or a CPU selection mechanism
  EDIT: thankfully MSR_PKG_POWER_LIMIT is a Package register

• ASCII is not the best to render a curve
• Programming cost

[cyring]

Backend

Usage

modinfo corefreqk.ko

parm:           Custom_TDP_Offset:TDP Limit Offset (watt) (array of short)
parm:           Activate_TDP_Limit:Activate TDP Limiting (array of short)
parm:           Activate_TDP_Clamp:Activate TDP Clamping (array of short)
parm:           Custom_TDC_Offset:TDC Limit Offset (amp) (short)
parm:           Activate_TDC_Limit:Activate TDC Limiting (short)

Solution

parm:           Custom_TW_Offset:Time Window Offset (ms) (array of short)

or

parm:           Custom_TW_Register:Time Window Register (bits) (array of short)

[cyring]

@BugReporterZ Hello

Commit 597825f of the develop branch, you will get the backend implementation only of the Power Time Window

In the new kernel module parameter you will supply the raw 7 bits of the register (zero based)

Order matters when enumerating the pair TW1 , TW2 in a domain set Package, Cores, Uncore, RAM, Platform

Driver is taking care to blacklist unimplemented register bits. Thus you'll skip an unused TW with value -1

Exemple bellow, I'm changing my Package from (28, 0) to (5, 128) seconds and any other possible domain.

insmod corefreqk.ko PowerTimeWindow=0x2c,17,-1,-1,0x2c,17,0x2c,17,0x2c,-1

Remarks:

• Because it crashes my Tiger Lake, parameter Experimental=1 is required to alter TW2 of Platform.
• Domain Cores is fully blacklisted. Not even experimental.
• The maximum value of a TW is 0x7f (128); the bit-field size. Zero is an acceptable value.
• Kernel allows to set parameter in mixed hexa and decimal values.
• You need to unload/reload driver to try other values.
• Save and sync your file system before shooting the driver.

Thank you for your returns.

[TechieUser2517]

It looks like I am only able to change Package TW2, but it does not seem to have any practical effect on my system. If I set PL2 to a low level, a TW2 value of many seconds will not allow the CPU to exceed PL2 for any visible time. Either TW2 is internally capped at 10 milliseconds or it's not implemented here.

insmod corefreqk.ko PowerTimeWindow=0x2c,12,12,12,0x2c,12,0x2c,12,0x2c,12
./corefreqd
./corefreq-cli

EDIT: Note that the default package TW2 was displayed at "0.0 S" but it was probably in the range of a few milliseconds.

[cyring]

Tried your TW arguments but less PL on a Laptop stressed with Conics > Hyperboloid of two sheets but Processor watts seem also capped ; plus throttling events.

Clamping OFF did not make a difference also.

Is your use case working from XTU ? or from BIOS ?

[cyring]

This down-powering use case appears to work

It starts at 25W and quickly falls at 15W

[TechieUser2517]

Is your use case working from XTU ? or from BIOS ?

No, XTU does not have an option to set TW2 (only TW1), and neither the option is available in BIOS (MSI Z690 A-Pro).

Some Gigabyte/Aorus desktop motherboards present the option in BIOS, but on the one I had it was non-functional.

[cyring]

This commit 12b1d63 is formatting the time decimals.

[TechieUser2517]

B5 = BITLSHIFT(1,B1)*BITRSHIFT((4+B2),2)*B3
B6 = BITLSHIFT(1,B1)*(1+B2/4)*B3

[cyring]

B5 = BITLSHIFT(1,B1)*BITRSHIFT((4+B2),2)*B3
B6 = BITLSHIFT(1,B1)*(1+B2/4)*B3

Found the issue in the float constants.
from:

double TW_Manufacturer(unsigned short Y, unsigned short Z, double TU)
{
	return (1 << Y) * (1 + Z/4) * TU;
}

to:

double TW_Manufacturer(unsigned short Y, unsigned short Z, double TU)
{
	return (1 << Y) * (1.0 + Z / 4.0) * TU;
}

[cyring]

I just tested it with Libreoffice Calc so I could be wrong, but I think the rightwise bit shift in the optimized function is clipping decimal digits. Using Y=12 and Z=1 I am getting 4 seconds like CoreFreq.

Hope this commit 3717100 is working ?

[TechieUser2517]

It seems so. Package TW1 is 5 seconds as configured and Platform TW1 28 seconds (28 seconds is a standard Intel value). Package TW2 also became 2.44 ms (I think).

[cyring]

... Package TW2 also became 2.44 ms (I think).

It looks better; although I have not found the variation with the previous optimized formula!

Indeed whenever result is below 1.0, it is multiplied by 10000000 to fit into the UI cell:

CoreFreq/corefreq-cli.c

Line 4000 in 3717100

const unsigned long long TW1 = 10000000LLU

[cyring]

B/c I made a contusion with Nehalem register, last commit is about a refactoring of the PL lock which is read this time from bit 63 in MSR_PKG_POWER_LIMIT:

... or bit 31 in MSR_PP0_POWER_LIMIT/MSR_PP1_POWER_LIMIT

UI is also improved in the time window formatting from nano-seconds up to days

[TechieUser2517]

I can confirm micro- and milliseconds being displayed on Alder Lake:

[cyring]

I can confirm micro- and milliseconds being displayed on Alder Lake:

It looks cleaner. Thank you.

Doing that, I found that an old Ivy Bridge has an unlocked Uncore PL. It's now part of code but did not get any impact on Power use.

[cyring]

@BugReporterZ Just working on UI to select Time Window
No value transmitted to backend so far

iOS inspired but very sluggish.
Need to find a force refresh
CoreFreq_develop.tar.gz

[TechieUser2517]

Response time seems directly proportional to the interval rate in program settings. Reasonable at 100 ms, way too slow at 2000 ms or more.

[cyring]

Response time seems directly proportional to the interval rate in program settings. Reasonable at 100 ms, way too slow at 2000 ms or more.

Yep, there is no other way for me beside refactoring my UI lib.
Thanks for your try.

[cyring]

Found an improvement by rearranging the main loop where function WindowsUpdate() has been moved before GetKey()

Demo with UI microbench activated: make clean corefreq-cli UBENCH=1

[cyring]

@BugReporterZ Hello,
For your testings is available the new Time wheel selector in commit 7a8f0a8

• Range of values is sorted as a function result of Z and Y: listing is strange.
• Rotation speed has been fixed
• Up, Down, Enter and Escape are the only available keys.
• Still struggling in range shifting withPage, home, and End keys
• Current value is highlighted but not as a landing position yet
• Underscore line is not available in Linux console. But cyan is a shared color with XTerm.
• Other PLn fixes in Backend also.

[cyring]

@BugReporterZ thanks for your demo.
Happy to see it works with Alder Lake.
First wondering is about removing duplicates: indeed we have tuples of Y, Z which lead to the same Time Window value. But those tuples are not giving the same register value. How can we say if it makes or not a difference within the Processor logic ?
I mean: is the Processor considering the register bits or the final value for duration ?
Intel could answer to this but it won't happen.
So my question is: should we leave all the possible combinations (even if duplicated results) and let the Users decide based on register values ?

[TechieUser2517]

I can only say that I've not seen other programs on Windows exposing both values for the time window calculation, but I don't know how they set it.

Perhaps an idea could be looking at how they do it in the Linux kernel, since there is a sysfs interface for Intel power caps/limits.
https://www.kernel.org/doc/html/latest/power/powercap/powercap.html

[cyring]

Kernel powercap.txt

constraint_X_time_window_us (rw): Time window in micro seconds.

constraint_X_name (ro): An optional name of the constraint

constraint_X_max_power_uw(ro): Maximum allowed power in micro watts.

constraint_X_min_power_uw(ro): Minimum allowed power in micro watts.

constraint_X_max_time_window_us(ro): Maximum allowed time window in micro seconds.

Two time windows: I believe kernel maps TW1 as the first, TW2 for the max.

[TechieUser2517]

Currently I have these values. Long-term and Short-term values match what I see in CoreFreq and BIOS. Peak power is probably PL4 which is not specified on my system.

* = [0, 1, 2]

cat /sys/devices/virtual/powercap/intel-rapl/intel-rapl\:0/constraint_*_name 
long_term
short_term
peak_power

cat /sys/devices/virtual/powercap/intel-rapl/intel-rapl\:0/constraint_*_max_power_uw 
125000000
0
0

cat /sys/devices/virtual/powercap/intel-rapl/intel-rapl\:0/constraint_*_power_limit_uw
125000000
190000000
0

cat /sys/devices/virtual/powercap/intel-rapl/intel-rapl\:0/constraint_*_time_window_us
27983872
2440
0

I was referring in any case to the actual implementation in Linux kernel code, where they probably directly use the MSR also used in CoreFreq, i.e. in https://github.com/torvalds/linux/tree/master/drivers/powercap and related header files.

[cyring]

https://github.com/torvalds/linux/blob/d615b5416f8a1afeb82d13b238f8152c572d59c0/drivers/powercap/intel_rapl_common.c#L983

Special processing based on 2^Y*(1+F/4)

Edit:

• found how it is get.
• not found how it is set: Y only or Y and Z (named F in kernel)

[cyring]

Duration formatting needs to be reworked, especially sub us values

[cyring]

Hello

Can your AlderLake read MSR_DRAM_PERF_STATUS (0x61b) and MSR_DRAM_POWER_INFO (0x61c ?

[cyring]

Got this as a result:

[11652.309737] CoreFreq(0:1:19): Processor [ 06_97] Architecture [Alder Lake] SMT [20/20]
[11652.309779] resource sanity check: requesting [mem 0xfedc0000-0xfedcffff], which spans more than pnp 00:03 [mem 0xfedc0000-0xfedc7fff]
[11652.309781] caller Router+0xc3/0x100 [corefreqk] mapping multiple BARs
[11652.309795] CoreFreq: DRAM RAPL[0]

OK, DDR might linked to some software agent when present in BIOS.

Can you now print the output of PLL register ?

inline void RKL_SA(void __iomem *mchmap)
{
	PUBLIC(RO(Proc))->Uncore.Bus.ADL_SA_Pll.value = readq(mchmap+0x5918);
	pr_info("CoreFreq:Pll[%llx]\n",PUBLIC(RO(Proc))->Uncore.Bus.ADL_SA_Pll.value);
}

I'm expecting to decode the SA_VOLTAGE

[TechieUser2517]

Added that and now this is the output:

[21981.345146] CoreFreq(0:1:19): Processor [ 06_97] Architecture [Alder Lake] SMT [20/20]
[21981.345192] resource sanity check: requesting [mem 0xfedc0000-0xfedcffff], which spans more than pnp 00:03 [mem 0xfedc0000-0xfedc7fff]
[21981.345193] caller Router+0xc3/0x100 [corefreqk] mapping multiple BARs
[21981.345207] CoreFreq: DRAM RAPL[0]
[21981.345216] CoreFreq:Pll[21a2402e000490]

[cyring]

CoreFreq/intelmsr.h

Line 3646 in a154015

SA_VOLTAGE : 56-40, /* = 1/8192V */

From bits [56-40] we are getting 0x21a2(8610)

Applying the datasheet formula:

V = 8610 / 8192
V = 1.0510

One of the components is about this voltage.
Can you tell which one is it ?

[TechieUser2517]

Yes: 1.05V is the System Agent (SA) voltage, since it's the one I set in BIOS.

[cyring]

Yes: 1.05V is the System Agent (SA) voltage, since it's the one I set in BIOS.

For testings in discussion #338

[cyring]

@BugReporterZ For your review, in the attached archive, duration is converted into nano-seconds and I don't get duplicates (and btw sorted)

CoreFreq_develop.tar.gz

Could it be better to present items as bellow ?

0 d 00 h 00 m 00 s 000 ms 000 us 000 ns

[cyring]

A previous Gigabyte motherboard I had listed values up to 448 seconds, while the current MSI one only up to 128 seconds. It's entirely at the manufacturers' discretion and their idea on how it should be used.

Typical Intel values are 1s (hardware default), 8s (old suggested value), 28s (for locked processors), 56s (for unlocked processors), but these are only recommendations, not a specification.

EDIT: from the Intel spec sheet for the latest processors the min-max range is usually 0.1 ... 448 seconds, but this is just for PL1 Tau, not the shorter and usually not user-configurable Tau time for PL2/3/4.

Sheet fixed (in the formatted cells)
EDIT There are more hours than the formatted cells
TimeWindow_preview.ods.gz

Based on PL1/Tau, I'm counting 49 occurrences from 0.1 to 448 seconds

[TechieUser2517]

For PL1 perhaps just using/implying seconds could be enough, but I don't know if it's possible to reduce number precision where desirable.

[cyring]

For PL1 perhaps just using/implying seconds could be enough, but I don't know if it's possible to reduce number precision where desirable.

Meanwhile I have prepared this archive for your testings
Wheel should follow the spreadsheet range; starting at 0.1 s , ending at 7 m 28 s

CoreFreq_develop.tar.gz

[TechieUser2517]

This seems a good balance. But I'm not sure about the list wrapping around, and when opening the window it should probably first highlight the currently configured value (handling cases where it could be out of range).

For example here the default value was 0.625s even though TW1 was set to 28s.

[cyring]

This seems a good balance. But I'm not sure about the list wrapping around, and when opening the window it should probably first highlight the currently configured value (handling cases where it could be out of range).

For example here the default value was 0.625s even though TW1 was set to 28s.

Indeed 1 on 2 has be found with this PC booted with TW1=28 s and TW2=2 ms

28 s is highlighted

However 2 ms was not found

Need to match the Register list rather than the computed TAU. This impacts the Backend.

[cyring]

@BugReporterZ

This archive version aims to highlight the current TAU which is displayed when list is wrapping.

Prints are also changed for the seconds unit.

Backend API has been modified. You thus have to fully rebuild and reload CoreFreq to test these changes.

make clean all

CoreFreq_develop.tar.gz

[TechieUser2517]

Just in case I always do make clean all

On the attached CoreFreq build there appears to be still an issue where the default value when opening the list of Tau times is not the currently selected one. Furthermore, 28.00 seconds appears to be listed twice. I've made a video:

2022-04-30_tau-selection2.mp4

[TechieUser2517]

My current motherboard does not allow to change PL2 Tau. I'm only seeing that value from CoreFreq.

As a side note, there's also a popular Windows application that shows it, called HWInfo64; here are samples found on the Internet for different processors. Typically it's 2.44 ms although sometimes it can be higher or even unspecified.

https://user-images.githubusercontent.com/26941368/166139090-dbdf7ba6-8ef3-46c6-993e-4ea495490aa9.png
https://user-images.githubusercontent.com/26941368/166139192-13b6cb4f-1281-489a-a487-4f3cfbce0016.png

[cyring]

My current motherboard does not allow to change PL2 Tau. I'm only seeing that value from CoreFreq.

As a side note, there's also a popular Windows application that shows it, called HWInfo64; here are samples found on the Internet for different processors. Typically it's 2.44 ms although sometimes it can be higher or even unspecified.

https://user-images.githubusercontent.com/26941368/166139090-dbdf7ba6-8ef3-46c6-993e-4ea495490aa9.png https://user-images.githubusercontent.com/26941368/166139192-13b6cb4f-1281-489a-a487-4f3cfbce0016.png

Thanks but Linux only here.

Looking at 2nd screenshot that would be this range of values:

Currently enhancing code to include a pre-range of values but I feel by the end of day we might cover the whole set of values, starting at 0000 h 00 m 00,000976562

[TechieUser2517]

Currently enhancing code to include a pre-range of values but I feel by the end of day we might cover the whole set of values, starting at 0000 h 00 m 00,000976562

That could be the simplest idea.

I briefly rebooted into Windows and this is what the same application I mentioned shows. I do not know if the data is all via CPU registers; possibly it is also using undocumented MSRs since it's capable of even seeing voltage offsets for the VF curve set up in BIOS.

Long screenshot with CPU information

[cyring]

Thanks for your screenshot.

Especially astonished by this Fused Ratio Limit of 85x

So 2.44 ms is the lowest found by software:, it is not worth to program rules exception in our Wheel; let just cover the range from zero to 448 seconds. Don't you think so ?

[TechieUser2517]

Makes sense; perhaps excluding few microsecond- and nanosecond-long values could make it more convenient to use. Maybe a "range extension" option could be included for those who desire setting something beyond these values.

[cyring]

Yes, the current is not the selected one. It just falls at the window center.

Yes current TAU can be duplicated but not coming from same Z and Y. Conditionally adding or removing current TAU is unbalancing and thus breaking the wheel.

I'll let you know when they're improved.

[cyring]

@BugReporterZ You can try this on-going development.

CoreFreq_develop.tar.gz

Some scrollings are broken. Please just look at the range of values which so far can go as low as 2 ms, referring to your first screenshot.

So we're now just 5 cells from zero:

[TechieUser2517]

I tried this and I could set PL2 Tau to ~1 or ~4 ms, but not intermediate values between these two.

[cyring]

Yes List exceptions make the code fragile.
As mentioned above, I'm changing back to cover from Y=0 Z=0 up to 448 ms
Which means that the only remaining exception will be the highest reachable TAU.

[cyring]

@BugReporterZ For your testings, this version present a list from the first possible of 0,000976 seconds up to 512 seconds.

CoreFreq_develop.tar.gz

As a placeholder, the last can be overwritten by any out of range value set previously by BIOS, software and so on.

In the following use-case I have intentionally started driver with:

insmod corefreqk.ko PowerTimeWindow=0x7f

Thus the list is replacing 512 with 3670016 to expose it during selection.
However as soon as the Limiter is altered, the list presents again a max of 512.

If things are OK for you, I will push developments.

[TechieUser2517]

The changes appear to work, although probably there will eventually need to be some option to change the maximum value through the UI, otherwise this will not be as straightforward to accomplish in particular with CoreFreq versions from distribution repositories. I don't imagine there will be significant demand for it, though.

[cyring]

For larger audience testing, code is released in the commit 0ad8d05