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

Quote:

Originally Posted by caveman (Post 1152011)

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.

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.

Quote:

Originally Posted by caveman (Post 1152011)

The goal was to verify those bets with some common usage patterns.

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.