Hi, > ext Michael Thompson wrote: >> How do we know if an application has good power usage. It wakes up only when it's doing something for you. When it _does_ things for you, it has good responsiveness and doesn't make rest of the system non-responsive. >> How do we know what the actual current consumption is? You use extra hardware for that, not software. :-) But anyway, that is not really relevant information when talking about applications. The question is not how much doing a thing consumes power, but is doing that thing really something that needs to be done. If application has to do something, then it has to. The power consumption of doing something isn't anything that application developers can affect (people at Nokia side are trying to get HW/kernel such that when something is not used, it doesn't use more power than it absolutely has to). If code doesn't need to do anything, then it shouldn't. This is the same crap people talk about in memory analysis. They want to know how much _exactly_ something is using from the whole system compared to the other applications. But that's not really a relevant question. The relevant questions are: - Is the application able to do what it needs to do? Even when user has other applications open with data he cares about? - basically how much free memory is available in the system - Is there something that can be optimized in the (memory/power/cpu) usage? - often there's also a performance/memory tradeoff If there isn't anything that you can optimize, it doesn't matter how exact number you get for the consumption. Getting a relatively good approximation helps in prioritization, but it doesn't need to be necessarily be particularly accurate. >> Does the hardware know what current is being consumed from the battery >> (and can that info be exposed in/proc or the battery applett) or is >> the battery app guessing based on the battery voltage? Igor Stoppa wrote: > There is ongoing work to provide users with graphical information about > current consumption. So the device _can_ know (fairly exactly) how much power it draws from the battery at the moment? > The idea is that when you want to measure an application, you can first > do a sort of "calibration" with a clean system in the state you are > interested (i.e. wlan on or off), then install the application to be > tested and run gain the measurement. This value changes the whole time depending on what application is doing, user's settings (wlan power, timeouts etc). How accurate average the device can get on the power it spends? >> I'm not sure that strace'ing is very ideal > > No, but some users and most developers could use it. > >> Powertop is not using such hacks and it works. Users have >> started >> complaining with dfevelopers and developers themselves have >> taken >> powerto in use. >> >> Can we run powertop or equivalent on the N800/Maemo? > > I'll let Eero answer this. The kernel needs to be re-built with CONFIG_TIMER_STATS=y but that seems to make at least the current wlan driver (binary blob) not to work correctly. The powertop package from Debian should work about as is once timer stats are provided. However, it should be noted that for a normal developer strace provides *much* better information. The problem with powertop is how you exclude the wakeups your powertop usage causes (ssh wlan wakeups etc)? You can just output the powertop data to tmpfs, but that's also very user unfriendly way to get the information. With strace you can monitor exactly what you want. If a process is not doing any syscalls (nor busylooping without syscalls which would show up immediately in "top"), it doesn't invoke anything from the kernel either, so getting information about kernel when you're interested just about what user-space processes cause, is redundant. Third tool you can use in addition to "top" and "strace" is "xresponse". It tells what screen updates are being done to the screen. Just do this in the ssh console: xresponse -w 0 -i And see all the screen updates (in X geometry format) listed with their timestamps. Xresponse and strace are available from the Maemo repositories. With Sbox you can just "kill -SIGUSR1 $(pidof Xephyr)" to request Xephyr to show which parts of its screen are updated. Note that both Xephyr and xresponse can show multiple screen updates that happen at the same time as a single rectangle. That's due to XDamage extension works, not a problem in the tools themselves. - Eero
