|
2010-04-11
, 12:12
|
Posts: 946 |
Thanked: 1,650 times |
Joined on Oct 2009
@ Germany
|
#2262
|
Cheers for that. Would be interesting with the new governor. For me battery life is more important that slightly sluggishness till the governor finds the right frequency rather than jumping to the max straight away. So what is the new governor policy?
Also, do you know if power bias does anything with the new governor?
echo conservative > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
echo 1 > /sys/devices/system/cpu/cpu0/cpufreq/ondemand/ignore_nice_load
echo 124999 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq
The Following User Says Thank You to titan For This Useful Post: | ||
|
2010-04-11
, 12:19
|
Posts: 171 |
Thanked: 114 times |
Joined on Feb 2010
|
#2263
|
echo conservative > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
|
2010-04-11
, 12:29
|
|
Posts: 290 |
Thanked: 165 times |
Joined on Sep 2009
|
#2264
|
|
2010-04-11
, 12:32
|
Posts: 171 |
Thanked: 114 times |
Joined on Feb 2010
|
#2265
|
it's better power wise as well; it's a bit complex to explain, but
it's better to execute the code you need to execute at full speed, and
then really quickly go idle, than it is to execute at a much lower speed.
Maybe a simple example (I plucked these numbers out of the air, they
don't represent any real cpu that exists) will help:
Say you have a cpu that consumes 40 Watts at full speed, and 30 Watts
at half speed, and 4 Watts when idle.
You have something to do, lets say mp3 decoding of 1 second of audio,
and that takes a full second at half speed, and one second at full speed.
At full speed decode + idle, that is half a second at 40 watts (20
Joules) and half a second at 4 Watts (2 Joules); total is 22 Joules.
At half speed decode, that is a full second at 30 Watts, so 30 Joules.
So, what ondemand does would cost 22 Joules, while a "hit the exact
frequency" governer would cost you 30 Joules.....
|
2010-04-11
, 12:47
|
Posts: 946 |
Thanked: 1,650 times |
Joined on Oct 2009
@ Germany
|
#2266
|
Now i am back to the latest lv titan kernel. and still my sim card is detected.
But somehow this seems to be related, it seems that when overclocking or undervolting (this really triggered my sim card problems) did result in my problem that i did have now and then was way more visible with the ULV or LV kernels of titan.
|
2010-04-11
, 12:49
|
Posts: 946 |
Thanked: 1,650 times |
Joined on Oct 2009
@ Germany
|
#2267
|
So the only difference between the old kernel and this one is that you have made this change permanent and added PPTP support to the kernel? Sorry, am just debating whether to upgrade the kernel as I am running the [125,850] test with your old kernel as well to maximise battery life, so just trying to understand exactly what will I gain by upgrading the kernel.
|
2010-04-11
, 12:52
|
Posts: 946 |
Thanked: 1,650 times |
Joined on Oct 2009
@ Germany
|
#2268
|
Now I'm running a long term test with the ULV kernel with range [125,850].
This should be the best tradeoff between speed, power saving and safety.
850 runs with the same voltage as the stock 500 setting, which is recommended by TI.
For the 125MHz I also set
after phone calls I enterCode:echo 1 > /sys/devices/system/cpu/cpu0/cpufreq/ondemand/ignore_nice_load
Code:echo 124999 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq
The Following User Says Thank You to titan For This Useful Post: | ||
|
2010-04-11
, 12:52
|
|
Posts: 290 |
Thanked: 165 times |
Joined on Sep 2009
|
#2269
|
it could have been related to the invalid 800MHz frequency we had
or that your SIM is quite old (AFAIK older SIMs have a higher operating voltage?).
|
2010-04-11
, 12:54
|
Posts: 946 |
Thanked: 1,650 times |
Joined on Oct 2009
@ Germany
|
#2270
|
|
BTW. Already updated to maemo21 kernel. No problems so far