Final Report for Project 94, Power Management On DICE Desktops

Hours worked on Project 94

Q2 8
Q3 104
Q4 77

Q1 142
Q2 105
Q3 58
Q4 4

Total hours 498, or an amazing 14+ weeks.


This project swallowed up an immense amount of time and didn't end up delivering all the benefits hoped for. However, it did achieve something solid in the end: we now have a very flexible and I think fairly robust piece of software which is proving useful for controlling sleep on the new student lab machines. With some extensions, and with better underlying sleep support from the OS, it could still be much more widely useful on DICE desktops across the School.

The basic problem was that the investigation project (devproj 34) discovered what was possible from Linux power management but didn't expose its instability. That only became obvious after developing the sleep component and running it for longer periods on test machines. The instability is different on each model of hardware, and also seems to differ every few months with OS software updates, so the temptation to run endless rounds of tests and to adjust the software's settings back and forth to try to get round the problems discovered was at times overwhelming.

With hindsight it might have been sensible to terminate the project once the instability of the underlying OS support for power management was discovered. However I'm glad that that didn't happen, as we now have a flexible and reliable piece of software which will be well placed to take advantage of any improvements in power management support from the OS and hardware. If the project had been terminated when sleep on Dells started to run into the sand, we'd probably have ended up with half a software solution which would subsequently have been ignored or binned.

Future Developments

  • Wake on mouse or keyboard activity. This is the expected way to wake a sleeping machine so it's worth investigating as an MPU mini-project.
  • A user-level command to control sleep policy was asked for. A simple "inhibit sleep" command could be provided with a few minutes' work, but this is perhaps unnecessary while simply keeping an X session going is enough to inhibit sleep? A more comprehensive user control of sleep policy could perhaps be delivered later with the use of PolicyKit when that becomes available on DICE.
  • Remote wake-ups using Wake On Lan would be desirable for office machines, together with a cosigned web page which could be used to request wake-ups. This could be looked at with perhaps not too much effort and will hopefully be tackled as a mini-project before too long.
  • I'd like to tie lcfg-sleep in to DeviceKit when that becomes available on DICE. This would have two potential benefits:
    1. The hardware quirks information is currently delivered on SL5 DICE by a version of HAL which is several years out of date. Even the updates on the HAL site seem not to be correct for our systems so I had to discover each model's hardware quirks for myself and specify them explicitly in lcfg-sleep resources. DeviceKit will replace the HAL quirks information with its own hardware information system. If we were able to tie into this then adjusting lcfg-sleep for new OS versions and for new models would be as simple as updating the DeviceKit package(s).
    2. It didn't seem possible to tie in lcfg-sleep with gnome-power-manager and thus query it to find out the idleness of logged in GNOME user sessions - so currently lcfg-sleep doesn't dare sleep machines at all when a user session is in progress. The LCFG component would have been limited to communicating with the DBUS system bus, whereas gnome-power-manager uses the per-user session bus which system software doesn't have access to. (Perhaps there is a way to communicate between session and system DBUS buses, but by this time the project was in a fairly late stage and there wasn't time to go into it in any great depth.) The other benefit which DeviceKit would bring would be that it replaces a lot of gnome-power-manager functionality with its own power management functionality and it'll communicate on the DBUS system bus. We could potentially get lcfg-sleep communicating easily with the system's own power management software, both to get idleness information and also perhaps to use it to initiate sleep (as that's currently done in a crude low level way).

-- ChrisCooke - 19 Nov 2009

Topic revision: r1 - 19 Nov 2009 - 13:09:47 - ChrisCooke
This site is powered by the TWiki collaboration platformCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback
This Wiki uses Cookies