9.1. performance mode settings do not work 100% anymore

Started by ranko, June 03, 2019, 08:53:52 AM

Previous topic - Next topic

ranko

Hi,

since a while performance mode does not work to 100% anymore.

For some applications it works still, but others are not recognized like my steam game that I entered with full path to "game.exe".
But also the steam detection does not work anymore.

My settings:



I know that normally the NFTS filesystem should not differentiate between uppercase and lower case letters.
I notice that after adding an application the full path is being converted to lowercase, could this be a reason for that ?



After clicking "OK" there are only 3 full paths to applications left:



Xeon E5-1680v4 | Supermicro X10SRi-F | 64GB DDR4 ECC | MSI RTX4070 Ventus | X710-DA2 | Win10 Pro 22H2

Jeremy Collake

The case should not matter. Process Lasso does case insensitive compares and converts rules to lowercase for consistency. That is why the then duplicated rules are disappearing.

That said, I am not sure what is going on here.

What does the log say, of anything, when you launch one of the games that should be detected?
Software Engineer. Bitsum LLC.

ranko

One problem is solved, the path of the "game.exe" executeable changed, sorry I didn't know.
They introduced now a win64 subdirectory for 64bit applications.

But the automatic detection still does not work, when a steam game is being started.
Steam games you could IMHO recognize by checking, whether an application has this path (at least on a default installation):
C:\Program Files (x86)\Steam\steamapps\common
I am not sure how you do it, maybe there are better ways, should steam allow to deploy also to other volumes.

BTW .. I am glad that the steam executable itself doesn't trigger performance mode (C:\Program Files (x86)\Steam\Steam.exe)
because the steam platform itself doesn't justify IMHO entering performance mode.

Today I discovered another thing which does not work as before.
Process Lasse doesn't quit "energy saving mode" anymore when simply moving the mouse on the screen.
Now you have to click at least to a window to exit energy saving mode.
Shall the intention be, to prevent "false positives" by accidently moving/touching the mouse on the desk, well ok.
But I personally preferred, that the default performance mode kicks in, as soon as I move the mouse.

Many thanks upfront if you could kindly explain and eventually change if you also think that it might sense to you and all customers.
Xeon E5-1680v4 | Supermicro X10SRi-F | 64GB DDR4 ECC | MSI RTX4070 Ventus | X710-DA2 | Win10 Pro 22H2

edkiefer

Thanks for the report, on the idlesaver, it should come out of idle with mouse movement, it is working here fine.
Does your display wake up with mouse movement?

On the Steam games it can be hit or miss and yes adding "C:\Program Files (x86)\Steam\steamapps\common\*.exe" can help.
Bitsum QA Engineer

Jeremy Collake

Glad it was just a new path! Makes sense.

Probably I need to play with Steam and check the auto detection.

Idlesaver should respond immediately to mouse movement. It sounds odd that you would have to click a window. I do wonder if the display of it exiting is just lagging behind. How are you watching it? It can change behavior with Performance Mode, depending on settings, but that doesn't sound like the issue. Maybe you and Ed can figure out how to reproduce for me.
Software Engineer. Bitsum LLC.

ranko

My system didn't change since my last installation of Win7 Professional SP1 which was according to systeminfo: 22.12.2017, 13:46:46.

I parametrized settings for all energy profiles, that my system / monitor stays on for longer time.
So in my "failure szenario" where I need to click to a window to cancel  "power save mode", the system is fully functional nothing is sleeping or whatever.
Xeon E5-1680v4 | Supermicro X10SRi-F | 64GB DDR4 ECC | MSI RTX4070 Ventus | X710-DA2 | Win10 Pro 22H2

ranko

Today I made some tests with different times for the IdleSaver.
First I thougt that I can not reproduce the issue anymore, that IdleSaver does not change from "Energy Saving" mode back to the default "Balanced" energy profile. I choosed 2 seconds not having to wait for too long and on an IDLE system the IdleSaver terminated/restored the default power profile within 0-2 seconds.

Then I switched back to 60 seconds and then again the issue, that I could move my mouse for a very long time, approx 50 seconds over the screen, before the default power profile became active again.

When repeating the test then it didnt switch to default power profile within 2 minutes and when I started then clicking with the mouse additionalyl then it took 10-15 seconds more until the change happened.
Xeon E5-1680v4 | Supermicro X10SRi-F | 64GB DDR4 ECC | MSI RTX4070 Ventus | X710-DA2 | Win10 Pro 22H2

edkiefer

Quote from: ranko on June 05, 2019, 01:33:20 AM
Today I made some tests with different times for the IdleSaver.
First I thougt that I can not reproduce the issue anymore, that IdleSaver does not change from "Energy Saving" mode back to the default "Balanced" energy profile. I choosed 2 seconds not having to wait for too long and on an IDLE system the IdleSaver terminated/restored the default power profile within 0-2 seconds.

Then I switched back to 60 seconds and then again the issue, that I could move my mouse for a very long time, approx 50 seconds over the screen, before the default power profile became active again.

When repeating the test then it didnt switch to default power profile within 2 minutes and when I started then clicking with the mouse additionalyl then it took 10-15 seconds more until the change happened.
I tried to reproduce what you're saying using 60sec and 120sec values, each time as soon as I move the mouse I am back to default.
When you say for example 60 seconds, that is the time PL will switch to energy saving power plan, how long do you let it idle in this state before moving the mouse?
Bitsum QA Engineer

ranko

When performing the tests with 60 seconds, then I waited approx between 1-20 secons before moving the mouse.
Didnt look every second to the clock at that interval.
Strange is that it works without issues at lower intervals like 2 or 5s.
Xeon E5-1680v4 | Supermicro X10SRi-F | 64GB DDR4 ECC | MSI RTX4070 Ventus | X710-DA2 | Win10 Pro 22H2

edkiefer

Quote from: ranko on June 05, 2019, 12:25:37 PM
When performing the tests with 60 seconds, then I waited approx between 1-20 secons before moving the mouse.
Didnt look every second to the clock at that interval.
Strange is that it works without issues at lower intervals like 2 or 5s.
That is odd it works with shorter time values, I tried again a few times and 60 and 120 seconds work fine here.
I can't think of anything that would do that off hand.
Bitsum QA Engineer

Jeremy Collake

Interesting. I am not sure what to make of this report

I also ran some tests and don't see the same issue. IdleSaver exits immediately when the mouse is moved.

We do need to test on Windows 7, though it shouldn't behave differently.

Do you have ParkControl installed by chance? Its Dynamic Boost could interfere.

I also assume your CPU load is not consistently at 100% during these tests? Just so we know, it shouldn't matter.
Software Engineer. Bitsum LLC.

ranko

1. No parkcontrol running
2.  All tests on an idle system.
OS: Win7 Professional SP1, latest Patchlevel.
System: CPU Xeon E5-1650v3, Supermicro X10SRi-F, 32 GB ECC RAM.

Parkcontrol is a great tool. I used it only once to tweak my energy profiles, its not running anymore in parallel.
With it I could achieve that only the 6 main cores (not the hyperthreaded cores) are running and that the clock runs at 2.5 GHz.

What I could do .. I have a 2nd SSD with a Win10 parallel installation running for testing/evaluating Win10.
It is an upgrade installation based on my Win7 system, so more or less the same drivers/applications plus eventually some new drivers with Win10.
The only modifications which I did there is:
- O&O Shutup 10 for Administrator and my account (use per account): https://www.oo-software.com/de/shutup10
- deactivate Live Apps in Win10 Startmenu
- installation of 8Gadgets and the gadgets which I typically use: https://8gadgetpack.net/
- installation of "Open Shell Menu" (old classic shell, further developed): https://open-shell.github.io/Open-Shell-Menu/

See here: https://www.forum.rme-audio.de/viewtopic.php?id=28786

Lets see whether it behaves same or different on Win10.
Xeon E5-1680v4 | Supermicro X10SRi-F | 64GB DDR4 ECC | MSI RTX4070 Ventus | X710-DA2 | Win10 Pro 22H2

ranko

Under Win10 I could not reproduce the issue.

I am using btw this power monitoring gadget under both systems: https://orbmu2k.de/sidebar-gadgets/power-status-sidebar-gadget

Under Win10 I got the idea and added a 2nd gadget tool - Systemmonitor II from the 8Gadget suite - which also monitors the energy power state
and found out that there is sometimes a deviation in status updates of up to 8 seconds with Systemmonitor II. But not always.

This puts up the question, whether my sidebar gadget from orbmu2k (which up to now worked flawlessly under Win7) MAYBE also has deviations.

I am thinking now how I can double check with a 2nd status tool whether my gadget works under Win7 well or whether it brought up the whole thing.

At the moment I think about this for doubleshecking:

As my energy profiles are tweaked well and set a very significant clock on my CPU I could use another status monitoring tool called HWMonitor
(https://www.cpuid.com/softwares/hwmonitor-pro.html) and watch the change of CPU clock and doublecheck with it whether a energy profile
change happened based on the clock I see
and whether my Power Gadget from Orbmu2k is exactly in sync with it or how much the max deviation is. A few seconds won't mind.
Remeber, last time I had to move the mouse for more than 1 or 2 minutes and no power status change happened.
Xeon E5-1680v4 | Supermicro X10SRi-F | 64GB DDR4 ECC | MSI RTX4070 Ventus | X710-DA2 | Win10 Pro 22H2

ranko

Good news, I could validate under Windows 7, that my Power Gadget from orbmu2k works fine. It seems to have a fix compiled in update interval of 1 (or maybe 2) seconds.
During these 3-4 set of tests the error didn't show up. I had this already a couple of times where I thought I couldn't reproduce but then of all sudding it was still there.

For my testing I moved the gadget over the HW Monitor Pro screen close to the actual clock values to be able to validate, that a state change happens in both tools.



This means to me that I can rely on the power gadget and that my issues here are not based on a wrong status display of the gadget.
And in the past I never saw a deviation that moving the mouse for a long time didn't change the status.
So I think there could be an issue under Win7.
Xeon E5-1680v4 | Supermicro X10SRi-F | 64GB DDR4 ECC | MSI RTX4070 Ventus | X710-DA2 | Win10 Pro 22H2

Jeremy Collake

Thanks for the work and info diagnosing this! It is good that it doesn't happen on your Windows 10 install.

We'll get to running those tests in Windows 7 and see if we can reproduce.
Software Engineer. Bitsum LLC.

ranko

Xeon E5-1680v4 | Supermicro X10SRi-F | 64GB DDR4 ECC | MSI RTX4070 Ventus | X710-DA2 | Win10 Pro 22H2