View Single Post
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: