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

fixed the heating problem on charging #286

Open
wants to merge 5 commits into
base: master
Choose a base branch
from

Conversation

achintya-7
Copy link

Issue: #279

The temperature is quite stable now while charging. I am using various applications like vscode, whatsdesk, teams, discord and a browser with several tabs. I believe the problem was that it turns turbo ON when the laptop is charging which increased the temperature to around 65 to 75 Celsius. Currently with all the above applications open that too for more than an hour, the temperature is around 40 Celsius. I am adding the screenshots for the debug and stats command below along with a modified .conf file.

Earlier even though setting the governer as powersave, I still was facing the heating issues on charging because somehow it was not shutting off the turbo.

debug

stats

config

I have added a new parameter for the /etc/auto-cpufreq.conf file. If you are facing heating issue, set the new parameter as 1.
@AdnanHodzic
Copy link
Owner

Hey, thanks for your contribution, but it seems like some things are missing as part of this PR, as soon as I try to run it in live mode I get following error:

ahodzic@carbon7 ~/code/auto-cpufreq (achintya-7-master)$ sudo auto-cpufreq --live

Note: You can quit live mode by pressing "ctrl+c"

-------------------------------------------------------------------------------

Linux distro: Ubuntu 21.10 impish
Linux kernel: 5.13.0-21-generic
Processor: Intel(R) Core(TM) i7-8565U CPU @ 1.80GHz
Cores: 8
Architecture: x86_64
Driver: intel_pstate

------------------------------ Current CPU stats ------------------------------

CPU max frequency: 4600 MHz
CPU min frequency: 400 MHz

Core	Usage	Temperature	Frequency
CPU0:	  5.9%     61 °C     2000 MHz
CPU1:	  5.1%     61 °C     2000 MHz
CPU2:	  6.8%     59 °C     3784 MHz
CPU3:	  6.9%     60 °C     2000 MHz
CPU4:	  5.1%     61 °C     2000 MHz
CPU5:	  6.0%     61 °C     2000 MHz
CPU6:	  6.9%     59 °C     2000 MHz
CPU7:	  6.1%     60 °C     2000 MHz

---------------------------- CPU frequency scaling ----------------------------

Traceback (most recent call last):
  File "/usr/local/bin/auto-cpufreq", line 4, in <module>
    __import__('pkg_resources').run_script('auto-cpufreq==1.0', 'auto-cpufreq')
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 651, in run_script
    self.require(requires)[0].run_script(script_name, ns)
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 1455, in run_script
    exec(script_code, namespace, namespace)
  File "/usr/local/lib/python3.9/dist-packages/auto_cpufreq-1.0-py3.9.egg/EGG-INFO/scripts/auto-cpufreq", line 169, in <module>
  File "/usr/lib/python3/dist-packages/click/core.py", line 829, in __call__
    return self.main(*args, **kwargs)
  File "/usr/lib/python3/dist-packages/click/core.py", line 782, in main
    rv = self.invoke(ctx)
  File "/usr/lib/python3/dist-packages/click/core.py", line 1066, in invoke
    return ctx.invoke(self.callback, **ctx.params)
  File "/usr/lib/python3/dist-packages/click/core.py", line 610, in invoke
    return callback(*args, **kwargs)
  File "/usr/local/lib/python3.9/dist-packages/auto_cpufreq-1.0-py3.9.egg/EGG-INFO/scripts/auto-cpufreq", line 95, in main
  File "/usr/local/lib/python3.9/dist-packages/auto_cpufreq-1.0-py3.9.egg/auto_cpufreq/core.py", line 874, in set_autofreq
  File "/usr/local/lib/python3.9/dist-packages/auto_cpufreq-1.0-py3.9.egg/auto_cpufreq/core.py", line 191, in charging
KeyError: 'heating_problem'

@achintya-7
Copy link
Author

achintya-7 commented Nov 21, 2021

It seems that this is caused because no auto-cpufreq.conf file is formed by default. I should have put this in a try catch field to prevent this error. Can you also check the code again including the auto-cpufreq.conf file.

@AdnanHodzic
Copy link
Owner

Changes make sense to me, but I'll need to test them bit more under heavy workload (as I don't have the overheating you have).

But could you make following changes as part of this PR:

  1. Make it work when user is not using config file
  2. With these changes, auto-cpufreq --live or --stats will state: "No config file being used" even when /etc/auto-cpufreq.conf is in place.

@achintya-7
Copy link
Author

Ok sir, I will be continuing to work and test on this error after the exams.

@AnonPol
Copy link

AnonPol commented Nov 24, 2021

@AdnanHodzic I think it's best the tool respects kernel defaults for CPU governor and only modifies the turbo boost to on or off depending on how intensive the activity is on CPU. This "powersave" governor of CPUFreq can cause massive under-performance while device is on battery and the "performance" governor can cause overheating while device is charging due to both of these governors from my understanding setting the CPU frequency always to minimum and maximum frequency that it can run at. TLP another battery saving tool by default respects the kernel defaults for CPU governor. Intel_pstate "performance" and "powersave" governors are a different matter. Both of the intel_pstate governors operate similar to schedutil/on-demand governor of CPUFreq so not sure what point there is to changing between them while charging and on battery.

@AdnanHodzic
Copy link
Owner

AdnanHodzic commented Nov 25, 2021

@AnonPol I think it's best to have this kind of discussion under discussions section and not as part of this PR. But short answer is that auto-cpufreq was designed to respect and let the kernel do the heavy lifting.

However, landscape is filled with various different hardware and specs which means making decisions automatically is not an easy chores. Hence, if something works better for certain users while they define it as part of custom configuration file for their needs, I see no problem in that nor does it deviate from original strategy which I outlined above.

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

Successfully merging this pull request may close these issues.

None yet

3 participants