Transcript Duke Systems CrowdLab An Architecture for Volunteer Mobile Testbeds Eduardo Cuervo Peter Gilbert Bi Wu Landon P.

Duke Systems
CrowdLab
An Architecture for Volunteer Mobile
Testbeds
Eduardo Cuervo
Peter Gilbert
Bi Wu
Landon P. Cox
Duke University
Duke Systems
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
Duke Systems
Mobile experimentation is hard
•
•
•
•
Mobility is fundamental but difficult to model
Location affects system behavior
Connectivity can be unpredictable
Devices are power constrained
Duke Systems
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
Duke Systems
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
Duke Systems
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
Duke Systems
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
Duke Systems
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)
Duke Systems
CrowdLab architecture
Duke Systems
Roadmap
• Motivation
• CrowdLab
• Hypervisor requirements
• Dual-mode wireless scheduling
• Evaluation
• Conclusions
Duke Systems
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
Duke Systems
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
Duke Systems
Virtual Wi-Fi
B
C
A
A
B
C
0
100ms
200ms
300ms
400ms
Virtual Wi-Fi
B
C
A
A
B
C
0
100ms
200ms
300ms
400ms
Virtual Wi-Fi
B
C
A
A
B
C
0
100ms
200ms
300ms
400ms
Virtual Wi-Fi
B
C
A
A
B
C
0
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
Duke Systems
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
Duke Systems
Managed mode
B
C
A
A
B
C
0
5min
10min
15min
20min
Unmanaged mode
B
C
A
A
B
C
0
5min
10min
15min
20min
Managed mode
B
C
A
A
B
C
0
5min
10min
15min
20min
Unmanaged mode
B
C
A
A
B
C
0
5min
10min
15min
20min
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
Duke Systems
More details in the paper
•
•
•
•
Fault-tolerant state (site directory)
Tasking services
Naming services
Custom N810 ARM Xen
Duke Systems
Roadmap
• Motivation
• CrowdLab
• Hypervisor requirements
• Dual-mode wireless scheduling
• Evaluation
• Conclusions
Duke Systems
CrowdLab Prototypes
12 X86 laptops
5 N810 tablets
• Ubuntu 7.10 on Dell
Inspiron 1525
• Xen 3.1, kernel 2.6.18
• Xen PCI-Passthrough
• Nokia Maemo
• Custom ARM Xen based
on Samsung’s port
Duke Systems
Evaluation questions
• Do we save energy by coarse-grain switching?
• How much time could users contribute?
• How well does CrowdLab perform under churn?
Duke Systems
Energy experiments
• Used N810 testbed
• Agilent power meter
• Used C-Scan experiment
• Evaluates AP performance collaboratively
• Bandwidth, latency, connectivity
Duke Systems
Epoch switching savings
Reducing managed epochs reduces power consumption
Duke Systems
How much time can be contributed?
Owners can contribute one hour per day on a single charge
Duke Systems
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)
Duke Systems
Experiment policies
• C-Who: at least two instances
• C-Scan: as many instances as possible
• Virtual Wi-Fi: must support PCI-passthrough
Duke Systems
Churn results
Resources are accurately accounted for
Policies are enforced
Duke Systems
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
Duke Systems
Questions?
Email:
Eduardo Cuervo <[email protected]>
Duke Systems