Loading in 2 Seconds...
Loading in 2 Seconds...
Characterizing and Conserving Energy Consumption in Mobile P2P Systems. Selim Gürün Priya Nagpurkar Ben Zhao Department of Computer Science U.C. Santa Barbara. 1 st International Workshop on Decentralized Resource Sharing in Mobile Computing and Networking ACM MOBISHARE, Los Angeles, CA
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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.
Characterizing and Conserving Energy Consumption in Mobile P2P Systems Selim Gürün Priya Nagpurkar Ben Zhao Department of Computer Science U.C. Santa Barbara 1st International Workshop on Decentralized Resource Sharing in Mobile Computing and Networking ACM MOBISHARE, Los Angeles, CA September 25, 2006
Breaking News… .... The U.S. software maker also boasted that Zune has what iPod doesn’t have, music-sharing capability. Using its Wi-Fi wireless function, Zune users will be able to detect one another and then share songs, recordings and pictures wirelessly. ….. • How to implement P2P applications/routing stacks on resource-constrained mobile devices? ACM MOBISHARE
Underlying Research Questions • What are the resource constraints of mobile devices and what makes P2P more challenging on such devices? • How do current P2P protocols utilize mobile device resources, especially the limited energy supply? • Can we implement a mobile-friendly, energy-efficient P2P application on such devices? How? ACM MOBISHARE
Decentralization-Induced Challenges on Mobile Devices • Mobile devices: Very diverse • Linux wristwatches, multi-core laptops and anything in between • Our platform: smart-phone and PDA like devices • Energy constraints on mobile devices introduce unique challenges to distributed applications • In Client-Server architecture clients offload tasks to wall-powered, resource-rich servers • Easier to implement disconnected operation for client • P2P nodes provide services to fellow nodes –no servers • Nodes have to be awake for providing services • Always-on, always connected assumption hurts mobile P2P ACM MOBISHARE
Underlying Research Questions • What are the constraints of mobile devices and what makes P2P more challenging on such devices? • Energy is limited • Always-on nature of servers restricts sleep options • How do current P2P protocols utilize mobile device resources, especially the limited energy supply? • Can we implement a mobile-friendly, energy-efficient P2P application on such devices? How? ACM MOBISHARE
P2P On Resource Restricted Devices • Initial idea was: • To evaluate the performance of a proof-of-concept P2P application on a mobile device • Not as trivial as it seems! • Many P2P protocols are implemented with no embedded platforms in mind • Simmud • Peer-to-peer multiplayer game from UPenn. • Back-ported to JRE 1.3 (inetsocketaddress, etc.) • Not stable in our run-time environment • FreePastry, Tapestry • Extensive use of non-blocking IO • Back-porting not feasible at all • Simpastry: C# ACM MOBISHARE
Chimera: A Light-Weight P2P Protocol • Light-weight, structured P2P protocol based on Tapestry • Developed in UCSB-CURRENT lab • Implemented in C as an application library • Easy to port: Requires (only) OpenSSL, arm-gcc is fine! • Chimera-CHAT • A generic, command-line based chat application • Forwards messages based on destination host’s node identifier • Chimera Internals • Borrows many concepts from Tapestry, e.g. circular address space • Prefix based routing: O(log(n)) hops in average • Nodes keep links to nodes that are in close proximity for stability ACM MOBISHARE
Source Node Leafset Neighbor Routing Neighbor Leafset Links Routing Table Links Chimera Routing 3223 0230 3123 3011 3003 3001 2333 2331 1023 2011 Each node keeps a leafset of neighbors and a set of routing nodes. ACM MOBISHARE
Powermon PerfMon High-precision Data Acquisition Device SCL Programmable Power Supply Stargate and Our Evaluation Bench PowerTool ACM MOBISHARE
CPU Load Across Scenarios ACM MOBISHARE
Wireless Energy Use Across Experiments ACM MOBISHARE
Chimera –Energy Consumption Results • CPU utilization is low • We do not observe any significant increase in CPU load when we increase network size from 25 nodes to 200 • Techniques like voltage/clock scaling can reduce CPU energy consumption significantly • Analyzes with much larger networks pending! • Wireless utilization is also low • Idle 70% of the time, in average • Better utilization of wireless interface needed • Compared results to TMSNC • A command line based MSN client • Not a substantial difference ACM MOBISHARE
Underlying Research Questions • What are the constraints of mobile devices and what makes P2P more challenging on such devices? • Energy • Always-on assumption (for server functionality) • How do current P2P protocols utilize mobile device resources, especially the limited energy supply? • Most energy wasted in idle state • No large CPU demand difference between client-server and P2P applications • Can we implement a mobile-friendly, energy-efficient P2P application on such devices? How? • Should we depend on physical layer for energy savings? Or should we use application layer to manage it? ACM MOBISHARE
Beacon Interval ATIM ATIM ATIM B Node A B B Node B Node C A ATIM R ATIM ACK D Data P Data ACK B Beacon Reclaiming Idle Power in 802.11 Ad-Hoc Mode A A D A R P A L A L A L A: Active L: Low Power ACM MOBISHARE
Physical Layer Power Saving Caveats • Approximate energy savings rate (when idle): 1 – (ATIM window/Beacon window) • Real energy savings is lower: sleep mode uses energy • (Not good) Each data message requires one ATIM message + an ACK • ATIM window: too small-> not enough time for ATIM broadcast, too large -> not enough time for data frames • Cisco Aironet parameters: • Beacon period: 20 to 1000 milliseconds, default 100 • ATIM window: 5 to 60 milliseconds, default 5 • The best beacon and ATIM parameters are application specific! • Can we do better than this, if we let P2P routing protocols adaptively choose best parameters? ACM MOBISHARE
Wireless Card Sleep Policy Can we use Chimera network manager for better energy savings? Wi > 1 seconds Active Low Power Wt > 3 seconds Wi: Wireless Idle time Wt: Wake up timeouts for checking network state ACM MOBISHARE
Energy Savings Impact of Various Wi 42% savings 26% savings ACM MOBISHARE
Average Delay of Various Wi ACM MOBISHARE
Related Work • Numerous energy saving protocols exist for ad-hoc networks • IEEE 802.11 ad-hoc power savings protocol • SPAN • Jung et al. (Texas A&M) • Power profiling setups used in prior studies to characterize mobile power consumption • Powerscope • Other P2P Systems for mobile networks • JXTA • Jabber • RockyRoad ACM MOBISHARE
Summary & Future Directions • Our Goal: A resource-aware, energy efficient P2P protocol • Tapestry like Java based implementations not suitable for mobile platforms • Chimera: Surprisingly efficient! • Physical layer power saving protocols are useful but not enough! • More savings possible by providing more feedback from P2P protocol later to physical layer. • A lot of work is ongoing • Compare power saving methods • Evaluate in much larger mobile communities ACM MOBISHARE
Backup Slides ACM MOBISHARE
P2P on Mobile Systems • Peer-to-peer paradigm: Decentralized, highly-scalable, fault-tolerant networks P2P • P2P nodes are both clients and servers depending on context of operation. • Mobile Systems: • More widespread than ever • Wireless networks everywhere • How to implement P2P applications/routing stacks on mobile devices when there are so many resource constraints? ACM MOBISHARE
Wireless Card Power Consumption ACM MOBISHARE
Most Expensive Functions ACM MOBISHARE
Jabber In jabber, the peers communicate to each other using servers. Not exactly a P2P architecture Jabber Server Jabber Server Mobile Jabber Client Mobile Jabber Client ACM MOBISHARE
JXTA In JXTA, the peers has to ask rendezvous servers who provides the service. Rendezvous Server Rendezvous Server Service advertisement Service Discovery Mobile JXTA Peer Mobile JXTA Peer ACM MOBISHARE
RockyRoad In RockyRoad, routing and service discovery protocols are designed by the developer. RockyRoad is an API. Rendezvous Server Rendezvous Server Developer Specific Service Discovery Service advertisement Default Protocols Routing: Forwarding Searching: Broadcasting Mobile RockyRoad Peer Mobile RockyRoad Peer ACM MOBISHARE Support for J2ME and J2SE exist!.
SPAN SPAN sits on top of physical layer. It tries to minimize the number of nodes that have their wireless NIC turned on, while still maintaining a connected network Localized decisions: battery and # of pairs that it can connect ACM MOBISHARE