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


CrowdLabAn Architecture for Volunteer Mobile

TestbedsEduardo Cuervo

Peter GilbertBi Wu

Landon P. Cox

Duke University


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


Mobile experimentation is hard

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


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


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


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


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


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)


CrowdLab architecture


Roadmap

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

• Evaluation• Conclusions


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


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


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


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


Managed mode

A

B

C


Unmanaged mode

A

B

C



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


More details in the paper

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


Roadmap

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

• Evaluation• Conclusions


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


Evaluation questions

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


Energy experiments

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


Epoch switching savings

Reducing managed epochs reduces power consumption


How much time can be contributed?

Owners can contribute one hour per day on a single charge


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)


Experiment policies

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


Churn results

Policies are enforced

Resources are accurately accounted for


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


Questions?

Email:Eduardo Cuervo <[email protected]>

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

Documents

e s y s t e

s epoch

s smartphones

s problems

s crowdlab architecture

s energy experiments

s mobile experimentation

s wireless multiplexing