Page 2 of 3 1 2 3
Reply
Thread Tools
freemangordon is offline freemangordon
2012-01-16 , 13:09
Posts: 3,074 | Thanked: 12,964 times | Joined on Mar 2010 @ Sofia,Bulgaria
#11
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:
caveman is offline caveman
2012-01-16 , 13:48
Posts: 191 | Thanked: 415 times | Joined on Jan 2012
#12
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:
freemangordon is offline freemangordon
2012-01-16 , 14:12
Posts: 3,074 | Thanked: 12,964 times | Joined on Mar 2010 @ Sofia,Bulgaria
#13
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 is offline Rob1n
2012-01-16 , 16:29
Posts: 3,617 | Thanked: 2,412 times | Joined on Nov 2009 @ Cambridge, UK
#14
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:
caveman is offline caveman
2012-01-17 , 18:27
Posts: 191 | Thanked: 415 times | Joined on Jan 2012
#15
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's Avatar
woody14619 is offline woody14619
2012-01-17 , 18:57
Posts: 1,455 | Thanked: 3,309 times | Joined on Dec 2009 @ Rochester, NY
#16
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:
woody14619's Avatar
woody14619 is offline woody14619
2012-01-17 , 19:34
Posts: 1,455 | Thanked: 3,309 times | Joined on Dec 2009 @ Rochester, NY
#17
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:
caveman is offline caveman
2012-01-17 , 20:03
Posts: 191 | Thanked: 415 times | Joined on Jan 2012
#18
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 :-(

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:
jloopvm is offline jloopvm
2012-01-17 , 21:45
Posts: 3 | Thanked: 2 times | Joined on Nov 2011
#19
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:
Remus's Avatar
Remus is offline Remus
2012-01-18 , 13:27
Posts: 37 | Thanked: 18 times | Joined on Jun 2011 @ /dev/null
#20
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?
 
Reply
Page 2 of 3 1 2 3

« Previous Thread | Next Thread »

 
Forum Jump


All times are GMT. The time now is 04:01.

Contact Us - Home - Archive - Top