Cannot set < 22% as minimal?!

[steadfasterX]

If I set the minimal frequency to 22% or higher all is fine - means the settings keep saved. When I set to lower then 22% (0-21%) it always switch back to 22% ?! Directly when set (1 sec delay or so). The same goes for the maximal frequence.. The minimal setting I can use is 22 %...

Any idea why or how to troubleshoot?

[fin-ger]

I think this happens because your CPU does not allow you to set you frequency below 800MHz or something (at least for modern Intel CPUs).

[martin31821]

800MHz / 22% ~ 3600MHz

You can not set the frequency below 800 MHz but this is not related to this extension. I could scale the values such that 22% in pstate = 0% in the extension

[steadfasterX]

oh ok I have the following CPU: Intel(R) Core(TM) i7-6820HK CPU @ 2.70GHz which is able to turbo boost up to 3,6 Ghz .. the 800 Mhz limit was unknown to me but it seems to match here...

Hm scaling could let users think that it is not working as expected, too. Better would be some hint about the limit by intel cpu and maybe let the user not scale lower then this (but showing the real % used) Would that be possible?

[martin31821]

The problem is that the pstate driver doesn't tell anything about the minimum value which can be set, I can try and parse some other files (/proc/cpuinfo) but there is no guarantee that I can extract any information about the maximum (regular) frequency.

I think in linux <= 4.2/4.3 it was working, maybe I can try to reproduce this in 4.1 LTS.

maybe let the user not scale lower then this (but showing the real % used) Would that be possible? This is nearly exactly what is happening now, the pstate driver resets the value to the minimal value it can handle and this is displayed. I just can add a clamp to 22/23% which should improve this further.

[martin31821]

I created a small check which tries to set the min_perf_pct to 0 and then reads back the value which should be the minimum value.

[eode]

From a UI perspective, I think it'd be nice if you: 1) Check the min_perf_pct by set/read, or read a saved value from a previous check 2) Set a hard stopping point on the slider at that percent (so the slider only goes that far) 3) If it's at the lowest point, change the text from a percentage to "Lowest" or "Hardware Limit"

[ayoungethan]

Pretty sure this is a hardware limitation (for me it is 20%). I don't see the point in making any change to the interface except for maybe a little note somewhere in the extension. There isn't much space to do anything in the main GUI. A tooltip or a little information link would suffice, such as "NOTE: the slider will automatically jump up to the minimum frequency available when attempting to set below the threshold of hardware capacity."

IMO dynamically changing the GUI text might add confusion. People would wonder what "lowest" or "limit" means, and there isn't much space for anything else. A little "information button" (such as https://www.flaticon.com/free-icon/round-info-button_61093) with something like the above-mentioned note would work well in that cramped space, I think. And is much easier to implement than trying to automatically parse the driver for values.

Just my .02 cents.

[mastercaution]

Actually, there is already an option that reads out the minimum (and also maximum) percentage set by the driver. It's in the cpufreqctl script (here) and there is also a JS function in indicator.js (here) but this function is not yet used very well.

A few months ago I experimented a bit around with this. In my eyes it's a pretty bad design to let a slider "randomly" jump around directly after user interaction (no offense here! :D). I mean an inexperienced user could think that his setting was not applied in the right way, and he will try to set the value to 0 again and again until he runs into frustration.

I have two ideas to handle this minimum (and maybe also maximum) value:

1. Slider on 0% -> CPU freq preference is on the drivers minimum. It's pretty much hiding this from the user.
2. Slider is locked below the minimum value to the minimum value ... but this still requires some sort of explanation. (So you can't move it under 8% for example)

I tested both ideas on my own. 2. is nice because it doesn't hide something from the user but 1. is simpler and adds less overhead while moving the slider. I would love to hear your opinions on that or maybe new ideas for making it perfect ;)

I like your idea @ayoungethan with that icon though. Unfortunately the Gnome extension API doesn't have a tooltip-option so the button needs to insert text to the popup or open a little window or something.

[ayoungethan]

@mastercaution I like idea 2:

Slider is locked under the minimum value to the minimum value ... but this still requires some sort of explanation. (So you can't move it under 8% for example)

In the absence of a tooltip, a little single-sentence pop-up help window I think makes sense.

[eode]

I'm with Chris on this - it's pretty weird to have a user-input slider jump around right after input. Or ever, really. The only exceptions I've seen to this, UI-wise, was where the user input directly affects other user input - like if you click to fix an aspect ratio, and then alter X or Y when selecting an image resolution, for example.

This, however, is no such case. There's a testable minimum, and a clear maximum.

UI wise, you could set the slider end labels to 'min' and 'max', with the current percentage centered.

Or, if there are no end labels, just replace the lowest value with 'Min' and highest with 'Max', or something similar.

On Thu, Jul 2, 2020, 12:16 PM ethan young notifications@github.com wrote:

@mastercaution https://github.com/mastercaution I like idea 2:

Slider is locked under the minimum value to the minimum value ... but this still requires some sort of explanation. (So you can't move it under 8% for example)

In the absence of a tooltip, a little single-sentence pop-up help window I think makes sense.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/martin31821/cpupower/issues/25#issuecomment-653100480, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAS4PT5UCBQ2WOYPVU4FENLRZSXEBANCNFSM4B7CWOOA .

[fin-ger]

To shed some light on this:

My initial plans were to write a custom GJS slider which would grey out the area on the slider which is below the hardware minimum.

However, this has several drawbacks:

1. It takes a some time to develop such a custom slider, which I currently don't have available
2. Being compatible with all the themes out there will be hard, if not impossible (we already have theme related issues, although we do not use any custom UI elements)
3. This slider would still be not clear on why the user can't set below e.g. 22%

As noted by @ayoungethan, we can solve 3) by adding a small tooltip which says Hardware minimum reached or similar. For 2) I don't think that custom UI elements will make things worse when sticking to predefined colors in the CSS. We already have to test each release on Fedora, Ubuntu, Arch, etc. to make sure the extension runs as expected, so looking for theme issues will not add additional steps for a release.

This leaves us with 1) - I'm currently lacking time for this.

[martin31821]

In addition to the minimum issue, since some recent kernel versions, the pstate driver seems to ignore some maximum values and just let this slider jump back, too.

I agree with all of you, that the minimum slider should be locked at the testable minimum.

[maxjf1]

I have this problem too, and understand that is an CPU limitation, but is there an real fix? (unrelated to the plugin)