search

OpenELEC / OpenELEC.tv

OpenELEC - The living room PC for everyone
http://openelec.tv
1.61k stars 883 forks source link

Raspberry Pi change Kernel governator to "ondemand" #1258

Closed tutifrutas closed 12 years ago

tutifrutas commented 12 years ago

the kernel is using the "conservative" governor by default, not "ondemand" . This is an issue due to the fact that the freq doesn't go back to default for example when sitting idle on the menu. Changing to ondemand solves the issue

MikeBuzz commented 12 years ago

this is not needed all thats needed is the latest firmware, i have tested as below

frequency(45)=950000000 root ~ # vcgencmd measure_clock arm frequency(45)=950000000 root ~ # vcgencmd measure_clock arm frequency(45)=950000000 root ~ # vcgencmd measure_clock arm frequency(45)=900000000

root ~ # vcgencmd version Sep 20 2012 22:38:16 Copyright (c) 2012 Broadcom version 338528 (release)

tutifrutas commented 12 years ago

the problem is not the frequency changing, the problem is that is does not goes back to default. The previous governator was allways maxing out even on idle. As far i could understand what Dom said. there is no in-between Frequencies, there is default and the maximum you set on the config, there is no steeping in the frequency. Ondemand goes from default to max and max to default when it is idle, on the menu for example.

http://www.raspberrypi.org/phpBB3/viewtopic.php?p=173680#p173680

tutifrutas commented 12 years ago

here is the log from dmesg

[ 8428.732139] bcm2835-cpufreq: Freq 700000->800000 (min=700000 max=800000 target=800000 request=800000) [ 8429.092086] bcm2835-cpufreq: Freq 800000->700000 (min=700000 max=800000 target=700000 request=700000) [ 8497.422918] bcm2835-cpufreq: switching to governor conservative [ 8497.422951] bcm2835-cpufreq: switching to governor conservative [ 8525.562220] bcm2835-cpufreq: Freq 700000->740000 (min=700000 max=800000 target=740000 request=740000) [ 8532.401662] bcm2835-cpufreq: Freq 740000->780000 (min=700000 max=800000 target=780000 request=780000) [ 8532.761624] bcm2835-cpufreq: Freq 780000->800000 (min=700000 max=800000 target=800000 request=800000) [ 8644.952100] bcm2835-cpufreq: switching to governor ondemand [ 8644.952131] bcm2835-cpufreq: switching to governor ondemand [ 8645.332212] bcm2835-cpufreq: Freq 800000->700000 (min=700000 max=800000 target=700000 request=700000)

as you can see the conservative does not put back the default i had to change it to ondemand and the first thing it did was to put it on default, take a look also at the time stamps i did left it a couple of mins on idle to see what happend

this is was tested on r11974

MikeBuzz commented 12 years ago

As it works on all other platforms with no issues, the only other difference i can find is that within linux.arm.conf the default is set set to ondemand where all other platforms are set to conservative, i will test changing these to match all other build and report back

MikeBuzz commented 12 years ago

Also as above i have had it drop aswell as increase as noted above

root ~ # vcgencmd measure_clock arm frequency(45)=950000000 root ~ # vcgencmd measure_clock arm frequency(45)=900000000

i dont have the message log for that time, but will check and report back once the new build has finished

tutifrutas commented 12 years ago

echo conservative > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor and echo ondemand > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor

dmesg

the problem is that conservative is more slow and needs low idle to go back to default, since xbmc is allways using like 20% it will probably never go back to default. and on pi 24/7 this can be a problem.

on normal systems conservative is better option since slower increase results in less power consumption

MikeBuzz commented 12 years ago

Yes this is the issue changing the 93_xbmc changes for all platforms so is not ideal, not sure is there is a way round this, let me have a look as we can also tweak the setting for conservative

tutifrutas commented 12 years ago

maybe put a hack in place check /proc/cpuinfo for "BCM2708" or something that is unique to the PI and set it ondemand after the lines setting it to conservative

MikeBuzz commented 12 years ago

I am seeing very strange behaviour, you can see that from the below you would think the CPU is running at 1000mhz

Sep 22 12:01:15 openelec user.info kernel: [ 79.777392] bcm2835-cpufreq: Freq 1000000->700000 (min=700000 max=1000000 target=700000 request=700000) Sep 22 12:02:13 openelec user.info kernel: [ 178.107450] bcm2835-cpufreq: Freq 700000->1000000 (min=700000 max=1000000 target=1000000 request=1000000)

but checking with the vcgencmd tool reports its at 700mhz root ~ # vcgencmd measure_clock arm frequency(45)=700000000

sraue commented 12 years ago

do we have a problem with "ondemand" on other platforms then RPi? if so i will work on a different solution

MikeBuzz commented 12 years ago

Ondemand did cause the e350 to ramp up to 1.6ghz, and run hotter, which caused then the fans to run more often,making the systems noisier On Sep 22, 2012 2:02 PM, "Stephan Raue" notifications@github.com wrote:

do we have a problem with "ondemand" on other platforms then RPi? if so i will work on a different solution

— Reply to this email directly or view it on GitHubhttps://github.com/OpenELEC/OpenELEC.tv/issues/1258#issuecomment-8788579.

tutifrutas commented 11 years ago

ondemand is quicker to goto max speed and quicker to lower the cpu freq, it is only good for the PI. In the pi there is sdram_freq, core_freq, gpu_freq besides the cpu_freq. if it is using conservative it is maxing out the other settings while it is stepping the cpu_freq and takes longer to go back to default.