Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Adguard GUI unnecessarily raising Windows platform timer resolution #2734

Closed
tox1c90 opened this issue Jun 5, 2019 · 11 comments
Closed

Adguard GUI unnecessarily raising Windows platform timer resolution #2734

tox1c90 opened this issue Jun 5, 2019 · 11 comments
Assignees
Milestone

Comments

@tox1c90
Copy link

tox1c90 commented Jun 5, 2019

Steps to reproduce

  1. After Windows has booted with Adguard being launched automatically but minimized to tray icon, run "powercfg /energy /duration 1" from elevated shell
  2. Open the generated "energy-report.html", look at the "Information" section and confirm that Windows platform timer resolution is at its default value 156000 and that no other process is running that raises timer resolution.
  3. Open Adguard GUI and interact with it in any way, for example press "Settings" or check for updates.
  4. Run "powercfg /energy /duration 1" again and you will see that Adguard.exe now has requested a Platform Timer Resolution of 10000 which causes energy report to issue a warning
  5. Close Adguard GUI by pressing "x", but leave it running in the background (minimized to tray)
  6. Check "powercfg /energy /duration 1" and see that Platform Timer Resolution is still forced to 10000 by Adguard.exe, even though the GUI is not rendered anymore. It will stay like this forever.
  7. Do "Close Adguard, but continue filtering", restart Adguard and minimize it directly to tray via "x" without any other interaction with the GUI
  8. Platform Timer Resolution is back to default 156000

Expected behavior

It is common for GUIs using WPF or for example Chromium to raise platform timer resolution when it's needed, so when the Adguard GUI is shown and not minimized, this can be the normal behavior. But when it's minimized to tray, this should be stopped and timer resolution should be reverted to it's default value, to allow the CPU to reach it's lowest power states.

Actual behavior

Once Adguard.exe causes the platform timer resolution to be raised, it stays there until the process is terminated, even when Adguard GUI is not rendered anymore but minimized to tray.

Background information on why this is bad: https://randomascii.wordpress.com/2013/07/08/windows-timer-resolution-megawatts-wasted/

Short version: Much lower CPU C state usage because of raised timer resolution, thus higher idle power consumption, very bad for battery life

On my PC the CPU core C7 state usage is dropping from ~95% to ~86% just after Adguard increased timer resolution.

Screenshot:

warning

adguard_timerresolution

Customer ID

Your environment

  • Operating system and version: Tested on two different PCs, Windows 10 (1903) and Windows 7
  • Adguard 7.0.2693.6661
@ameshkov ameshkov added this to the 7.2 milestone Jun 6, 2019
@ameshkov
Copy link
Member

ameshkov commented Jun 6, 2019

Thanks for reporting it!

As I understand, the only way to fix this is to call timeBeginPeriod and restore it once the program is minimized for some time (for a couple of minutes at least).

We'll need to check if that causes any issues with it.

@ameshkov ameshkov added the UI label Jun 6, 2019
@tox1c90
Copy link
Author

tox1c90 commented Jun 6, 2019

The problem is you can only close these particular requests using timeEndPeriod that you opened before using timeBeginPeriod. Because Windows will remember all timer calls by different processes and set the timer period to the lowest value requested.
So even if you call timeEndPeriod, if there is still another process running that also raised timer resolution, it will stay raised.

It could be that you are not even doing such calls within your own code. In the linked blog article, it is mentioned that WPF, or to be more precise wpfgfx_v0400.dll is raising the timer resolution to render certain UI elements.

As far as I understood, if it's not your code which is calling timeBeginPeriod at the moment, but this DLL, then you cannot do anything to cancel that call from within your own code, because from Windows point of view, wpfgfx_v0400.dll still needs the low timer period. There is also a thread at MSDN regarding this issue, with a guy complaining that he is helpless against it:
https://social.msdn.microsoft.com/Forums/sqlserver/en-US/e35c2b9d-600f-4dfe-b5b4-5a146a825c8c/wpfgfxv0400dll-calls-timebeginperiod?forum=wpf

Could it be that you are unintentionally still rendering parts of your UI, even if it's minimized?

@northis
Copy link
Member

northis commented Jun 6, 2019

@tox1c90 We will try to solve the problem.
About the latest question - when the program is minimized in tray, its windows are in hidden state, so they aren't rendered.

@northis
Copy link
Member

northis commented Jul 3, 2019

Resolved in adguard-windows/pull-requests/537

@stale
Copy link

stale bot commented Sep 1, 2019

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@stale stale bot added the wontfix label Sep 1, 2019
@zzebrum zzebrum closed this as completed Sep 3, 2019
@tox1c90
Copy link
Author

tox1c90 commented Sep 22, 2019

Although the changelog states that it was fixed "[Fixed] AdGuard GUI unnecessarily raises Windows platform timer resolution #2734", it's behaving exactly the same as before on my PCs. That's a bit strange....

@northis
Copy link
Member

northis commented Sep 23, 2019

@tox1c90 Perhaps, we've taken in account not all the cases - issue is really reproduced on main window. We'll fix it of course. But the rest of the cases are ok.
Please, open the filtering log window, close the main window, than close the filtering window and do the report.
After this Requested Period by AdGuard should be 156000.

@northis northis reopened this Sep 23, 2019
@stale stale bot removed the wontfix label Sep 23, 2019
@northis northis modified the milestones: 7.2, 7.3 Sep 23, 2019
@northis
Copy link
Member

northis commented Sep 24, 2019

Resolved in adguard-windows/pull-requests/648

@tox1c90
Copy link
Author

tox1c90 commented Dec 21, 2019

I am sorry, I really dont want to annoy you again with this issue, but would you mind setting it to 156250 instead, because this is the default value of Windows 8 and 10 upwards.

156000 was the Windows 7 default. The difference is quite tiny, but calling 156000 still results in an energy report warning.
And I think for a permanent solution it's better to do it in a clean way and put it to the correct value.

@zzebrum zzebrum reopened this Dec 24, 2019
@zzebrum zzebrum modified the milestones: 7.3, 7.4 Dec 24, 2019
@northis
Copy link
Member

northis commented Dec 25, 2019

@tox1c90 No problem, we will change it.

@northis
Copy link
Member

northis commented Jan 30, 2020

Resolved in adguard-windows/pull-requests/803

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants