caveman | # 1 | 2012-01-13, 17:51 | Report

I have been interested in the effect of kernel-power v49 on battery usage, particularly with smartreflex enabled, so I ran a few tests to have a rough ideia of its impact.

The system runs CSSU testing, and the test setup was:
* install mplayer and i2c-tools
* enable offline mode
* mute the volume
* turn off the screen just before the test (see below)
The rationale is to control the test scenario and minimize the power consumption of other N900 components, so the test results can better measure the MPU power consumption.

For this test I have chosen playing mp3 files as 'load'.

The test is as follows:
1. read current battery status (with i2cget)
2. play some music files (with mplayer)
3. read current battery status again
4. calculate the diff of 1 and 3
The atual shell code I used in the test is:
The /bin/su is required because mplayer bombs when run as root. During the sleep I turned the screen off.

Warning: i2c-tools is very low level and may damage the hw if used incorrectly.

In my test I used a ~5min mp3 with a 5x loop, which gives about 25-30min of playing.

The results are the following.

| load | nokia kernel | kp49 default | kp49 dsp | kp49 starving |
| mp3 | 165 | 145 | 145 | 154 |
| mp3 | 100% | 88% | 88% | 93% |

Each test has been run at least 3 times and the lower number is presented in the table.

Conclusions for my device with load 'playing mp3,':
* the most power efficient case is kp49 with smartreflex enabled;
* for my device with load 'playing mp3,' overclocking does not save power (the saying goes that overclocking may improve battery usage since code runs faster and processor idles sooner);
* smartreflex is more power efficient than undervolting the processor.

Congratulations to the KP team and, in particular, to those working on SR!

It would be interesting to see more results with other N900s and other loads.

history:
* check post #2 for relevant considerations
* added numbers for 'starving' profile

---

Last edited by caveman; 2012-01-15 at 15:59. Reason: updated based on comments

freemangordon | # 2 | 2012-01-13, 18:05 | Report

You have to add "on this particular device" too, as SR is device dependent. And you don't see any battery savings with overclocking as mp3 is not MPU intensive, playng such usualy requires frequencies between 250 and 500. Try something which is more CPU intensive. And you can do the same measurements with DSP involved (i.e. playing a video).

Otherwise big thanks for the research.

freemangordon | # 3 | 2012-01-14, 07:50 | Report

@Karam - here is your way to prove whether battery patch reduces battery usage.

nkirk | # 4 | 2012-01-14, 19:43 | Report

@ caveman,

Would you have time to do another run with a custom sane undervolt profile to compare the benifis of having SR on to do the undervolting on the fly and to have the device permanatly undervolted using a custom profile.

for starters you could create a new profile with +2 noches in voltage values for each frequency vs the values calculated by SR.( On your device of course)

and yes, as freemangodan suggested would highly appreciate if you can use a video or something of that sort to create a higher mpu load.

/nkirk

Estel | # 5 | 2012-01-14, 20:24 | Report

Also, consider the fact that overclocking lower limit (i.e. setting 500-900) result in power savings during standby - as N900 finish it's "idle tasks" quicker, sitting in 0mhz longer every second (as compared to switching into 125 or 250 mhz lower limit while idle - see batterypatch or other voodoo that actually use power to monitor dbus events (idle, locked etc)

/Estel

Estel | # 6 | 2012-01-14, 20:25 | Report

Also, consider the fact that overclocking lower limit (i.e. setting 500-900) result in power savings during standby - as N900 finish it's "idle tasks" quicker, sitting in 0mhz longer every second (as compared to switching into 125 or 250 mhz lower limit while idle - see batterypatch or other voodoo that actually use power to monitor dbus events (idle, locked etc)

/Estel

caveman | # 7 | 2012-01-15, 16:00 | Report

Good idea! Based on your suggestion I added numbers taken with the starving profile.

caveman | # 8 | 2012-01-15, 16:07 | Report

You are right. I will run a few tests using video as load to compare the numbers, in particular to test if overclocking saves power.

caveman | # 9 | 2012-01-16, 11:48 | Report

I ran a few tests using video as load, and the results were startling if not unexpected.

All tests used the same procedured outlined above, but I used a video file as load, instead of a music file. For those interested in running the same test, the video was the mp4 trailer @ 480 of sintel, from http://www.sintel.org/. It runs for about 50s, and I used a 10x loop.

The results follow:
| profile | juice | % |
| default | 245 | 100% |
| dsp | 270 | 110% |
| starving | 245 | 100% |

So for my phone, OC does not save power, at least playing video with mplayer.

geneven | # 10 | 2012-01-16, 12:57 | Report

Interesting, though I'm not convinced the full story has yet been told.

Just imagine how different things would have been if such careful investigation had been undertaken when overclocking was first proposed; instead the powers that be chose to focus on bogus and hysterical scare stories.