Opened 9 years ago

Last modified 20 months ago

#5457 new defect

Should OHM save to a logfile?

Reported by: cjb Owned by: cjb
Priority: high Milestone:
Component: power manager (OHM) Version:
Keywords: power Cc: cscott
Blocked By: Blocking:
Deployments affected: Action Needed:
Verified: no

Description (last modified by jg)

OHM could record the following data:

  • Timestamp of each idle suspend
  • Timestamp of each resume
  • Activity running at suspend-time

This would help me work out how to tune our idleness suspend timeouts. I'd need a way to get the logfiles back to me, somehow, and do log rotation etc.

Change History (9)

comment:1 Changed 9 years ago by cscott

Well, the obvious answer to the latter questions is 'use syslog' -- we already include logrotate, etc.

Richard has asked for similar log collection. If you provide a script in, say, /etc/olpc-update.d/ named 'ohm' that spits out "all the logs since I was last run", then I can arrange to have olpc-update run these scripts and send the results upstream as a binary blob when it checks for new updates.

comment:2 Changed 9 years ago by cjb

Richard wants this data too, so we'll coordinate on getting it in over the next few days.

comment:3 Changed 9 years ago by jg

  • Description modified (diff)

comment:4 Changed 9 years ago by gnu

The recorded data should also include the battery's couloumb counter, showing accurately how much energy has been used since the last update. To validate this info, we'd also need the charging status (voltage and amperage, positive or negative). When the laptop runs on battery, we have a very accurate accounting of how much power the laptop is using, and the ohm logfiles should record it. Not only to see what our "average" power consumption is (over time and over the population of laptops), but also to see how much variation there is across the population of laptops and batteries. We will likely find some variations that can lead us to improvements, bringing every laptop toward higher battery capacity and lower power use. The logs can also be used as benchmarks against which new releases can be tested; if a new release consumes significantly higher power for a given run of activities, it should be tuned to reverse that trend.

comment:5 Changed 9 years ago by jg

  • Milestone changed from Update.1 to Update1.1

comment:6 Changed 9 years ago by cscott

  • Cc cscott added

I've got some ideas about doing data upload during olpc-update-query, once you figure out what you want to collect. The requirement on your end is having a simple script which olpc-update-query which will give on stdout a limited size dump of 'interesting information'. Say 10k or so? You then can implement the logging, rotation, etc, however you like.

comment:7 Changed 9 years ago by cscott

  • Blocked By 6447 added

comment:7 Changed 9 years ago by cscott

  • Blocked By 6447 removed

From discussion, my more recent recommendation is not syslog, but a in-memory ring buffer. If persistence across reboots is required, then saving/loading the ring buffer to/from disk can be done in an init script. The helper script would send OHM a dbus message (say) to get it to give it the current contents of its ringbuffer.

comment:8 Changed 20 months ago by Quozl

  • Milestone 8.1.1 (was Update1.1) deleted

Milestone 8.1.1 (was Update1.1) deleted

Note: See TracTickets for help on using tickets.