Should OHM save to a logfile?

[cjb]

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.

[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.

[cjb]

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

[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.

[cscott]

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.

[cscott]

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.