the effect of smartreflex on N900 battery usage
 

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

Re: the effect of smartreflex on N900 battery usage
 

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.

Re: the effect of smartreflex on N900 battery usage
 

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

Re: the effect of smartreflex on N900 battery usage
 

@ 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

Re: the effect of smartreflex on N900 battery usage
 

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

Re: the effect of smartreflex on N900 battery usage
 

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

Re: the effect of smartreflex on N900 battery usage
 

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

Re: the effect of smartreflex on N900 battery usage
 

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.

Re: the effect of smartreflex on N900 battery usage
 

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.

Re: the effect of smartreflex on N900 battery usage
 

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.

Re: the effect of smartreflex on N900 battery usage
 

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.

Re: the effect of smartreflex on N900 battery usage
 

I will look for the latest kp49.

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.

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

Re: the effect of smartreflex on N900 battery usage
 

Right :)

ten chars

Re: the effect of smartreflex on N900 battery usage
 

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

Re: the effect of smartreflex on N900 battery usage
 

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.

Re: the effect of smartreflex on N900 battery usage
 

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.

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:

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

Re: the effect of smartreflex on N900 battery usage
 

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.

Re: the effect of smartreflex on N900 battery usage
 

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
I tried to md5sum /proc/kcore but it wasn't there :-(

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.

Re: the effect of smartreflex on N900 battery usage
 

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!

Re: the effect of smartreflex on N900 battery usage
 

Just curious, how did you conclude this?

Re: the effect of smartreflex on N900 battery usage
 

Conclusions - overclock if You feel it fancy, and don't do otherwise ;) Don't expect significant power saving nor power loss (it depends on device and usage patterns, and I suspect that - most of the times - overall it equals to around 0) from both overclocking and underclocking.

/Estel

Re: the effect of smartreflex on N900 battery usage
 

Yes, and I'm telling you test #2 is flawed. You ran something that's ramping up the CPU to top speed, for a large fixed number of iterations, but neglected to account for the time involved in each. It also doesn't test the more common case of small bursts of CPU usage, ones running typically under a second.

When you ran the test above, the one running at 600Mhz obviously took longer to do than the one at 900Mhz. Say the 600Mhz test took 20 minutes to complete, while the other took 15. You're not accounting for the 5 minutes that the 900Mhz machine sat at 0% usage. You're also not comparing the low-end speeds (125/250 vs 500), since you're doing something so intense that it's kicking it up to the top speed.

OC isn't just about how fast it goes as a top speed, but how fast it goes at the first step, to complete things before it gets ramped up to full speed.

If you're doing the same thing at top speed, it's going to use about the same amount of battery. But batteries perform differently with different loads, as do their "predictors" for how much battery is "left". The life-left value you're citing is a predicted value. If you run with a heavy load, it drops rapidly, predicting you will continue to use the same load. If you then remove that load, the value will in some cases actually go up because it's averaged based on load over time.

To do a fair test, you need to set this up so it takes the same rough amount of time as well as iterations, in smaller chunks, with gaps between the work. If the test above takes 25 minutes at 250-600Mhz, then set them up with pauses between them and test the value delta after about 40 minutes from test start. Then do the same for 500-900Mhz, also testing after 40 minutes. That gives the battery prediction routines time to stabilize after the heavy load.

md5 sums are not common usage. An app that fires up, runs CPU for a short time to check for connection, run a small script to update a desktop, or refresh a widget... That's common usage. When those run for a half second every minute at 250Mhz vs a quarter of a second at 500Mhz, those fractions add up quick.

As for running tests, it's already been done. The result has been time and again that race to idle is alive and well, and that 500Mhz is the high point for performance vs power with this chipset.

In this regard, you may not see the advantage if you're doing something long term (like a huge md5 sum run over and over again very quickly in succession), or something time-based (like streaming audio). But you will see it in short-run cpu usages like those caused by background apps, waking the CPU on occasion and racing to finish before the governor kicks the CPU up to a higher frequency.

Again, this is a usage thing. If you're using your device as an MP3 player, your settings and battery life are going to be different from mine. The point here is that not all settings are right for all people, nor is claiming that one feature doesn't supply a savings just because it doesn't do so for your use pattern.

Re: the effect of smartreflex on N900 battery usage
 

Of course, Titan et al did -- I don't suppose you thought I was accusing Titan of making up scare stories against overclocking. I was talking about careful studies by those who questioned the value of overclocking.