Active Topics
-
Longtime users: What device(s) are you using today? (52)
to General by Wikiwide - 1 day, 7 hrs ago -
Registering (1)
to General by Halftux - 1 day, 21 hrs ago -
Applications Wishlist (55)
to Maemo 7 / Leste by sixwheeledbeast - 3 days ago -
Error after installing Leste on sdcard (2)
to Maemo 7 / Leste by insanelysexy - 5 days ago -
Using LM2596 DC-DC for N900 (7)
to General by insanelysexy - 6 days, 16 hrs ago - more...
maacruz |
2011-02-16
, 15:25
|
|
Posts: 1,101 |
Thanked: 1,184 times |
Joined on Aug 2008
@ Spain
|
#71
|
Originally Posted by alephito
I've been suffering this problem since I installed the launch bar applet, a loooooooong looooooooong ago, although it hasn't happened lately, may be since I started the DT beta.
|
|
2011-02-16
, 16:11
|
|
Posts: 674 |
Thanked: 191 times |
Joined on Mar 2008
@ Buenos Aires, Argentina
|
#72
|
Lucky you. I have never had that bug until now. But I can live with it.What about the other "problem"? I mean the "broken" Community SSU update.
Thanks.
|
|
2011-02-16
, 16:35
|
|
Posts: 1,101 |
Thanked: 1,184 times |
Joined on Aug 2008
@ Spain
|
#73
|
Originally Posted by Frank Banul
FWIW, I recall but can't find the relevant post that the 400/133 mode may be lower power consumption than 333/266 because the DSP does not idle where the ARM does. At one point, I had a 400/133 kernel loaded and don't recall a change in battery life, but that's just a general impression.
Originally Posted by maacruz
I implemented this idea and today did some limited testing to measure the battery consumption while playing music under the different possible states using the dsp.
Actually, looking at this, I have an idea. The original op_dsp patch limits the op states to 0 and 1, while the Diablo kernel sets the op state to 1. If we allow more op states with the dsp active, we can get significant battery gains by choosing state 2, or even 3 if it works.
Testing protocol:
Start with battery at 99%, should not drop under 75%
Set op state. Start playing music (128 kbps mp3, easy music) using osso-mediaplayer. No other programs running.
Start the measuring script:
Code:
cat /sys/devices/system/cpu/cpu0/cpufreq/stats/time_in_state; battery_status; sleep 900; cat /sys/devices/system/cpu/cpu0/cpufreq/stats/time_in_state; battery_status
Wait 15 min, then unlock the device, stop the music and take note of the values.
Do it again with other op state. First I alternated op 0 and 1, 3 measurements each. Then, charged the battery and repeated the procedure with op 1 and 2, 2 measurements each.
Results:
After the first 6 measurements, I realized the battery meter accuracy was no better than 0.4 %, so the error was in the 20% range. 15 minutes is not long enough, for good measurements it would need 1 hour to keep the error under 5%, but since I already had 6 measurements I continued anyway with the op=1 and op=2 states.
Later, for completion, I did a run of mplayer (bare mplayer in other xterm).
This is how much the battery dropped in each state in 15 min:
0 (400/133) -> 2.8 % (11.2%/hour)
1 (330/220) -> 2.4 % (9.6%/hour)
2 (266/177) -> 2.0 % (8.0%/hour)
3 (165/110) -> 1.6 % (5.6%/hour)
Later:
mplayer (400/0) -> 3.2 % (12.8%/hour)
Nothing like hard data
Conclusion:
For just music playing, op=3 is great, doubling battery life. Of course, the device struggles trying to play videos. Also tryed doing some other activity and it is usable, but slow.
Playing music with mplayer is really bad for the battery.
Someone who still runs the diablo/ssu kernel should do the same measurement (to the only available op), to finally dispel any doubt about battery consumption.
EDIT: Played same music during 172 min through speakers at maximum volume (they suck more power than earbuds), at op=3, battery went from 92.4% to 73.2%. That means 6.7%/hour
EDIT2: One hour measurement at op=1 (default value), using earbuds, battery went from 98.2 to 88.1, that is 10.1%/hour
Last edited by maacruz; 2011-02-17 at 12:14. Reason: It is 400/133, not 400/166
|
|
2011-02-16
, 20:23
|
|
Posts: 1,101 |
Thanked: 1,184 times |
Joined on Aug 2008
@ Spain
|
#74
|
Originally Posted by alephito
Mmm, looks like you may have installed the osso-software-version-rx44 package from Diablo instead Community SSU.
What about the other "problem"? I mean the "broken" Community SSU update.
Thanks.
Check what release you have with "dpkg -l osso-software-version-rx44"
It should be 1:5.2010.33-1 (stable) or 1:5.2010.32-3 (testing)
| The Following User Says Thank You to maacruz For This Useful Post: | ||
|
|
2011-02-16
, 20:26
|
|
Posts: 1,101 |
Thanked: 1,184 times |
Joined on Aug 2008
@ Spain
|
#75
|
Here I go, again
New test kernel: https://garage.maemo.org/frs/download.php/9344/zImage
Changes: allow all 4 op states in op_dsp. op_dsp=3 -> 50% more battery life playing music (wrt default op_dsp=1).
Last edited by maacruz; 2011-02-16 at 20:43.
New test kernel: https://garage.maemo.org/frs/download.php/9344/zImage
Changes: allow all 4 op states in op_dsp. op_dsp=3 -> 50% more battery life playing music (wrt default op_dsp=1).
Last edited by maacruz; 2011-02-16 at 20:43.
|
|
2011-02-16
, 20:45
|
|
Posts: 1,101 |
Thanked: 1,184 times |
Joined on Aug 2008
@ Spain
|
#76
|
Originally Posted by andy1
And you have a N800! Cool!
I havent tried the new kernel yet but I did get the "TSC2301: Pen down data with no irq" on the dmesg now after drawing for quite a while so it seems the polling does catch some data.
|
|
2011-02-16
, 21:09
|
|
Posts: 637 |
Thanked: 445 times |
Joined on Dec 2009
@ Kaliningrad, Russia
|
#77
|
Yes, that is true: the applications that start automatically are in my Personal Launcher. But in my case this behavior started with the installation of this beta.
|
|
2011-02-16
, 22:10
|
|
Posts: 875 |
Thanked: 918 times |
Joined on Sep 2010
|
#78
|
Yes, that is true: the applications that start automatically are in my Personal Launcher. But in my case this behavior started with the installation of this beta.
0 (400/165) -> 2.8 % (11.2%/hour)
1 (333/266) -> 2.4 % (9.6%/hour)
2 (266/177) -> 2.0 % (8.0%/hour)
3 (165/110) -> 1.6 % (5.6%/hour)
|
|
2011-02-16
, 22:22
|
|
Posts: 1,101 |
Thanked: 1,184 times |
Joined on Aug 2008
@ Spain
|
#79
|
Originally Posted by auouymous
The bug is in personal launcher, so it should be solved there. We shouldn't be chasing wild gooses.
Could the gconf/dbus fixes have broken personal launcher? Maybe try reverting them back to old versions and see if problem goes away. Maybe compile a DT kernel without touchscreen patch and let them them test it with personal launcher.
Is it 400/133 or 400/165? The governor doesn't work when dsp is enabled, right? And changing op_dsp locks the frequency of both cpu and dsp?
The governor does not work when dsp is enabled, op state remains constant.
Changing op_dsp sets the frequency that both cpu and dsp will have when dsp is active. op_dsp can't be changed when the dsp is active.
Last edited by maacruz; 2011-02-17 at 08:03. Reason: It is 400/133
|
|
2011-02-16
, 22:42
|
|
Posts: 206 |
Thanked: 46 times |
Joined on Mar 2010
|
#80
|
Does Diablo turbo apply the microb tweaks? If not, will it?
Also, I don't understand what the zimage is or how to use it...
Last edited by cstryon; 2011-02-16 at 22:47.
Also, I don't understand what the zimage is or how to use it...
Last edited by cstryon; 2011-02-16 at 22:47.
