Hi,
ext Michael Thompson wrote:
> On 17/08/07, Eero Tamminen <eero.tamminen at nokia.com> wrote:
>> ext Frantisek Dufka wrote:
>>> True. But still seeing power consumption could help and having actual
>>> current drawn from battery somewhere in /proc would be very useful in
>>> many situations.
>>>
>>> <snip>
>>> These were just examples and some of them may not be good but you should
>>> still see the point.
>> Yes, they are good points. Better tools are always needed.
>>
>> I'm just frustrated that people don't use the tools that
>> are already available, both on desktop[1] and for the device.
>> Even with the currency consumption meter you would still need top &
>> strace to find out which process actually consumes the power.
>
> So it turns out claws is doing a gettimeofday poll every 10 seconds, so
> you're right the strace was useful, but it's hard to quantify the affect of
> this polling and whether it's significant enough to warrant the developers
> fixing.
10 sec interval is not that bad. (LinuxThreads thread manager polls
at 8 sec interval in the devices i.e. all apps using threads poll in
the device, NPTL will fix that, but requires a new toolchain)
If Claws would be using network at that interval or e.g. writing to
Flash, then it would definitely be bad. Also if it does that polling
when it's not visible (and updates screen?) when it's not visible, that
would also be bad.
Because you can have multiple processes running at the same time, and
the device doesn't have anything that would sync these wakeups, it would
be better that applications don't do extra wakeups.
As a rule of thumb, if something wakes up more often than once every
1-2 secs, that's definitely something that has to be fixed. But
basically I consider anything doing wakeups on its own broken,
the wakeups should be event based, not timer based[1]. E.g. for
monitoring files there's inotify (or earlier dnotify) and wrapper
for that offered by gnome-vfs.
[1] Something like clock is exception, but it wakes at ~1 min interval.
Things like CPU meters could have dynamic wakeups, if nothing
happens wake up (to check CPU state) less often (once every 5
secs?), and increase the frequency when CPU is busy (to once
a sec?). Unfortunately there's no event to tell that CPU usage
changed :-)
> The power consumption of applications in the foreground should also be good
> as users can set the keyboard lock with an application in the foreground.
If application doesn't get user input, it shouldn't have anything to do.
Applications should only react to events they receive.
- Eero
