Can apps that disable dyntick be considered bugs?
 

I have read in various threads that when running some apps, such as Xterm and Microb dyntick will not lower the' tick rate', thereby decreasing battery life when in 'lock screen and keyboard' mode.

To me that seems like a bug, but I can't find anything about this in Maemo bugzilla. Would this be a 'bug' in those specific apps or is something in the OS in need of fixing?

Re: Can apps that disable dyntick be considered bugs?
 

Well it's not disabling, it's that these tasks do thing that don't allow dyntick to take effect.

This may or may not be a bug - some applications require such behaviour (e.g. timers) while others do not (either unnecessary or could be done some other way).

In almost all cases though, when an application goes into the background, timers should be stopped, to allow battery saving behaviours to take effect.

Re: Can apps that disable dyntick be considered bugs?
 

What do you mean by 'into the background' ? Not as a background process I assume? Do you mean minimized? At any rate, If I tell my device to go into a power-saving mode I tink it is reasonable to expect that applications comply with that.

Re: Can apps that disable dyntick be considered bugs?
 

@iamthewalrus: So if you start a timer and then "lock screen and keys" what do you want it to do? Keep accurate time? or stop the timer to save power?

Re: Can apps that disable dyntick be considered bugs?
 

Well, technically you currently don't tell your device to go to power-saving mode. Device goes to power-saving mode automatically whenever possible.

I see what you mean but part of the problem is in fact lack of such explicit power-saving mode. there is offline mode, mode when screen is off, mode when touchscreen and keyboard is locked but no explicit 'please do really nothing and save power' mode.

Good example is media player, people want it to play even in offline mode, with screen, keyboard and touchscreen off. This is can of worms, random people want random set of features to work in such idle mode so there can't be one such mode.

Re: Can apps that disable dyntick be considered bugs?
 

You're right. You could say 'lock screen and keys' does exactly what it says. That that also can be used as a 'sleep' mode is more a happy coincidence. Maybe what we need is this explicit 'sleep' mode or even a real 'suspend to ram'.

I don't know enough about programming to understand how applications use this timer, but in case of the not yet existing 'sleep' mode I think we need to temporarily stop these timers or applications. Isn't there some standard for how applications should deal with power management in Linux?

Re: Can apps that disable dyntick be considered bugs?
 

The easiest solution is probably that if you minimise an app it should attempt to stop all dyntick-stopping behaviour. Do apps get a signal that the screen has been locked? If so, these apps should stop display routines/update timers anyway as the output is not being seen.

Re: Can apps that disable dyntick be considered bugs?
 

Applications with a user interface are usually event-driven and idle most of the time. Only when a user does something, an event is generated and handled by the application. Only when all applications are idle, the device can go into power-save mode.
Timers can be setup by applications to trigger actions without user input at regular intervals. Since these also run while the device is idle, they prevent the device from switching to power-save mode.
Good behaving applications never let timers be run when not needed. But many applications unfortunately do. Many applications were ported from desktop-Linux where extreme power-saving is simply not an issue.
Application programmers need to be made aware of power-efficient programming. This is relatively new.

Re: Can apps that disable dyntick be considered bugs?
 

I've noticed that when I'm in RSS and click on an article and it opens an Opera window (I'm an Opera/OS2007 person) then the browser appears to not be loading in the background if I minimise it and continue to read the RSS while waiting (that is, doing something else while waiting for the page to load doesn't really work..). Does that mean that Opera and MicroB behaves differently in this case? There's some conflict of interest here, even for the same individual.. I like the browser not to spend CPU on things while I'm not using it, on the other hand background loading would be useful now and then.

For the locked screen case I think I would like the application to be notified. In that case I would want the browser to heed it and not do anything.

Without thinking it through too much I see a couple of scenarios:
- Minimised mode: Browser should finish load the currently loading page, but stop any animations. My satellite tracking software (vaporware at the moment) will stop updating the tracking display while minimised.
- Screen locked: All updates of (the invisible) screen to stop.

Re: Can apps that disable dyntick be considered bugs?
 

Well, non-programmers may be confused by this. We are talking about microsecond precision here. And we are also talking about various parts of the device going independently into their power saving modes, not just the main CPU. In normal mode of operation even if device is (heavily) used, various bits go to power-saving mode every now and then. So there is no one power-save mode that such applications continuously prevent to enter. It is not black or white.

What matters is that applications do unnecessary work that consumes power. It is about ratio between sleeping device and active device (with microsecond precision) where 'sleeping device' consists of separate sleeping parts - CPU, wi-fi, bluetooth, audio/DSP, display, touchscreen, mmc cards, usb, ....

Once this ratio is bad enough you have dead device in few hours.

Some applications abuse CPU, some do network activity, some leave audio open, some scan mmc cards or read/write to files ...

Re: Can apps that disable dyntick be considered bugs?
 

There may technically not be a single power save 'mode', but from the users standpoint it is clear when you're done using a device and want to put it away without having to reboot it. So I wonder isn't it possible to just halt a process, no matter how good or bad the application is written?

Re: Can apps that disable dyntick be considered bugs?
 

Just to answer that very last question, without going into ramifications at all: Yes, it's possible. There's a Unix signal for that: SIGSTOP. It suspends the application until you send SIGCONT.

Re: Can apps that disable dyntick be considered bugs?
 

Yes, it is possible. You can send SIGSTOP to the process and later resume it with SIGCONT.
This basically freezes the process.

But the average user wouldn't want to do this. Maybe some (yet unwritten) suspend tool could handle this.

Re: Can apps that disable dyntick be considered bugs?
 

Yes, it works in most cases see e.g. this. In general this does not solve everything but majority of cases are solved by this. It would not solve e.g. when application leaves audio open (preventing dsp from sleeping). Also you can't stop everything, you want to leave some parts of system running. So there is the problem of determining what can be stopped like this and what not.

Re: Can apps that disable dyntick be considered bugs?
 

signal sender=:1.6 -> dest=(null destination) path=/com/nokia/mce/signal; interface=com.nokia.mce.signal; member=tklock_mode_ind
string "locked"
signal sender=:1.6 -> dest=(null destination) path=/com/nokia/mce/signal; interface=com.nokia.mce.signal; member=tklock_mode_ind
string "unlocked"

Programs using libosso may already recieve those dbus events, if not, I guess monitoring for them manually would work too.

Re: Can apps that disable dyntick be considered bugs?
 

In case of a 'suspend' mode I would think you only want to keep those processes running that you need to get out out suspend mode again.

Re: Can apps that disable dyntick be considered bugs?
 

Yes. So start xterm, run ps and tell me which are those :-) Even on freshly flashed firmware with no 3rd party application installed the list is long and it is hard to tell.

Re: Can apps that disable dyntick be considered bugs?
 

There is a 3rd party addon: n800-s2ram.

Re: Can apps that disable dyntick be considered bugs?
 

Its very easy to manage this in Bash:

^Z (CTRL+Z) does SIGTOP; fg (foreground) does SIGCONT.

(Although I just read xterm is one of the culprits...)

Re: Can apps that disable dyntick be considered bugs?
 

People usually don't start browser from xterm :-) What you can do is to call something like
It can be done from powerlaunch script when keys are locked/released.

Re: Can apps that disable dyntick be considered bugs?
 

Yes, this is heavier approach with other issues.
1. really everything is frozen so even some stuff that should be done is not done and system is mildly confused with amnesia after wakeup.
2. you need to wake up periodically each minute to ping the watchdog or system reboots. This means that your programs are periodically woken up too for short moments and can feel bad about it too (e.g. when playing sound or using network). SIGSTOP/SIGCONT may cause similar issues but at least it is not done every minute.

s2ram may indeed save more power but most people don't care if your tablet lasts 20 or 40 days in such standby mode. With clean firmware N810 lasts 30 days after fresh charge when not used at all. So it is not that bad when power management really works.

For better effect both ways can be combined (first send SIGSTOP to all suitable tasks and then do s2ram trick periodically).

Another solution for longer periods of inactivity is to implement suspend to disk (=card). Wakeup may take few seconds though. Still much better than current shutdown/boot procedure taking tenths of seconds.

Re: Can apps that disable dyntick be considered bugs?
 

30 days? I thought everyone recharged their NIT every day :)

The issue isn't only the time it requires the device to boot. The issue is also booting drains the battery life. An embedded device either doesn't boot much, or booting is quick. With the NIT's low battery life you get neither which drains the battery even more.

Say you fire up the NIT in the morning to check mail. Then you drive to work, suspend it, and after 8 hours you fire it up to check your mail again. Or you did this during your lunch break.

If you want a really high battery life while not using the device for long you'd suspend to disk. This is slower than suspend to RAM though, and on a computer it costs some time and energy to do this. You really don't want to suspend to disk every minute your laptop isn't in use, but I think for the NIT the difference is minor (especially with the SDHC kernel).

If you are using a lot of RAM suspend to RAM will use the swap to suspend to provided you have one (else it'll fail). In any case, only if you need to reboot suspend isn't an option. Else, it is almost always worth it after X minutes where X is e.g. 15, provided the suspending works correct. The ideal X is something one can researh after an implementation exists. This not only counts for laptops as well. It also counts for PCs.

Re: Can apps that disable dyntick be considered bugs?
 

All Linux palmtops I've used, indeed all palmtops, take a long while to boot (e.g. Zaurus, Psion Series 5, Newton).

Why suspend though? I can quite happily do this all week using the default dyntick+cpufreq+powering off components powersaving and still have battery life left.

As well as that, I can leave my N810 with wifi up and an ssh session running on my PC all evening (~4 hours, not doing much though, but that's like email), every night of the week and it will probably last a week.

Re: Can apps that disable dyntick be considered bugs?
 

Yes, I admit I got backup N810 which I currently don't use much. Ideal for various power management related tests. So far I managed to do only this one 'test' of keeping it unused in the drawer 3 or four times :-) Was around 30 days every time.
Not sure if you mean tablet and not sure if you mean suspend to disk or RAM (both are not part of current system) but anyway for tablet this is debatable. Tablet is more like a phone, not laptop with bad power management. It is meant to be always on always online so you can get your mail or receive Skype call anytime you wish. With no buggy application it works fine as is and lasts days while connected to wi-fi with light usage. Do you turn your phone off every X minutes where X is e.g. 15?

Re: Can apps that disable dyntick be considered bugs?
 

Suspending indeed goes against the 'always online' idea, even though my guess is large number of users don't actually use their tablets this way. Still If we assume that leaving it online is the way to go then something needs to be done about runaway processes.

How about a GUI to see which (userspace) applications have used lots of resources in a certain timeframe, and way to indicate which applications to halt (with SIGSTOP) when not using the tablet.

Re: Can apps that disable dyntick be considered bugs?
 

Well, I'm sorry, but I have a laptop at home and this device is always online when I have it at home (and soon with me, with 3G). If I wouldn't have a laptop I would use a desktop or workstation instead (actually, I do, but its almost always off, also to save costs on power which is becoming more expensive these days). I do like to wake up and see if I have e-mail based on the NIT's ambient light... but come on... its simply much easier to read e-mail on a bit bigger screen with my own favourite e-mail application with calendar support and so on.

When I leave the house I immediately don't have a connection anymore. No more WLAN. How am I always-on then? I'd need a seperate device for always-on. So, if you look at it this way, the NIT doesn't have the hardware to be always-on while on the move. If I travel, and I don't need to use the NIT, I should either close my resource hungry applications or use suspend. Heck, if I'd travel with my NIT, I wouldn't be able to use the on-board GPS because the chipset is crappy. The NIT doesn't have 3G either. It doesn't have as much storage as my Iriver H340 (with only 25 GB filled) which works several hours with Rockbox. So, IMO, or at least for me, the NIT isn't very useful as a always-on device.

Perhaps I should clearlify how I use my NIT: as a backup device in case I lost my way on the road, or if I'd need to look up something on the Internet while on the road. This doesn't happen much; so why leave the device on the whole time? I don't run many non-standard applications on the NIT either.

PowerTOP is a great application to see how many W an application uses but it requires a patched kernel.

Re: Can apps that disable dyntick be considered bugs?
 

Indeed. Ideally they'd be fixed, but I probably want a way of saying "the only non-system processes I want running when the screen is locked is Media Player, mplayer, MediaBox" (for example).

I'd envisage three lists:
* A whitelist of core system processes which should never be stopped.
* A whitelist of processes to keep running when locked/screen off
* A blacklist of processes to always stop when locking or the screen goes off after some timeout.

In fact, I remember suggesting SIGSTOP as part of Hildon Desktop and/or Maemo back in the OS2005 days :-)

There's a trickiness in measuring "lots of resources in a certain timeframe"; however some central database of processes/versions and whether they should be stopped, can be stopped or mustn't be stopped would solve a lot of those issues: the community can build it up over time.

Re: Can apps that disable dyntick be considered bugs?
 

This catch-all solution seems like a good idea considering the many ways apps can consume resources . I also like leaving it up to the user as some may actually want to let an app run even if it is resource hungry. Now we only need someoneone to er.. program it.