1 characterizing and conserving energy consumption in mobile p2p systems selim gürün priya...

28
1 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 September 25, 2006

Upload: kerry-mckinney

Post on 28-Dec-2015

215 views

Category:

Documents


0 download

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 22

Backup Slides

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 24

Wireless Card Power Consumption

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

ACM MOBISHARE 29

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