Page 8 of 62 « First 67 8 91018 Last »
Reply
Thread Tools
maacruz is offline maacruz
2011-02-16 , 15:25
Posts: 1,101 | Thanked: 1,184 times | Joined on Aug 2008 @ Spain
#71
Originally Posted by alephito View Post
Originally Posted by n9ots View Post
This happens to me occasionally (although not since upgrading to DT kernel and junk).
I suspect it has something to do with the launch bar applet, as the only programs that launch as you describe are those available on my launcher.
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.
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.
 
alephito is offline alephito
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.
 
maacruz is offline maacruz
2011-02-16 , 16:35
Posts: 1,101 | Thanked: 1,184 times | Joined on Aug 2008 @ Spain
#73
Originally Posted by Frank Banul View Post
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 View Post
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.
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.
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
Lock and switch off the screen (I have it configured to switch off in 0 seconds).
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
 

The Following 6 Users Say Thank You to maacruz For This Useful Post:
maacruz is offline maacruz
2011-02-16 , 20:23
Posts: 1,101 | Thanked: 1,184 times | Joined on Aug 2008 @ Spain
#74
Originally Posted by alephito View Post
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.
Mmm, looks like you may have installed the osso-software-version-rx44 package from Diablo instead Community SSU.
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:
maacruz is offline maacruz
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.
 
maacruz is offline maacruz
2011-02-16 , 20:45
Posts: 1,101 | Thanked: 1,184 times | Joined on Aug 2008 @ Spain
#76
Originally Posted by andy1 View Post
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.
And you have a N800! Cool!
 
Kroll is offline Kroll
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.
Same to me.
 
auouymous is offline auouymous
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.
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.

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)
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?
 
maacruz is offline maacruz
2011-02-16 , 22:22
Posts: 1,101 | Thanked: 1,184 times | Joined on Aug 2008 @ Spain
#79
Originally Posted by auouymous View Post
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.
The bug is in personal launcher, so it should be solved there. We shouldn't be chasing wild gooses.

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?
It is 400/133
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
 
cstryon is offline cstryon
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.
 
Reply
Page 8 of 62 « First 67 8 91018 Last »

Tags
chinook, diablo, new life, os2008

« Previous Thread | Next Thread »

 
Forum Jump


All times are GMT. The time now is 18:55.

Contact Us - Home - Archive - Top