Setup and load

Method

Android

Software: Changed code to support perturbing the following values:

• geofenced versus continuous
• time filter (interval between readings)
• accuracy (balanced power versus high accuracy)

Hardware

• Collected data for 6 hour stretches
• Same phone was used for all experiments (Galaxy Nexus S, released in 2011, running Android 4.0 Ice Cream Sandwich)

Workload

• Largely stationary at home
• Made one trip to kids's school (4 km, ~ 20 mins) in every 6 hour window
• Scaled x4, simulates day in the life of "office worker"
  • commutes to work in the morning
  • commutes back in the evening
  • go to dinner/gym etc at night
  • return home
• Used scaling in order to explore space quickly using a single phone

High order bit for results

Android

Background battery drain over 6 hours

Background battery drain extrapolated to 24 hours (6 hours * 4)

Observations

• Significant background power drain even in the absence of data collection (~ 60% drain over the course of the day)
• At 30 - 60 sec cycles, data collection with geofencing is essentially free (~ 40% drain over the course of a day)
  • At 60 sec intervals, geofence doesn't buy you that much (~ 2%, well within error ranges)
  • At 30 sec intervals, geofence is somewhat useful (~ 20%, but is that within error range? see below)
  • At 2 sec intervals, geofence is incredibly useful (difference between running out of battery and not)

Existing duty cycling?

• Drain with data collection during the day (10:30pm to 4:30am and 7am to 1pm) is 10-15% (extrapolated to 40-60% through the day). During the first 10:30pm to 4:30am, the phone was by my side as I worked. I checked it occasionally, but was at home except for one mandatory trip to kids's school. The 7am to 1pm data collection was on my trip to Berkeley on Friday. At that time, I was obviously in motion but made a conscious effort not to use the phone for normal activities. This was a real strain, but I persevered until I downloaded the data during the SDB meeting.
• No data collection between midnight and 6am was around 2%. At this time, the phone was lying on a bedside table and I did not touch it.
• Interestingly, on the night that I slept in the lab, the drain between midnight and 6am was still around 10%. I hypothesise that this is because I used the phone as an alarm clock and picked it up occasionally to check the time.

This is consistent with the Martins et al paper in USENIX 2015 (https://www.usenix.org/system/files/conference/atc15/atc15-paper-martins.pdf) where they compared the power drain of a base Android install with one that had Google Play Services installed. Presumably this is what Doze is intended to assist with. My phone is a Galaxy Nexus that is a few generations old, so old that Google no longer releases OTA for it. So I am not running Android Marshmallow and cannot verify what Doze does. It would be pretty cool to see how all this interacts with Doze.

Unexplained Anomaly

There is one clear anomaly - the low power drain of the ongoing high accuracy collection.

My expectations around high accuracy are as follows:

• high accuracy sensing will have higher power drain than balanced accuracy. This appears to be true with a geofence - the high accuracy drain is significantly higher. In particular, battery drain at high accuracy at an interval of 30 secs is higher than balanced accuracy at 2 secs (80% v/s 60%), and is almost double of low accuracy at 30 secs (80% v/s 40%)
• ongoing sensing will have a higher or equal power drain than geofencing. We don't know what the power drain for the blackbox geofencing implementation is, but it seems reasonable to assume that it would be no worse than just running the sensing continuously, since otherwise it makes no sense for the OS to provide the API. And indeed, this is true for all balanced power sensing modes, although the difference can be small at times. The difference is particularly pronounced for the 2 sec case (130% versus 60%) and probably within noise for the 60 sec case (42% versus 40%).

However, this expectation is not met for the high accuracy case. The ongoing high accuracy case has two anomalies:

• With geofencing, high accuracy drain is higher than balanced accuracy with 2 sec drain. But without geofencing, high accuracy drain is lower than balanced accuracy with 2 sec drain.
• The power drain of ongoing high accuracy collection is significantly lower than the power drain for geofenced high accuracy collection (~ 55% v/s 80%).

This is counter-intuitive. If high accuracy sensing is so expensive, why isn't more of it more expensive? Since this was a counter-intuitive result, I did some sanity checking to ensure that this wasn't a bug.

Is this a bug?

It is pretty clear from the graph above that:

• balanced power accuracy turns the GPS on very infrequently (O(10) times)
• high power accuracy uses the GPS much more frequently - for the geofenced implementation, the lock is acquired ~ 40 times for a ~ 20 min ride
• high power, ongoing collection acquires the gps lock at 7 times the rate of the geofenced implementation (350 v/s ~ 50) and it runs for 1 hr 23 min instead of 10 min. But it still consumes less power. The only explanations for this that I can think of are:
  • GPS chips have now become efficient enough that while they are on in a suburban location, they take about as much power as a wifi scan
  • they have a large startup cost, so powering them on occasionally consumes more power than just leaving them on.

The explanations are not very convincing (if #2 above were true, then the fused API is no longer as compelling), so it would be interesting to explore this further in the future.

Note also that we would expect the gps-lock to be acquired 720 times (6 hours, at 30 sec intervals), but it is actually acquired only 350 times. It looks like even in high accuracy mode with the fused API, the OS only turns the GPS on half the time. It either takes two readings per lock, or duty cycles the GPS based on techniques similar to Paek et al from Mobisys 2010. http://dl.acm.org/citation.cfm?id=1814463

Noise and error bars

Except for the no data collection, I have run the data collection for a particular regime exactly once. This means that some of the other anomalies may just be the result of noise. In particular, there are some small unexpected anomalies in addition to the previous one.

• drain for geofenced data collection at 30 sec intervals is less than the drain at 60 sec intervals (38% versus 40%)
• drain for geofenced data collection at both 30 and 60 sec intervals is less than the drain for no data collection (38% and 40% versus ~45%)
• drain for ongoing data collection at 30 and 60 secs is around the same as that for no data collection (48%)
• drain for ongoing data collection at 60 secs is less than that for no data collection (42% versus 48%)

My assumption is that all of these are within the noise for the battery drain, but then are the savings by using the geofence real? I think that we should get multiple runs and get error bars to confirm.

What is the accuracy?

batteryinfo dump and accounting

In order to generate these stats, I used the adb shell dumpsys batteryinfo command. This command is replaced in later versions of android with the adb shell dumpsys batterystats command and the current documentation (https://source.android.com/devices/tech/power/batterystats.html) refers to the output of the current command.

In the prior analysis, I have primarily used the battery drain, which can be measured directly using a standard API. However, the dumpsys shell command promises to provide additional information which could potentially be used to build a richer model. How much additional information can I collect, and how useful is it?

My first thought was to use $ adb shell dumpsys batterystats --charged from the documentation, but it turns out that it is not supported for batteryinfo.

The output also does not support the pwi (Power Use Item) or pws (Power Use Summary) fields.

I then looked at the raw data and pulled out some information that appeared to be relevant.

• duration since start
• for the tracker process (cfc_tracker or mobility)
  • bytes sent
  • bytes received
  • wake lock duration and count
  • wake lock for sync duration and count
  • travel diary state machine invocation duration and count
  • location change service invocation duration and count
  • activity recognition service invocation duration and count

Observations

• Sensor power drain is not charged to the process. Note neither the accelerometer, nor WiFi are listed below.
• It looks like what is primarily charged to the process is the time that it runs in the foreground, consuming CPU resources
• It is not clear what all the various Wakelocks represent (why is the GCoreFlp wakelock 273 times? What does it represent?
• The sync takes way too much time. The app spends more time syncing (5 minutes) than it does collecting and storing location data (1 minute)
  • The incoming sync is an order of magnitude bigger than the outgoing sync
  • So the travel diary representation that we send is too big. There are also known issues with purging items from the cache properly. We should revisit and streamline our cache implementation.
• mobility app does not appear to sync its data?! Or maybe it is so fast that it does not meet the threshold for reporting? Need to ask them.

#10065:
Network: 36.45MB received, 860.01KB sent
Wake lock GCoreFlp: 1s 223ms partial (273 times) realtime
Wake lock GeofencePendingIntentWakeLock: 4ms partial (2 times) realtime
Wake lock *sync*_edu.berkeley.eecs.cfc_tracker.provider_Account {name=dummy_account, type=openbms.org}: 5m 25s 57ms partial (10 times) realtime
TOTAL wake: 5m 26s 284ms partial realtime
Proc *wakelock*:
  CPU: 58s 910ms usr + 15s 270ms krn
Proc edu.berkeley.eecs.cfc_tracker:sync:
  CPU: 1m 35s 600ms usr + 6s 500ms krn
  10 proc starts
Proc edu.berkeley.eecs.cfc_tracker:
  CPU: 16s 610ms usr + 5s 540ms krn
  8 proc starts
Apk edu.berkeley.eecs.cfc_tracker:
  Service edu.berkeley.eecs.cfc_tracker.location.TripDiaryStateMachineService:
    Created for: 3s 601ms  uptime
    Starts: 4, launches: 4
  Service edu.berkeley.eecs.cfc_tracker.location.GeofenceExitIntentService:
    Created for: 1s 452ms  uptime
    Starts: 2, launches: 2
  Service edu.berkeley.eecs.cfc_tracker.smap.SyncService:
    Created for: 0ms  uptime
    Starts: 0, launches: 10
  Service edu.berkeley.eecs.cfc_tracker.location.ActivityRecognitionChangeIntentService:
    Created for: 18s 61ms  uptime
    Starts: 37, launches: 37
  Service edu.berkeley.eecs.cfc_tracker.location.LocationChangeIntentService:
    Created for: 1m 54s 703ms  uptime
    Starts: 94, launches: 94

Next steps

• Get additional set of readings for the following regimes so that we can get some error bars.

  • geofence 30 secs
  • geofence 60 secs
  • geofence 30 secs high accuracy
  • ongoing 30 secs
  • ongoing 60 secs
  • ongoing 30 secs high accuracy
  • mobility data collection

• We do not need to repeat the 2 sec interval readings since the results were unambiguous in that case.

• During the geofence tests, I will make at least a 20 min round trip outside.
• For the ongoing tests, I may or may not make the trip, since we don't do any duty cycling.

Error bars

Since I had only a week between the previous result and the current presentation, I was able to get error bars for only some of the regimes. I got the most data for the "no data collection" or baseline regime, since it showed a fair amount of variability, and it is key to know how much additional drain continuous collection adds.

Gory Details