the effect of smartreflex on N900 battery usage - Page 2 - maemo.org

freemangordon | # 11 | 2012-01-16, 13:09 | Report

Originally Posted by caveman View Post

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.

I would ask you to repeat the tests with pre50 build or with my latest v49 build in KP thread, SmartReflex for frequencies above 600 in KP49(the one in devel repo) is a kind of "first iteration". In latest patch I sent to pali (and which is in KP pre50) SR should behave better for OC frequencies(hopefully

).

EDIT:
AIUI mplayer uses SW decoding, so data when DSP is involved is still missing. You should use stock player for that.

EDIT2:
Well, results are actually not so bad, for about 13.5% higher frequency we have 10% more battery drain. And higher drain seems somehow expected as playng a movie through CPU most probably keeps it awake all the time.

Last edited by freemangordon; 2012-01-16 at 13:16.

The Following 2 Users Say Thank You to freemangordon For This Useful Post:
Estel, fw190

caveman | # 12 | 2012-01-16, 13:48 | Report

Originally Posted by freemangordon View Post

I would ask you to repeat the tests with pre50 build or with my latest v49 build in KP thread, SmartReflex for frequencies above 600 in KP49(the one in devel repo) is a kind of "first iteration". In latest patch I sent to pali (and which is in KP pre50) SR should behave better for OC frequencies(hopefully

).

I will look for the latest kp49.

Originally Posted by freemangordon View Post

EDIT:
AIUI mplayer uses SW decoding, so data when DSP is involved is still missing. You should use stock player for that.

Is there a way to play a video with the stock video player using the command line?

The main assumption that was put to test was that OC would save power on high loads. In my phone it does not.

I agree that having data using the DSP would be nice, so we will know how moving the load from the MPU to the DSP impacts power usage.

Originally Posted by freemangordon View Post

EDIT2:
Well, results are actually not so bad, for about 13.5% higher frequency we have 10% more battery drain. And higher drain seems somehow expected as playng a movie through CPU most probably keeps it awake all the time.

'dsp' to 'default' is 805 to 600, or about 34% increase in frequency for a 10% power penalty, right?

The Following User Says Thank You to caveman For This Useful Post:
Estel

freemangordon | # 13 | 2012-01-16, 14:12 | Report

Originally Posted by caveman View Post

'dsp' to 'default' is 805 to 600, or about 34% increase in frequency for a 10% power penalty, right?

Right

ten chars

Rob1n | # 14 | 2012-01-16, 16:29 | Report

Originally Posted by caveman View Post

The main assumption that was put to test was that OC would save power on high loads. In my phone it does not.

OC should save power on high-load time-independent processes. If it can complete the process in a shorter time, then it can switch back to a lower power mode quicker. Playing a video is time-dependent though, so unless it can switch down for micro-seconds between frames (which may depend on the CPU governor) then it'll be running at full power for the entire time. Something like a compression job should allow the CPU to complete the task faster and switch back to low power mode quicker (providing it's not I/O bound anyway).

The Following 3 Users Say Thank You to Rob1n For This Useful Post:
Estel, fw190, woody14619

caveman | # 15 | 2012-01-17, 18:27 | Report

Originally Posted by Rob1n View Post

OC should save power on high-load time-independent processes. If it can complete the process in a shorter time, then it can switch back to a lower power mode quicker. Playing a video is time-dependent though, so unless it can switch down for micro-seconds between frames (which may depend on the CPU governor) then it'll be running at full power for the entire time. Something like a compression job should allow the CPU to complete the task faster and switch back to low power mode quicker (providing it's not I/O bound anyway).

This should be easy enough to check. I used as load the md5sum of the previous video file, looping for 9000x (so that we have a cached file in RAM). All other test variables remain unaffected.

Here are the results:
| profile | juice |
| kp49 + default | 195 | 100%
| kp49 + dsp | 221 | 113%

This seems consistent with the 'playing video' results.

So far my current belief is: the reasoning that OC saves power may be sound, but is not true.

So if you want to save power, enable SmartReflex and do not overclock.

woody14619 | # 16 | 2012-01-17, 18:57 | Report

Originally Posted by geneven View Post

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.

Uhm... It was. Titan and others did lots of such testing. It is in fact how we know under-volting is even possible, and that the MPU "sweet spot" is around 500Mhz.

Originally Posted by caveman View Post

All other test variables remain unaffected.

Here are the results:

Whoh there! Hold on a second. One quick question: How long did each test run for? And how much longer did the under-clocked test run? Also, where you writing said file to flash? If so, you're not testing MPU, you're testing flash write, since that's by far more expensive than the MPU running. And if you're not counting the extra idle time the system has after the faster version is done, it's not exactly a fair test. the whole concept of race to idle means you need to count that idle time as part of the equation.

What you would ideally do for real MPU test is run an app that pulls it's info from /dev/random and pushes it's output to /dev/null, or something like a pi generator. Then find out it's maximum run time (should be the slower clocking), and have it run several times over a set time frame. Something like this would be great:

Code:

dd -count 20000 -if=/dev/random | gzip -9 >/dev/null

Now, if you have the line above and it takes 10 second to run on stock, have it run the app every 30 seconds for about 30 minutes. Then do the same on the overclocked device, in exactly the same time frame (30 mins). The important thing here is that it should run the app the same number of times in the same time interval. And that interval has to be reasonably long enough to be a real test... a few seconds won't do. In this example it should run the app 60 times, roughly distributed, over 30 minutes.

All other things being equal, I'm willing to bet that a device clocked at 500-900 will have much better savings than one clocked at 250-600 (from my own experience). This would be the "race to idle" effect showing itself. (Btw, this test has been done several times in multiple threads with the same results: OC == better results.)

The Following 4 Users Say Thank You to woody14619 For This Useful Post:
Estel, freemangordon, fw190, nkirk

woody14619 | # 17 | 2012-01-17, 19:34 | Report

Originally Posted by Rob1n View Post

Playing a video is time-dependent though, so unless it can switch down for micro-seconds between frames (which may depend on the CPU governor) then it'll be running at full power for the entire time.

Precisely.

Now this is one important point that does need to be foot-noted on all of this: Weather OC, SR, Under-volt, and friends are going to save you battery life depends on your personal usage pattern. If you're listening to MP3s with it all day, OC is not going to help you much, where SR or UV may. If you're using it as a PS2 emulator, SR may not be as useful, though OC is probably required. If you're using it as a PDA with IM and e-mail checking, then OC may save a huge chunk where SR/UV may just be marginal.

Testing with just media playing is great, if that's your primary target. But lots of people use their N900 for lots of different tasks. Saying that OC isn't saving you much battery with your usage is fine. Saying that applies generically to everyone, with much different usage patterns is another thing entirely.

Last edited by woody14619; 2012-01-17 at 19:38.

The Following 4 Users Say Thank You to woody14619 For This Useful Post:
Estel, joerg_rw, nkirk, pelago

caveman | # 18 | 2012-01-17, 20:03 | Report

Originally Posted by

Whoh there! Hold on a second. One quick question: How long did each test run for? And how much longer did the under-clocked test run? Also, where you writing said file to flash? If so, you're not testing MPU, you're testing flash write, since that's by far more expensive than the MPU running. And if you're not counting the extra idle time the system has after the faster version is done, it's not exactly a fair test. the whole concept of race to idle means you need to count that idle time as part of the equation.

I have ran 2 types of tests. The music and video tests were 'constant time,' as they played the same files over and over. The md5sum was 'constant workload,' and it ran for a fixed number of iterations.

The constant load test was not so different from what you suggested. It was something like

Code:

for i in $(seq 1 9000); do md5sum sintel-trailer-480.mp4; done > /dev/null

I tried to md5sum /proc/kcore but it wasn't there :-(

Originally Posted by

All other things being equal, I'm willing to bet that a device clocked at 500-900 will have much better savings than one clocked at 250-600 (from my own experience).

The goal was to verify those bets with some common usage patterns. I had the same beliefs myself, but they did not hold. So far what I have seen in my device and for those particular loads was that OC may be good for speed, but does not save power. Things may be different for some other devices and/or loads, so I suggest you run some tests and post your results. The test is simple enough.

For me this is not a quest of 'oc or not oc,' as I am interested in saving battery power, and I would love to know the behavior of different workloads on power usage.

The Following 2 Users Say Thank You to caveman For This Useful Post:
Estel, nkirk

jloopvm | # 19 | 2012-01-17, 21:45 | Report

Congratulations on your work. Great improvement on the N900.

My experience with kp49 has been great.

I use DSP profile adjusting minimum clock speed to 500 MHz and maximum to 950 MHz. Always. Using less than 500 seems to cause breaks on audio playback of certain files (The Economist Podcast is one of them). The minimum frequency seems to change little the current consumption when the phone is on standby.

Battery and speed patch seem to interfere with kp49 use of smart reflex. I found I had to remove them.

Now, I get almost 24 hours of standby with skype conected on WiFi (my minimum use). Apart from eventual bursts of current comsumption (100 to 280 mA), my current keeps down between 18 and 50 mA.

I guess the greatest benefit of SR is when you are NOT using N900's features (stand by).

Great job!

The Following User Says Thank You to jloopvm For This Useful Post:
don_falcone

Remus | # 20 | 2012-01-18, 13:27 | Report

Originally Posted by jloopvm View Post

Congratulations on your work. Great improvement on the N900.

My experience with kp49 has been great.

I use DSP profile adjusting minimum clock speed to 500 MHz and maximum to 950 MHz. Always. Using less than 500 seems to cause breaks on audio playback of certain files (The Economist Podcast is one of them). The minimum frequency seems to change little the current consumption when the phone is on standby.

Battery and speed patch seem to interfere with kp49 use of smart reflex. I found I had to remove them.

Now, I get almost 24 hours of standby with skype conected on WiFi (my minimum use). Apart from eventual bursts of current comsumption (100 to 280 mA), my current keeps down between 18 and 50 mA.

I guess the greatest benefit of SR is when you are NOT using N900's features (stand by).

Great job!

Just curious, how did you conclude this?