User:Bjordan/Chris Power MGMT: Difference between revisions

From OLPC
Jump to navigation Jump to search
(New page: Control of power --> transmitter? vs. using repeater)
 
No edit summary
 
(12 intermediate revisions by the same user not shown)
Line 1: Line 1:
Control of power --> transmitter? vs. using repeater
Control of power --> transmitter? vs. using repeater

OHM - "Open Hardware Manager" by [http://blogs.gnome.org/hughsie/ Richard Hughes]

Useful debugging tools for power management:
<pre>
ohmd --verbose --no-daemon
lsohm # ohm's ideas of what state things are in
lshal # all things hal knows about status of battery, lid, etc
lshal --monitor # realtime, HW events broadcasted to ohm
</pre>

Wakeup events: (all policy decisions go through ohm)
* Suspend mode - in Joyride
* Sleep mode - in Joyride
** Wakeup doesn't work well in 703

Idleness detection: (don't want to turn off during an update)
* Mouse/keyboard idle for 60s?
* CPU also idle? # might be doing compile
* Has dbus signal inhibited suspend? or /etc/ohm/inhibit-idle-suspend
* Have tty1 or tty2 been used recently? (printing to or typing to)
* Are audio/camera devices in use? # Not implemented. Record, distance.
* DISTANCE: CHIRP ... idle for 10s ... CHIRP, etc. Not necessarily idle.

In linux:
[http://www.cpuidle.de/ CPU-idle] - different states a CPU can be in

Power breakdown: 703
* RAM 700mW DCON 200mW EC 100mW LCD 300mW CPU 1W-3W Backlight
* Maybe make a graph of progress?

[[User:Femslade|Francesca]]: Mesh/antenna off?
* me: We could collect some data of frequency of checks in order to catch the most mesh networks?

Joe: Hibernation mode?
* Chris: waking up, what hardware will there be?
* Chris: disc space tradeoff makes it hard to hibernate

Next step:
* Better idleness detection
* Faster

[[User:DanielDrake|Daniel]]: in wireless, power-saving modes in AP
* If you have AP, large schools have APs
* Chris: OLPC supports that mode
* We may not be doing this, follow up

[[Michael_Stone|Michael]] - What needs to be done? How can we help?
* Activities doing a good job vs. bad job of supporting power management
* Look at top - CPU usage
* Look at vmstat (how many context switches are happening?)
* Timer list using [http://www.lesswatts.org/projects/powertop/ powertop] [http://en.wikipedia.org/wiki/PowerTOP wikipedia]
** Needs dynamic ticks ext on kernel
** /proc/timer_list and /proc/timer_stats
** Could be thrown into [[Tinderbox_Testing|tinderbox]]
** Provide powertop in joyride and/or a GUI for powertop
* Pie menu in main screen as memory usage by each activity
** Also power usage pie
*** Accumulated power register
*** Modify Sugar to collect power usage data
**** Chat with Scott on how to get data on power usage

What other data can activities be providing? Crashes, errors, etc.

Dynamic heuristic gathering / development
* Activity specific?

Pie menu is nice because it shows all users how much power is being used... without Chris having to yell at developers

Even when off -- [[Embedded_controller|embedded controller]] sits there and waits for power button to be turned on

Why is 708 not waking up on keyboard presses?
* Lid open -- error, screen on, then back off

[[Power_Management]]

Chris has [http://www.math.umbc.edu/~rouben/beamer/ Beamer] PDF

Latest revision as of 16:09, 23 June 2008

Control of power --> transmitter? vs. using repeater

OHM - "Open Hardware Manager" by Richard Hughes

Useful debugging tools for power management:

ohmd --verbose --no-daemon
lsohm # ohm's ideas of what state things are in
lshal # all things hal knows about status of battery, lid, etc
lshal --monitor # realtime, HW events broadcasted to ohm

Wakeup events: (all policy decisions go through ohm)

  • Suspend mode - in Joyride
  • Sleep mode - in Joyride
    • Wakeup doesn't work well in 703

Idleness detection: (don't want to turn off during an update)

  • Mouse/keyboard idle for 60s?
  • CPU also idle? # might be doing compile
  • Has dbus signal inhibited suspend? or /etc/ohm/inhibit-idle-suspend
  • Have tty1 or tty2 been used recently? (printing to or typing to)
  • Are audio/camera devices in use? # Not implemented. Record, distance.
  • DISTANCE: CHIRP ... idle for 10s ... CHIRP, etc. Not necessarily idle.

In linux: CPU-idle - different states a CPU can be in

Power breakdown: 703

  • RAM 700mW DCON 200mW EC 100mW LCD 300mW CPU 1W-3W Backlight
  • Maybe make a graph of progress?

Francesca: Mesh/antenna off?

  • me: We could collect some data of frequency of checks in order to catch the most mesh networks?

Joe: Hibernation mode?

  • Chris: waking up, what hardware will there be?
  • Chris: disc space tradeoff makes it hard to hibernate

Next step:

  • Better idleness detection
  • Faster

Daniel: in wireless, power-saving modes in AP

  • If you have AP, large schools have APs
  • Chris: OLPC supports that mode
  • We may not be doing this, follow up

Michael - What needs to be done? How can we help?

  • Activities doing a good job vs. bad job of supporting power management
  • Look at top - CPU usage
  • Look at vmstat (how many context switches are happening?)
  • Timer list using powertop wikipedia
    • Needs dynamic ticks ext on kernel
    • /proc/timer_list and /proc/timer_stats
    • Could be thrown into tinderbox
    • Provide powertop in joyride and/or a GUI for powertop
  • Pie menu in main screen as memory usage by each activity
    • Also power usage pie
      • Accumulated power register
      • Modify Sugar to collect power usage data
        • Chat with Scott on how to get data on power usage

What other data can activities be providing? Crashes, errors, etc.

Dynamic heuristic gathering / development

  • Activity specific?

Pie menu is nice because it shows all users how much power is being used... without Chris having to yell at developers

Even when off -- embedded controller sits there and waits for power button to be turned on

Why is 708 not waking up on keyboard presses?

  • Lid open -- error, screen on, then back off

Power_Management

Chris has Beamer PDF