maemo.org - Talk - ANNOUNCE: Diablo-Turbo first beta available

maemo.org - Talk (https://talk.maemo.org/index.php)

- OS2008 / Maemo 4 / Chinook - Diablo (https://talk.maemo.org/forumdisplay.php?f=29)

- - ANNOUNCE: Diablo-Turbo first beta available (https://talk.maemo.org/showthread.php?t=69740)

Re: ANNOUNCE: Diablo-Turbo first beta available

Quote:

Originally Posted by alephito (Post 948002)

Quote:

Originally Posted by n9ots (Post 947936)

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.

Re: ANNOUNCE: Diablo-Turbo first beta available

:) 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.

Re: ANNOUNCE: Diablo-Turbo first beta available

Quote:

Originally Posted by Frank Banul (Post 947534)

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.

Quote:

Originally Posted by maacruz (Post 947495)

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 :D

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

Re: ANNOUNCE: Diablo-Turbo first beta available

Quote:

Originally Posted by alephito (Post 948101)

:) 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)

Re: ANNOUNCE: Diablo-Turbo first beta available

Here I go, again :D
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).

Re: ANNOUNCE: Diablo-Turbo first beta available

Quote:

Originally Posted by andy1 (Post 947871)

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!

Re: ANNOUNCE: Diablo-Turbo first beta available

Quote:

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.

Re: ANNOUNCE: Diablo-Turbo first beta available

Quote:

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.

Quote:

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?

Re: ANNOUNCE: Diablo-Turbo first beta available

Quote:

Originally Posted by auouymous (Post 948411)

The bug is in personal launcher, so it should be solved there. We shouldn't be chasing wild gooses.

Quote:

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.

Re: ANNOUNCE: Diablo-Turbo first beta available

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...