1 characterizing and conserving energy consumption in mobile p2p systems selim gürün priya...
TRANSCRIPT
1
Characterizing and Conserving Energy Consumption in Mobile
P2P Systems
Selim GürünPriya Nagpurkar
Ben Zhao
Department of Computer ScienceU.C. Santa Barbara
1st International Workshop on Decentralized Resource Sharing in Mobile Computing and Networking
ACM MOBISHARE, Los Angeles, CASeptember 25, 2006
ACM MOBISHARE 2
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.
…..
In Challenging iPod, Microsoft Hustles, Samsung Stutters
By Cho Jin-seo, Staff Reporter September 15, 2006
• How to implement P2P applications/routing stacks on resource-constrained mobile devices?
ACM MOBISHARE 3
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 4
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 5
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 6
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 7
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 8
Chimera Routing
3001
3003
2333
2331
3011
3123
1023
32230230
2011
Source Node
Leafset Neighbor
Leafset Links
Routing Neighbor
Routing Table Links
Each node keeps a leafset of neighbors and a set of routing nodes.
ACM MOBISHARE 10
Stargate and Our Evaluation Bench
PowerTool
Powermon
PerfMonSCL High-precision
Data Acquisition Device
ProgrammablePower Supply
ACM MOBISHARE 11
CPU Load Across Scenarios
0
1
2
3
4
5
Control Overhead Passive Participation Active Participation
Scenarios
CP
U L
oad
(%
)
25 Nodes
50 Nodes
100 Nodes
200 Nodes
ACM MOBISHARE 12
Wireless Energy Use Across Experiments
0%
5%
10%
15%
20%
25%
30%
35%
25 50 100 200 25 50 100 200 25 50 100 200
Control Overhead Passive Participation Active Participation
% o
f Tota
l W
irele
ss E
nerg
y
TX
RX
ACM MOBISHARE 13
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 14
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 15
Reclaiming Idle Power in 802.11 Ad-Hoc Mode
Node A
Beacon Interval
Node C
Node B
ATIM ATIM ATIM
B
B
B
A
R
D
B Beacon A ATIM
R ATIM ACK
D Data
P Data ACK
P
A L A L LA
A: Active
L: Low Power
A
A
ACM MOBISHARE 16
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 17
Wireless Card Sleep Policy
Active Low Power
Wi > 1 seconds
Wt > 3 seconds
Can we use Chimera network manager for better energy savings?
Wi: Wireless Idle timeWt: Wake up timeouts for checking network state
ACM MOBISHARE 18
Energy Savings Impact of Various Wi
0
20
40
60
80
100
120
140
160
180
1 2 3 4 5
Idle-Timeout (seconds)
En
erg
y S
aved
(Jo
ule
s)
Control Overhead
Passive Participation
Active Participation
42% savings
26% savings
ACM MOBISHARE 19
Average Delay of Various Wi
0
0.2
0.4
0.6
0.8
1
1.2
1.4
1 2 3 4 5
Idle-Timeout (seconds)
Avg
Messag
e D
ela
y (
sec) Control Overhead
Passive Participation
Active Participation
ACM MOBISHARE 20
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 21
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 23
P2P on Mobile Systems
• Peer-to-peer paradigm:Decentralized, highly-scalable, fault-tolerant networks
• 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?
• P2P nodes are both clients and servers depending on context of operation.
P2P
ACM MOBISHARE 25
Most Expensive Functions
0123456789
10
ChkLe
afse
t
Chim
J oin
Rout
e
RtNei
gh
RtUpd
t
RtGet
Tabl
e
Ntwor
kSnd
NetwkA
ctiv
Misc
.
RtRow
Lkup
RtLk
up
Energ
y C
onsum
ed
(Jo
ule
s)
CPUWireless
ACM MOBISHARE 26
Jabber
Jabber Server Jabber Server
Mobile Jabber Client
Mobile Jabber Client
In jabber, the peers communicate to each other using servers. Not exactly a P2P architecture
ACM MOBISHARE 27
JXTA
Rendezvous Server
Rendezvous Server
Mobile JXTA Peer
Mobile JXTA Peer
In JXTA, the peers has to ask rendezvous servers who provides the service.
Service advertisementService Discovery
ACM MOBISHARE 28
RockyRoad
Rendezvous Server
Rendezvous Server
Mobile RockyRoad Peer Mobile RockyRoad Peer
In RockyRoad, routing and service discovery protocols are designed by the developer. RockyRoad is an API.
Service advertisementService Discovery
Support for J2ME and J2SE exist!.
Default Protocols
Routing: Forwarding
Searching: Broadcasting
Developer Specific