Efficient Monitoring and Saving CPU time

back

Optimization

The application has been optimized to consume as little as possible to perform its activities (see bottom of this page for more details). For more information on how much each component of the application consumes, check-out these benchmarks.

History and Data Rates

From the settings, you can change 2 rates of update:

  •       History logging defines how often values will be stored in the text file.
  •       Current mA defines how often to retrieve current data from the system.

All other battery information is provided by the system using events and is thus updated as soon as a change occurs.

Most battery drivers provide current mA data every minute. So it’s often pointless to refresh that data more often. CyanogenMod kernels are reported to have a more frequent update rate.

Saving CPU time

To save CPU time while keeping data accuracy, current mA data is averaged based on previous measures when logging.

For example, using default settings, if the measured values are 2mA, 5mA, 12mA, 3mA and 4mA during 5 minutes, the average 5mA (2+5+12+3+4 / 5) will be logged in the history.

You can set the data refresh rate to lower rates (5 minutes for example), but you will loose precious data in between!

Widgets obviously take CPU time to refresh, so don’t add too many of them!

Notifications (as well as external package) take time to refresh as well, but less than widgets, so use at your own discretion.

Changing settings based on your needs

By default, current mA is refreshed every minute and history is logged every 5 minutes!

You care for notifications only:

  •        Remove any widgets, those take more CPU than notifications.
  •        Disable history logging if you don’t use it.
  •        Disable graphics if you don’t need them, text history is often enough to track issues.

You are tracking a battery drain issue:

  •        Set history logging and data refresh rates to the same value (1 minute)
  •        Remove widgets and notifications to reduce battery usage to its bare minimum.

In daily use:

  •        Increase history logging to 5 minutes, leaving a 1 minute data refresh rate to keep accurate readings.
  •        Optionally disable history logging, keeping the graphics for infrequent checks.
  •        Or disable graphics, keeping history logging, allows enabling graphics when needed.
  •        Or disable both graphics and history logging if you don’t need monitoring anymore.

Graphics and History Duration

The more data you keep the longer it might take to draw the graphics or load the history file, hence the more CPU/battery it will use within the application; this is why there are limitation settings!

You must make sure the logging rate and the maximum history duration are set appropriately to avoid going beyond your system limit or slowing down the application.

For example setting a logging rate of 10 seconds while keeping 28 days will use 12Mbytes of raw data and slow-down the initial display of a graphic!

Screen-off behavior

Note that notifications and widgets are not refreshed when the screen is off, thus the application will consume the minimum for the configured monitoring.

Alarms will continue to be triggered even if screen is off!

Deep-sleep behavior

Tests have shown that a 1 minute interval monitoring allows deep-sleep to occur as usual. Thus monitoring has a reduced impact on battery. Higher refresh rate will obviously consume more and might prevent deep-sleep from occurring!

You might want to try System Tuner application to actually check your settings! The CPU detail screen will show you the deep-sleep time since start!