Survey of paper "Understanding the characteristics of android wear os"

1. Understanding the
Characteristics of
AndroidWearOS
Renju Liu, Felix Xiaozhu Lin
Purdue ECE
Presentation By: Pratik Jain

2. Motivation
 Interactive wearables, like smart watches, are a newcomer to the
spectrum of mobile computers.
 Integrate computing even tighter with our daily lives.
 Substantial increase in demand for smart watches.

3. Usage
Patterns
&
Device
Hardware
 Users interact with wearable devices frequently throughout the
daily use
 Each interaction is short ( < 10s ), and is dedicated to a simple task
 Due to the limited content that can be displayed on one screen,
users spend a short time on one screen before switching to the
next.
 Tiny Battery capacity (200 – 400mAh)
 Slower CPU – Fewer cores
 Simpler CPU – Scaled-down but often architecturally identical to
handheld’s CPU

4. AndroidWearOS
 One of the most popular OSes for interactive wearables.
 Wearable OS with the most public information.
 Supports third-party applications and features a resigned system
UI, including Card for notifications, Context streams, and voice
input.
 Apps – renovated UI – Follow Android’s conventional
programming paradigm – Written in Java – Compiled ahead-of-
time – executed atop the managedAndroid Runtime.
 Major OS components –
 System Server – Key daemon hosting the core OS services
 Surface Flinger – Daemon controlling UI animation
 Clockwork – OS shell that implements the system UI

5. Benchmark
Scenarios
 A benchmark suite that consists of 15 benchmarks falling into the
following 4 categories:
1. Wakeup – Due to internal or external events, device transits out of
suspended mode and presents brief information. Due to frequent daily
wakeup, energy efficiency is the most important metric.
2. Single input – A waking wearable device responds to a single input
from the user. Because the user is waiting, the device needs to achieve
low UI latency.
3. Continuous interaction – Users are interacting with the device
continuously. The resultant UI animation requires the device to
produce a steady stream of graphic frames.
4. Sensing – For the execution of wearable apps, sensor data is sampled
and processed periodically to collect context information.

6. METHODOLOGY

7. Experimental
Setup
 All the benchmarks are run on 2 state-of-the-art Android Wear
devices
 LGWatch R
 Samsung Gear Live
 Qualcomm’s APQ8026 system on-chip
 AndroidWear 5.0 “Lollipop”

8. Power
Management
 Batteries have tiny contacts which are incompatible with
commodity power monitors.
 A compatible interface circuit is carved out from a smartphone
battery.
 Used the interface as an adapter between the smart watch and an
external power monitor.
The battery
interface carved
out from Nexus 5
The interface
(flipped) connected
to the LG watch R

9. Toolset
 Used the following to examine system behaviors at different levels
and granularities
 Systrace – for capturing global system events such as scheduling, I/O
activities, and IPC
 Android Runtime’s built-in function tracer – for recording function
call history in individual processes
 Linux perf – for sampling CPU performance counters.

10. Tackling
profiling
overhead
 EventTracing – Major profiling overhead
 Memory overhead can be overwhelming in tracing function
invocations.
 2 ways used to tackle
 In quantifying global system behaviors, the paper only relies on
system events. It collects function trace from extra runs.
 In quantifying function-level activities, deduction of an overhead of
4 µs from each traced function invocation ( constant overhead ).

11. CPUUsage
 CPU usage is collected at two granularities
 Task-level breakdown. An analyzer is built to identify the tasks .
 Function-level breakdown. To further locate the performance
hot spots in System Server, the following 2 metrics are employed:
 Exclusive CPU cycles are spent in the function’s own code
 Inclusive CPU cycles are spent in the function’s code as well as
in all subroutines being called
 Both metrics include the time spent in both user and kernel spaces
and do not cover the time when a task is off CPU due to being
scheduled out.

12. IdleTime
Analysis
 Amount and duration of the observed idle episodes are unusual.
 Match some idle episodes to system events known to cause idle, e.g.
I/O and power management.
 Others often root in stalling of OS service in serving app’s requests.
 IdleChecker, an analyzer that helps mapping anomalous idle episodes
to the responsible code regions, based on a simple rationale:
The function calls and IPC transactions spanning an anomalous idle
episode are suspicious.
 IdleChecker runs the following steps for each idle episode.
 Identifies suspicious app tasks that are blocked throughout the entire
idle episode but run after the episode.
 For each suspicious task, it identifies two suspicious CPU time quanta:
the one right before the idle episode and the one right after it.
 Examines the suspicious quanta, looking for IPC transactions spanning
across the idle episode.
 Identifies the function invocations that either coincide with the IPC
or span across the idle episode.

13. Thread-level
Parallelism
 Metric widely used for gauging an interactive system’s need for
core count.
 Average number of busy CPU cores during the non-idle time.
TLP = 𝑖=1
𝑛
𝑖 ∗ 𝑐𝑖/(1 − 𝑐0)
 𝑐0 - total time when no threads are running
𝑐𝑖 - time when exactly i threads are running simultaneously
n - number of cores available.
 For measurement, all 4 cores are forced online

14. Microarchitectural
behaviors
 Microarchitecture design is a Mystery
 By using the Linux perf, the paper samples the performance
counters of the Cortex-A7 CPU on test devices.
 Observe branch prediction, cache, andTLB in all benchmarks

15. RESULTS

16. Where doCPU
cycles go?
 Intensive OS execution often dominates the global CPU usage.
 Many costly OS services are likely to make software unnecessarily
complicated
 The CPU time distribution of hot functions is highly skewed.
 Manipulating basic data structures consumes substantial CPU
cycles.
 Legacy OS functions may become serious performance
bottlenecks
 OS Execution Bottlenecks
 setLight(), Layout(), computeOom(), getSimpleName()

17. Idle Episodes
 Plentiful and of a variety of lengths
 Improper OS Designs
 Interference from voice UI
 Legacy support for device suspending
 Performance overprovision during continuous Interaction
 Design Implications
 Hunting OS inefficiencies
 Filling idle time with useful work
 reducing CPU & GPU clock rates which will shrink idle episodes
 predictive execution

18. Thread-level
parallelism
 Short interactions exhibit substantial TLP, which is on par with
desktop workloads.
 While apps are mostly single-threaded, OS daemons contribute to
TLP significantly.
 A wearable device needs at least two cores.

19. Microarchitectural
behaviors
 A significant mismatch exists between the OS and CPU
microarchitecture, particularly in L1 icache, iTLB, and branch
predictor.
 The mismatch is largely due to the OS code complexity, and will
not be eliminated by a unilateral enhancement of wearable CPU.
 OS should be trimmed down to match the simplicity of its apps.

20. RelatedWork
 Gao et al. find that smartphone workloads show limitedTLP,
concluding that they need no more than two cores.
 ProfileDroid contributes an approach for charactering smartphone
apps at multiple layers
 Min et al. studies the battery usage of smart watches
 WearDrive creates synthetic benchmarks to shed light on
wearable storage.
 RisQ andTypingRing target gesture recognition
 iShadow tracks gaze in real time
 Ha et al. build wearable for cognitive assistance
 Cornelius et al. focus on user identification

21. Recap
 In-depth analysis of one of the most popular wearable Oses,
Android Wear.
 Examination of 4 key aspects: CPU usage, idle episodes, TLP, and
micro-architectural behaviors – in fifteen benchmarks.
 Discovery of serious OS inefficiencies and system bottlenecks that
were widespread but unknown before.
 The results clearly point out the system bottlenecks for immediate
optimization and have strong implications on future wearable
system software and hardware design.

22. THANKYOU!