1. D u k e S y s t e m s CrowdLab An Architecture for Volunteer Mobile Testbeds Eduardo Cuervo Peter Gilbert Bi Wu Landon P. Cox Duke University

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

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

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

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

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

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

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

9. D u k e S y s t e m s CrowdLab architecture

10. D u k e S y s t e m s Roadmap Motivation CrowdLab Hypervisor requirements Dual-mode wireless scheduling Evaluation Conclusions

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

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

13. Virtual Wi-Fi A B C A B C 0100ms200ms300ms400ms

14. Virtual Wi-Fi A B C A B C 0100ms200ms300ms400ms

15. Virtual Wi-Fi A B C A B C 0100ms200ms300ms400ms

16. Virtual Wi-Fi A B C A B C 0100ms200ms300ms400ms

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

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

19. Managed mode A B C A B C 05min10min15min20min

20. Unmanaged mode A B C A B C 05min10min15min20min

21. Managed mode A B C A B C 05min10min15min20min

22. Unmanaged mode A B C A B C 05min10min15min20min

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

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

25. D u k e S y s t e m s Roadmap Motivation CrowdLab Hypervisor requirements Dual-mode wireless scheduling Evaluation Conclusions

26. 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 Samsungs port

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

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

29. D u k e S y s t e m s Epoch switching savings Reducing managed epochs reduces power consumption

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

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

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

33. D u k e S y s t e m s Churn results Policies are enforced Resources are accurately accounted for

34. 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 users 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. D u k e S y s t e m s Questions? Email: Eduardo Cuervo