Active Topics
-
Is there a section to talk about Java ME? Apps, etc. (5)
to General by teroyk - 23 hrs, 25 mins ago -
Extra softwares in Sailfish using CLI, repositories, etc (118)
to SailfishOS by nieldk - 1 day, 4 hrs ago -
Paths (0)
to Maemo 7 / Leste by teroyk - 2 days, 2 hrs ago - more...
|
2012-01-16
, 13:48
|
|
Posts: 191 |
Thanked: 415 times |
Joined on Jan 2012
|
#12
|
Originally Posted by freemangordon
I will look for the latest kp49.
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).
Originally Posted by freemangordon
Is there a way to play a video with the stock video player using the command line?
EDIT:
AIUI mplayer uses SW decoding, so data when DSP is involved is still missing. You should use stock player for that.
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
'dsp' to 'default' is 805 to 600, or about 34% increase in frequency for a 10% power penalty, right?
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.
| The Following User Says Thank You to caveman For This Useful Post: | ||
|
|
2012-01-16
, 14:12
|
|
Posts: 3,074 |
Thanked: 12,960 times |
Joined on Mar 2010
@ Sofia,Bulgaria
|
#13
|
Originally Posted by caveman
Right
'dsp' to 'default' is 805 to 600, or about 34% increase in frequency for a 10% power penalty, right?
ten chars
|
|
2012-01-16
, 16:29
|
|
Posts: 3,617 |
Thanked: 2,412 times |
Joined on Nov 2009
@ Cambridge, UK
|
#14
|
Originally Posted by caveman
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 main assumption that was put to test was that OC would save power on high loads. In my phone it does not.
| The Following 3 Users Say Thank You to Rob1n For This Useful Post: | ||
|
|
2012-01-17
, 18:27
|
|
Posts: 191 |
Thanked: 415 times |
Joined on Jan 2012
|
#15
|
Originally Posted by Rob1n
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.
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).
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.
 |
|
2012-01-17
, 18:57
|
|
Posts: 1,455 |
Thanked: 3,309 times |
Joined on Dec 2009
@ Rochester, NY
|
#16
|
Originally Posted by geneven
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.
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.
Originally Posted by caveman
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.
All other test variables remain unaffected.
Here are the results:
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
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: | ||
|
|
2012-01-17
, 19:34
|
|
Posts: 1,455 |
Thanked: 3,309 times |
Joined on Dec 2009
@ Rochester, NY
|
#17
|
Originally Posted by Rob1n
Precisely.
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.
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.
|
|
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.
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
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).
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.
|
|
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!
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: | ||
 |
|
2012-01-18
, 13:27
|
|
Posts: 37 |
Thanked: 18 times |
Joined on Jun 2011
@ /dev/null
|
#20
|
Originally Posted by jloopvm
Just curious, how did you conclude this?
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!
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.