d u k e s y s t e m s crowdlab an architecture for volunteer mobile testbeds eduardo cuervo peter...

D u k e S y s t e m s

D u k e S y s t e m s

CrowdLabAn Architecture for Volunteer Mobile

TestbedsEduardo Cuervo

Peter GilbertBi Wu

Landon P. Cox

Duke University

D u k e S y s t e m s

Smartphones: disruptive technology• Powerful computers• Always-on, mostly-connected• Constant proximity to owner• Place computation everywhere (cafes, cars, campus)

Evaluating ideas for new applications requires multi-device experimentation

D u k e S y s t e m s

Mobile experimentation is hard

• Mobility is fundamental but difficult to model• Location affects system behavior• Connectivity can be unpredictable• Devices are power constrained

D u k e S y s t e m s

Internet experimentation• Large-scale testbeds for distributed systems• e.g., PlanetLab• Nodes located all over the globe• Experiment instances run as virtual machines• Expose experiments to live Internet phenomena

• As mobile researchers, we want a mobile PlanetLab

D u k e S y s t e m s

Existing approaches

• Programmed mobility• e.g., Orbit• Limited mobility

• Vehicular mobility• e.g., CarTel, DieselNet• Limited locations

• Human mobility• e.g., AnonySense• Limited access to resources

D u k e S y s t e m s

What do we want?

• Want experiments in any location• Cafes, shops, airports, etc

• Want to observe all levels of the stack• OS, drivers and applications

• Want local interactions• Ad-hoc network, sensing

D u k e S y s t e m s

How can we get there?

• Want experiments in any location• Rely on volunteer devices

• Want to observe all levels of the stack• Rely on hypervisor for isolation

• Want local interactions• Need coordination among devices

D u k e S y s t e m s

CrowdLab

• Expose mobile apps to real mobile human contexts like PlanetLab exposes systems to the real Internet

• Low-level access to wireless state• Dual mode wireless abstraction• Supports gang-scheduled instances• Can support multiple architectures (x86 & ARM)

D u k e S y s t e m s

CrowdLab architecture

D u k e S y s t e m s

Roadmap

• Motivation• CrowdLab• Hypervisor requirements• Dual-mode wireless scheduling

• Evaluation• Conclusions

D u k e S y s t e m s

Mobile hypervisor

• Simple, virtualized peripherals• Disk and Ethernet NIC• Simple read/write interfaces• Relatively easy to isolate guests from host

• Wi-Fi is different• Low-level access necessary for many experiments• Need more than read/write interface

D u k e S y s t e m s

Wireless multiplexing

• Originally considered fine-grained switching• Virtual Wi-Fi• Guests assigned a slice in Virtual Wi-Fi schedule• Switching synchronized across DAs

• Appealing abstraction• Multiplexing hidden from guests• Guests can scan for and connect to APs• DAs coordinate during their slice in schedule

Virtual Wi-Fi

A

B

C

ABC0 100ms 200ms 300ms 400ms

Virtual Wi-Fi

A

B

C

ABC0 100ms 200ms 300ms 400ms

Virtual Wi-Fi

A

B

C

ABC0 100ms 200ms 300ms 400ms

Virtual Wi-Fi

A

B

C

ABC0 100ms 200ms 300ms 400ms

D u k e S y s t e m s

Problems with Virtual Wi-Fi

• Cost of transparent sharing too great• Measurements: inaccurate due to switching• Energy: no opportunities to sleep card

• Instead, use coarse-grained switching• Leverage PCI-passthrough of hypervisors• Guests temporarily load custom driver • DAs reload trusted driver

D u k e S y s t e m s

Dual-mode wireless scheduling

• Managed mode (DAs in control)• DAs establish ad-hoc network• DAs task devices, schedule experiments• Allows experiment policies to be enforced

• Unmanaged mode (guests in control)• Accurate measurement: direct access to Wi-Fi• Energy efficient: opportunities to enter PSM

Managed mode

A

B

C

ABC0 5min 10min 15min 20min

Unmanaged mode

A

B

C

ABC0 5min 10min 15min 20min

Managed mode

A

B

C

ABC0 5min 10min 15min 20min

Unmanaged mode

A

B

C

ABC0 5min 10min 15min 20min

D u k e S y s t e m s

API for guest experiments

timeToNextEpoch Returns expected time to epoch switch Allows guest to prepare to give up radio

getCoordinator Returns IP address of coordinator guest Allows guests to coordinate their actions

D u k e S y s t e m s

More details in the paper

• Fault-tolerant state (site directory)• Tasking services• Naming services• Custom N810 ARM Xen

D u k e S y s t e m s

Roadmap

• Motivation• CrowdLab• Hypervisor requirements• Dual-mode wireless scheduling

• Evaluation• Conclusions

D u k e S y s t e m s

CrowdLab Prototypes

12 X86 laptops

• Ubuntu 7.10 on Dell Inspiron 1525

• Xen 3.1, kernel 2.6.18• Xen PCI-Passthrough

5 N810 tablets

• Nokia Maemo• Custom ARM Xen based

on Samsung’s port

D u k e S y s t e m s

Evaluation questions

• Do we save energy by coarse-grain switching?• How much time could users contribute?• How well does CrowdLab perform under churn?

D u k e S y s t e m s

Energy experiments

• Used N810 testbed• Agilent power meter• Used C-Scan experiment• Evaluates AP performance collaboratively• Bandwidth, latency, connectivity

D u k e S y s t e m s

Epoch switching savings

Reducing managed epochs reduces power consumption

D u k e S y s t e m s

How much time can be contributed?

Owners can contribute one hour per day on a single charge

D u k e S y s t e m s

Churn experiments

• Used X86 laptop testbed• Mobility-trace emulation• Ile-Sans Fil (Restaurants and Cafes)

• Laptop site running traces• Measurement (C-Scan)• Social sensing (C-Who)• Wireless driver experimentation (Vwifi)

D u k e S y s t e m s

Experiment policies

• C-Who: at least two instances• C-Scan: as many instances as possible• Virtual Wi-Fi: must support PCI-passthrough

D u k e S y s t e m s

Churn results

Policies are enforced

Resources are accurately accounted for

D u k e S y s t e m s

Conclusions

• CrowdLab: architecture for a mobile PlanetLab• Guest code runs on volunteer mobile devices:• Provides low-level access to Wi-Fi state• Protects user’s device and data integrity

• Evaluation showed that CrowdLab• Allows users to contribute several hours each day• Provides a stable testbed environment even on churn

D u k e S y s t e m s

Questions?

Email:Eduardo Cuervo <ecuervo@cs.duke.edu>