1 / 35

CrowdLab

CrowdLab. An Architecture for Volunteer Mobile Testbeds. Eduardo Cuervo Peter Gilbert Bi Wu Landon P. Cox Duke University. Smartphones: disruptive technology. Evaluating ideas for new applications requires multi-device experimentation. Powerful computers Always-on, mostly-connected

mariel
Download Presentation

CrowdLab

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. CrowdLab An Architecture for Volunteer Mobile Testbeds Eduardo Cuervo Peter Gilbert Bi Wu Landon P. Cox Duke University

  2. Smartphones: disruptive technology Evaluating ideas for new applications requires multi-device experimentation • Powerful computers • Always-on, mostly-connected • Constant proximity to owner • Place computation everywhere (cafes, cars, campus)

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

  4. 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

  5. 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

  6. 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

  7. 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

  8. 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)

  9. CrowdLab architecture

  10. Roadmap • Motivation • CrowdLab • Hypervisor requirements • Dual-mode wireless scheduling • Evaluation • Conclusions

  11. 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

  12. 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

  13. Virtual Wi-Fi B C A A B C 0 100ms 200ms 300ms 400ms

  14. Virtual Wi-Fi B C A A B C 0 100ms 200ms 300ms 400ms

  15. Virtual Wi-Fi B C A A B C 0 100ms 200ms 300ms 400ms

  16. Virtual Wi-Fi B C A A B C 0 100ms 200ms 300ms 400ms

  17. 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

  18. 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

  19. Managed mode B C A A B C 0 5min 10min 15min 20min

  20. Unmanaged mode B C A A B C 0 5min 10min 15min 20min

  21. Managed mode B C A A B C 0 5min 10min 15min 20min

  22. Unmanaged mode B C A A B C 0 5min 10min 15min 20min

  23. 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

  24. More details in the paper • Fault-tolerant state (site directory) • Tasking services • Naming services • Custom N810 ARM Xen

  25. Roadmap • Motivation • CrowdLab • Hypervisor requirements • Dual-mode wireless scheduling • Evaluation • Conclusions

  26. CrowdLab Prototypes 12 X86 laptops 5 N810 tablets Nokia Maemo Custom ARM Xenbased on Samsung’s port • Ubuntu 7.10 on Dell Inspiron 1525 • Xen 3.1, kernel 2.6.18 • Xen PCI-Passthrough

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

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

  29. Epoch switching savings Reducing managed epochs reduces power consumption

  30. How much time can be contributed? Owners can contribute one hour per day on a single charge

  31. 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)

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

  33. Churn results Resources are accurately accounted for Policies are enforced

  34. 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

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

More Related