23.9.2010

T-110.5111 Computer Networks II Energy efficiency 17.11.2014 Matti Siekkinen

Outline

•  Motivation •  Measuring energy •  Modeling energy consumption •  Optimizing energy consumption

Green ICT

Source: Google image

What is Green ICT?

•  Green ICT –  Reduce the energy

consumption of ICT

•  What’s involved? –  Networked Equipment

•  PCs, mobile phones, data centers, set-top boxes...

–  Network Equipment (infrastructure)

•  Routers, switches, wireless access points…

Why we give a damn

•  ICT energy consumption –  About 12% of global power consumption –  60billion KWh wasted by inefficient computing every year –  Telecom data volume increases approximately by a factor of 10

every 5 years, which corresponds to an increase of the associated energy consumption of 16-20% every year

•  CO2 –  At least 2% of global CO2 emission –  As much as airplanes, and ¼ of cars

•  €€¥££ –  Data center and network operators –  Large part of operation costs

Another viewpoint: Quality of experience

•  Energy constrained devices –  Smartphones

•  Need to recharge more and more often –  Sensors and sensor networks

•  Don’t want to or cannot change batteries often

•  Quality of experience and availability issue –  Not directly about money –  Not so much a ”greenness” issue either

•  Although scale is very large... •  Mobile network infrastructure draws far more power than the

phones

•  We focus today mostly on these issues

Some questions worth asking

•  How much energy does it cost when you –  make a phone call, –  watch YouTube, or –  send an email?

•  How much of that energy could be saved? •  How to achieve these energy savings?

7

Outline

•  Motivation •  Measuring energy •  Modeling energy consumption •  Optimizing energy consumption

Power measurement

•  System-level power measurement Measure the total power consumption of the whole mobile phone.

•  Component-level power measurement

9

Measuring with software

•  Simplest way to measure •  Nokia Energy Profiler

–  Easy to use –  Sampling frequency is low (4Hz) –  Get accurate information about, e.g.

voltage(V), current(Am) •  Measured error just a few % in active cases,

more for low power cases (idle) –  Only for Symbian L

10

Measuring with software (cont.)

•  PowerTutor –  A power monitor for Android-based mobile

platforms –  Uses models to estimate power

consumption •  Accuracy may vary depending on usage

(check their paper for details)

•  Many other model-based profilers have been developed –  Serious ones are mostly research

prototypes –  App stores are full of apps with no certainty

of accuracy

11

Glance at the power consumption

12

(5,2.249)

(10,1.281)

(113,1.494)

(211,2.516)

0.000

0.500

1.000

1.500

2.000

2.500

3.000 1

5

10

15

20

25

30

35

40

45

50

55

60

65

70

75

80

85

90

95

10

0

105

11

0

115

12

0

125

13

0

135

14

0

145

15

0

155

16

0

165

17

0

175

18

0

185

19

0

195

20

0

205

21

0

215

22

0

225

23

0

235

24

0

243

24

5

249

Pow

er(W

att)

Time(second)

WLAN WCDMA

Watching YouTube from N95

? ?

?

Using external instruments

13

Power measurement

•  System-level power measurement Measure the total power consumption of the whole mobile phone.

•  Component-level power measurement

Example: Given a mobile phone, measure the power consumption of each CPU, network interface, and display separately.

14

Component-level power measurement

•  Requires information about power distribution network at the circuit level

•  Very few off-the-shelf devices can be measured on component-level –  e.g. Openmoko Neo Freerunner –  See: Aaron Carroll and Gernot Heiser. An analysis of

power consumption in a smartphone. In Proceedings of the USENIXATC 2010.

15

Outline

•  Motivation •  Measuring energy •  Modeling energy consumption •  Optimizing energy consumption

Where does the energy go?

•  Hardware consumes the energy

•  Amount of energy consumed depends on –  Hardware physical

characteristics –  Hardware operating mode –  Workload generated by

software running on top of hardware

17

Power modeling

•  Allows to estimate energy/power consumption even when direct measurement is impossible –  Impractical: external instruments usable only in lab settings –  Software not available

•  Why interesting? –  Understand and improve energy consumption behavior of

existing protocols and services •  Also in setups which aren’t possible in a lab •  Help redesign for better energy efficiency

–  Develop energy-aware protocols and applications •  Run-time estimation of energy consumption •  E.g., choose energy efficient paths, peers, servers

•  18

Power modeling (cont.)

•  Power models describe –  Transmission energy, computational energy, other energy

expenditure –  Power consumption of each hardware component or software

component –  Power consumption of a service

•  Methodology –  White box modeling –  Black box modeling

Power measurement is needed for both methods.

19

Example: Transmission energy

•  Which one consumes less energy? –  3G, WLAN, or LTE? –  Lumia 920 or iPhone 5? –  P2P or C/S? –  ...

•  No simple answers...

20

Transmission energy metrics

Two metrics •  How many Joules are needed for transmitting or

receiving one Bit (energy utility)? –  Not constant –  Depends on how you send or receive the data –  Depends on how you control the operating mode of the network

interface –  Contextual dependency

•  E.g. poor signal strength requires more transmit power

•  How many Bits do you need to transmit or receive? –  In bad network conditions, you also need to consider the power

consumed by data retransmission (TCP)

21

Transmission: WNI states and transitions •  Radio access resource management is the key to understand

–  Link layer protocols, esp. MAC sublayer –  Determines how the radio is used (à when powered on) –  This is technology specific à Wi-Fi, 3G, LTE all differ

•  The resource management protocols defines different states for the UE –  Usually timer specified transitions between states –  E.g. receive, idle, and sleep in WiFi –  CELL_DCH, CELL_FACH, CELL_PCH for 3g

•  Correspond to different transport channels •  Determines how frequently radio must listen to the physical channel

•  States have different power characteristics –  Part of circuitry can be powered off at run time (sleep)

Wi-Fi, 3G, LTE: different power states

SLEEP

TRANSMIT

IDLE

RECEIVE PSM

Timeout

Traffic burst

RRC Inactivity timer running

RRC_IDLE

CHAPTER 2. LTE 13

For real-time streaming applications such as voice calls, the data sentduring every transmission and the bandwidth utilized are very small. Forapplications transmitting small amount of data for many times semi persis-tent scheduling is more adaptable in which the UE does not need to requestfor a Grant each time for transmission of data. Instead, the UE is providedwith a transmission pattern which it follows and transmits the data duringthat particular time slot. For example, during a voice call the UE sends aninitial SR and gets the transmission pattern from the scheduler after whichthe data is sent on the allocated time. This reduces the complexities andoverhead of the scheduler and the UE.

There are many di↵erent types of scheduling algorithms which are de-signed based on the need of vendors. Commonly used algorithms includeRound Robin [42], Proportional Fair [47], Maximum Channel Quality Index(CQI) [43], Channel aware scheduling algorithm [42].

2.3 LTE UE and RRC States

In LTE, a UE can shift between three states namely, RRC DISCONNECTED,RRC CONNECTED and RRC IDLE.

Figure 2.4: States of LTE UE

Initially, when the UE is in the OFF state, it does not hold any ac-tive connection with the eNodeB. The state at which the UE is turned onand is searching for a possible base station for registration or the phasewhen the UE is in Airplane mode could be termed as RRC DETACHED

Transmission: Tail energy

•  All wireless network interfaces exhibit tail energy –  Energy spent being idle with radio on à “wasted” energy

•  Due to inactivity timers –  How long UE waits (continuous rx) without receiving any packets before

switching to lower power state (only periodic rx) •  Timers decrease delay and limit signaling

–  Too short timers cause nasty delay for non-continuous traffic •  Packets need to wait until UE powers radio on again (periodically) after

timer has triggered and UE transitioned in lower power state –  State transitions may require exchange of signaling msgs between UE

and base station •  Timer values vary between technology

–  Wifi≈100-200ms, 3G≈11s, LTE≈10s –  Cellular timers are network controlled and depend on ISP config

How to minimize tail energy

•  Can’t get rid of timers because of other performance issues

•  Wi-Fi tail short à no need to optimize •  3G has Fast Dormancy

–  Phone requests the network to transition to CELL_PCH –  Network maintains control and allows or denies (e.g. too

frequent requests) –  Cuts tail duration down to 3-5s

•  LTE has DRX/DTX (discontinuous reception/transmission) –  3G has also CPC (continuous packet connectivity) which is

similar (not (yet) fully supported by deployed networks)

How to minimize tail energy (cont.) •  DRX works in LTE’s connected state

–  Hence, also called cDRX (connected mode DRX)

•  DRX operates in cycles –  Check periodically if new data is waiting –  Very similar to PSM in 802.11

2

RRC IDLE.

Fig. 1. States of LTE UE

Initially, when the UE is in the OFF state, it does not holdany active connection with the eNodeB. The state at which theUE is turned on and is searching for a possible base stationfor registration or the phase when the UE is in Airplane modecould be termed as RRC DISCONNECTED state. Once theUE finds base station coverage, it registers to the MobilityManagement Entity (MME) through the LTE Attach proce-dure. After the registration is successful, the UE moves to theRRC CONNECTED state. In the RRC CONNECTED state theUE has a Radio Resource Control (RRC) connection with theeNodeB and maintains an active connection through varioussignaling messages. Once the UE sleeps for a longer durationwithout any data transmission, it moves to the RRC IDLEstate after the expiry of inactivity timer (Inactivity). Whenthe UE is out of coverage area, or during the process ofarea update it de-registers with the eNodeB and moves toRRC DISCONNECTED state.

DRX is the power saving mechanism in LTE, that wasintroduced in order to reduce the power consumption bymaking the UE to move to sleep and idle states when thereis no data transmission to and from the UE based on specifictimers.

In order to obtain information about scheduling, the UserEquipment (UE) monitors the physical down-link controlchannel (PDCCH) information every TTI. Performing thisevery TTI consumes lot of energy as the UE wakes up veryfrequently even though there is no scheduled data for it toreceive. Hence in order to have a solution for overcoming thisissue, Discontinuous Reception (DRX) was introduced. DRXis a proprietary power saving mechanism for LTE, throughwhich the User Equipment (UE) is made to sleep for a longerduration by shutting its wireless RF modem off for a maximumpossible time without compromising the Quality of Service(QoS), latency and user experience. The explanation for DRXin LTE 3GPP was first released with T.36.300, Release 8.

DRX is configured on the UE by Radio Resource Control(RRC) [?], i.e. the eNodeB, which provides the informationon various parameters and its timer values based on which theUE wakes and listens to the PDCCH control information. Themost important part is that, a LTE device can move to DRXstate in both RRC CONNECTED mode and in RRC IDLEmode.

When DRX is deactivated in the network, the UE listens toevery sub frame in the RRC CONNECTED mode. On expiryof inactivity timer, the UE moves to RRC IDLE mode. With

DRX being activated, the transmission and reception of datahappens in the RRC CONNECTED mode. When the UE doesnot receive any data for a certain time, it enters the DRX cyclephase and activates the Short DRX cycle with Short DRXtimer (Ts). In the Short DRX cycle state, the UE monitors thePDCCH during the DRX OnTimer period.

Fig. 2. RRC State transition of LTE UE

The Short DRX timer is active for a time period called asthe Short DRX timer period (TS)after which the UE activatesthe Long DRX timer (Tl). In Long DRX cycle, the wakeupduration of the UE for monitoring the PDCCH is less frequentthan the Short DRX cycle. Once the UE enters the Long DRXcycle, it shifts from the RRC CONNECTED to RRC IDLEmode if the Inactivity timer expires. When the UE gets anintimation about data to be received through the PDCCH, orwhen it needs to transmit data, it moves from RRC IDLEmode to RRC CONNECTED mode. Once all the data istransmitted, the UE again activates the DRX cycle in theRRC CONNECTED mode and then moves to the RRC IDLEmode after inactivity timer expiry.

Fig. 3. LTE DRX

A. OnDuration Timer

On Duration, is the time period an UE is awake for listeningto the PDCCH frame that specifies whether it has any down-link data transfer to happen. It happens during the start of aDRX Long cycle, DRX Short cycle and spans the durationspecified for the timer. After the end of OnDuration, the UEgoes to the sleep mode if there is no DL data assignment ortriggers the inactivity timer if it has a DL data assignment inthe near future.

arriving data

DRX inactivity timer (DRXidle)

DRX cycle (DRXc)

RRC inactivity timer (Tidle)

CONNECTED STATE IDLE STATE Rx on

Rx off transition

to Idle DRX on-duration

timer (DRXon)

Case study 1: White box modeling

Power modeling of data transmission over 802.11g

•  Xiao, Y., Savolainen, P., Karppanen, A., Siekkinen, M., and Ylä-Jääski, A. Practical power modeling of data transmission over 802.11g for wireless applications. In Proceedings of the e-Energy 2010.

27

Power consumption of 802.11 wireless network interface (WNI)

•  Power consumption depends on operating mode Energy = Power(operating mode)* Duration(operating mode)

28

Continuously Active Mode (CAM)

Power Saving Mode(PSM)

IDLE

TRANSMIT RECEIVE

SLEEP PS

TRANSMIT PT

IDLE PI

RECEIVE PR

PSM Timeout

Tsleep = TI - Ttimeout

WNI operating modes and power

•  Order of magnitude less power drawn in sleep state

WNI operating mode Average Power (W)

Nokia N810 HTC G1 Nokia N95

IDLE 0.884 0.650 1.038

SLEEP 0.042 0.068 0.088

TRANSMIT 1.258 1.097 1.687

RECEIVE 1.181 0.900 1.585

Operating modes and traffic patterns

•  Problem: No common open API for querying the current operating mode

•  Idea: Estimate the operating modes & durations from observed traffic patterns –  Take into account 802.11 Power Saving Mode(PSM)

Figure: I/O graph of YouTube traffic (Byte/tick)

Per-burst computation

•  TCP style bursty traffic naturally fits to this model •  Reduce computational work

–  If CBR -> use 1 pkt bursts •  Definitions

–  Burst: Pkt interval < t •  t is a predefined threshold

–  Burst size SB –  Bin rate r = SB/T = SB/(TB+TI)

•  31

Burst Duration TB

Burst Interval TI

Packet Interval

Taking PSM into account

•  Scenario 1: no time to sleep between bursts

E = PRTB+ PITI

Pd(r) = E/T = PI + r(PR – PI) TB/SB

•  Scenario 2: catch some sleep in between bursts

E = PRTB+ PITtimeout + PSTsleep

Pd(r) = E/T =PS + r[(PR – PS) TB/SB+ (PI – PS) Ttimeout/SB]

Time

PR

PI

TB TB+ TI

Power

Time

PR

PI

TB TB+ TI

Power

TB+ TI+ Tsleep

Trying out model: power vs. throughput

33

0.0 0.2 0.4 0.6 0.8 1.0 1.2

0 32 64 96 128 160 192 224 256

Avg

Pow

er(W

)

Data rate limit(KB/s)

Download, CAM

Measured

Estimated

0.0 0.2 0.4 0.6 0.8 1.0 1.2

0 32 64 96 128 160 192 224 256

Avg

Pow

er(W

)

Data rate limit(KB/s)

Download, PSM

Measured

Estimated

Q: What’s this?

A: Effect of PSM: manage to catch sleep in between packets/bursts when rate is low enough

When rate ≥ 64KB/s, PSM has no effect!

Measurements using Nokia N810

N810: Energy utility

•  How many bytes can be transferred per Joule spent •  Roughly linearly dependent on throughput à should always transmit as fast as possible!

11

10

15

20

25

30

35

40

45

50

16 16(PSM) 32 32(PSM) 16 16(PSM) 32 32(PSM)

Ener

gy U

tility

(KB/

J)

Data rate(KB/s)

Measured(N810)Estimated(N810)

Measured(N95)Estimated(N95)

(a) On N810 and N95(16-32KBps).

40 60 80

100 120 140 160 180 200 220 240

64 96 128 160 192 224 256

Ener

gy U

tility

(KB/

J)

Data rate(KB/s)

Measured(N810)Estimated(N810)Measured(N95)Estimated(N95)

(b) On N810 and N95(64-256KBps).

0

100

200

300

400

500

600

700

16 32 64 96 128 160 192 224 256

Ener

gy U

tility

(KB/

J)

Data rate(KB/s)

Measured(G1)Estimated(G1)Measured(Nexus S)Estimated(Nexus S)

(c) On HTC G1 and Nexus S

Fig. 5. Energy utility of TCP download with single flow at rate between 16KBps and 256KBps.

10

15

20

25

30

35

40

45

50

16 16(PSM) 32 32(PSM) 16 16(PSM) 32 32(PSM)

Ener

gy U

tility

(KB/

J)

Data rate(KB/s)

Measured(N810)Estimated(N810)

Measured(N95)Estimated(N95)

(a) On N95 and N810(16-32KBps).

40 60 80

100 120 140 160 180 200 220 240 260

64 96 128 160 192 224 256

Ener

gy U

tility

(KB/

J)

Data rate(KB/s)

Measured(N810)Estimated(N810)Measured(N95)Estimated(N95)

(b) On N95 and N810(64-256KBps).

0

100

200

300

400

500

600

700

16 32 64 96 128 160 192 224 256

Ener

gy U

tility

(KB/

J)

Data rate(KB/s)

Measured(G1)Estimated(G1)Measured(Nexus S)Estimated(Nexus S)

(c) On HTC G1 and Nexus S.

Fig. 6. Energy utility of TCP upload with single flow at data rate from 16KBps to 256KBps.

500

1000

1500

2000

2500

512 1024 1536 2048 2854(no-trickle)

Ener

gy U

tility

(KB/

J)

Data rate(KBps)

MeasuredEstimated

(a) TCP download.

500

1000

1500

2000

2500

512 1024 1536 2048 2854(no-trickle)

Ener

gy U

tility

(KB/

J)

Data rate(KBps)

MeasuredEstimated

(b) TCP upload.

500

1000

1500

2000

2500

512 1024 1536 2048 2854(no-trickle)

Ener

gy U

tility

(KB/

J)

Data rate(KBps)

MeasuredEstimated

(c) TCP download and upload.

Fig. 7. Energy utility of TCP download/upload on Nexus S. The X-axis represents the aggregated data rate of all theTCP flows. The biggest value on the X-axis is the maximum throughput achieved without any rate limit. Each datapoint shows the mean and the standard deviation of the measured or the estimated Power.

TABLE 9MAPE of power models for Nexus S

No. No. MAPE No. No. MAPEdownlink uplink (%) downlink uplink (%)

1 0 3.4±2.0⋆ 0 1 2.6±1.5⋆4.2±1.7 4.1±4.4

2 0 3.3±1.7⋆ 0 2 2.9±2.0⋆2.4±1.1 0 2 5.1±4.0

4 0 2.9±2.0 0 4 5.1±1.58 0 2.2±1.4 0 8 5.9±1.81 1 2.1±1.8⋆ 1 1 2.7±1.92 2 5.0±2.8 4 4 4.8±2.1

⋆ The display was turned off. The data rate was between 16 and256KBps.

As shown in Fig. 7, the standard deviation is very smallcompared to the value of the mean. As the processingoverhead for maintaining more TCP flows is includedin the measured Power, the small standard deviation ofthe measured Power shows that the processing overheadcan be safely ignored. Fig. 7 also shows that the powermodels presented in Section 3 can provide generally ac-curate energy estimation of TCP transmission, regardless

of the number of TCP flows.

5.4 TCP Download/Upload in Congested NetworkWe connected the Nexus S to a public AP in our cam-pus and measured the power consumption during TCPdownload and upload. The phone tried to send/receivedata as fast as possible without any data rate limit ortraffic shaping. Due to the interference caused by theneighbouring APs, MAC layer retransmissions couldnot be left ignored. Based on the collected MAC layertraffic traces, we calculated the retransmission ratio Rr

and the expected value of retransmitted packet intervalE(Tir). The samples of retransmitted packet intervalsused for calculating E(Tir) seem to follow the InverseGaussian distribution. The overhead of retransmittingpackets was computed following (22). Because the CPUfrequency was always 400MHz during the measurement,no extra cost was caused by DVFS. The final resultsare shown in Table 10. In upload cases, taking intoaccount the retransmission overhead can improve thepower estimation accuracy by almost 50%.

Download (PSM)

Measurements using Samsung

Nexus S

Case study 2: Black box modeling

•  A system-level power model –  Include main components

•  Processors, wireless network interfaces, display –  Build using system-level measurements

•  Difficult to measure components separately –  Generic model

•  Not tied to specific application

•  Statistical modeling using linear regression –  Impossible to track exactly what happens e.g. within CPU –  Must treat the system as a black box and use statistical

methods to build model –  We use some a-priori knowledge (model variable selection)

35

Modeling power with Linear Regression

•  Linear regression widely used for processor power modeling –  Build a linear relationship between the p predictor variables and

power consumption based on n observations

•  Need to: –  select regression variables (we use a-priori knowledge here) –  train the model (least squares fitting) –  evaluate the model

∑ =+= p

1j jijj0i xgyf )()( ,ββ

predictor variables

variable coefficients

preprocessing function

intercept

Regression variables

•  Target: reflect resource consumption of a mobile application –  Diverse, capture all components

•  Computation: Hardware performance counters (HPC) –  Set of special registers in modern CPUs –  17 counters about hardware-related activities (CPU activity,

memory access) –  We chose eventually only 3 of them (limited monitoring capabilities)

•  Network I/O –  Download data rate –  Upload data rate –  CAM switch: Effect of 802.11 power saving mechanism

•  Display –  Brightness level

Model training and evaluation: input data

•  Need data for both training and evaluation –  Must not use same data set for both!

•  Desired data characteristics: –  Should activate all the different hardware components –  Produce heterogeneous workloads to hardware àUse different kinds of smartphone applications (video player, file dl, idle, camera app…)

•  What to collect from test cases? –  Regression variable values: monitor with software

•  the X in the equation –  Power consumption: plug device to external power monitor

•  the Y in the equation

Model training

•  Find out model coefficients using (non-negative) least squares fitting: –  Standard minimization problem –  Use existing tools (e.g. Matlab)

∑ = −= n

1i2

iip0 yfyS ))((),...,( ββ

€

Power(W ) = 0.7655 + 0.2474 × g0(x0) + 0.0815 × g1(x1)+ 0.0606 × g2(x2) + 0.0011× g17(x17)+ 0.0015 × g18(x18) + 0.3822 ×g19(x19)+ 0.125 × g20(x20).

CPU_CYCLES DCACHE_WB

TLB_MISS dl rate

ul rate CAM switch

brightness level

Model evaluation

40

4.8

2.0 3.7

0.2

13.7

3.8

0.8

0 2 4 6 8

10 12 14

Radio LiveTV YouTube Audio recorder

Video recorder

upload download

Median Error(%)

•  Finally, need to evaluate accuracy of the model •  Evaluation based on similar data used for model fitting

–  But not the same!

failed to capture video camera

impact

Outline

•  Motivation •  Measuring energy •  Modeling energy consumption •  Optimizing energy consumption

How to save energy?

1.  Switch off unnecessary hardware

2.  Reduce the Joule per Bit, per Cycle, per instruction

3.  Reduce the workload –  Amount of bytes to transmit –  Number of instructions to execute

42

Switch off unnecessary hardware Not working = Zero Watt

•  What can be turned off?

•  When can it be turned off?

•  How to leverage the difference in power consumption among the operating modes?

43

Example 1: Sleeping

•  Save network equipment (i.e. routers) energy –  PSM equivalent for WLAN clients

•  Observation 1: Networks are provisioned for peak load –  Average utilization remains relatively low

•  Observation 2: Routers and switches are usually far from energy proportional –  Roughly the same power draw with any load

•  Idea: turn (parts of) lightly loaded routers off occasionally –  Power draw is somewhat proportional to nb of active ports –  Switch off some routers and route traffic around

12/11/14

Sleeping routers

•  Time driven sleeping –  If router sleeps when packets arrive -> packet loss

•  Need to carefully consider when a link can sleep

•  Wake on arrival –  Link sleeps when idle, awakes upon arriving packet, goes back

to sleep –  Require specific technology

•  Not currently implemented in OTS routers

•  These mechanisms are currently on research level –  Not commercially deployed (AFAIK)

12/11/14

Example 2: Wake-on-LAN

•  Reduce the energy consumption of networked equipment –  E.g. workstations within an enterprise network

•  Go to sleep while idle •  Q: When to wake up? •  A: Proxy sends a “magic” packet that triggers wake-

up –  Some part of NIC must remain powered up –  Requires explicit support from the NIC

•  Optimize further: Proxy handles some traffic on behalf of sleeping host –  No need to wake up host for each request –  Proxy replies on behalf of the sleeping host

•  Wake-on-Wireless-LAN also exists

•  46

How to save energy?

•  Can we just turn off unnecessary hardware?

•  Can we reduce the Joule per Bit, per Cycle, per instruction?

•  Can we reduce the workload (e.g traffic size)?

47

Reducing per-unit power consumption •  Low-power hardware

–  Necessary especially in longer term

•  Power management of hardware devices –  E.g. DVFS (CPU), PSM (Wi-Fi) –  Important that protocols leverage these properly!

48

Example 3: Dynamic voltage and frequency scaling (DVFS) •  Dynamic power(switching power) of microprocessor

C·V2·f, –  C=capacitance being switched per clock cycle, V=voltage, and

f=switching frequency •  DVFS

–  Adjust the CPU frequency level on-the-fly based on workload –  Reduce dynamic power –  Reduce the cooling cost (generate less heat)

•  Both voltage and frequency usually adjusted simultaneously –  Combination is called P-state

•  Governors in smartphones control switching policies –  May have some impact on performance –  E.g. aggressive vs. timid

•  49

Dynamic Modulation Scaling (DMS)

•  Reduce communication energy per bit •  Trade-off between energy and data

rate –  Traditionally BER vs. data rate

•  Change modulation dynamically –  Slows down transmission in a certain rate

if MAX rate is not required •  Scale power consumption accordingly

–  Transmit power –  Frequency of electronic circuitry for

filtering, modulation, etc.

50

Energy delay tradeoff of QAM (b is nb if bits per symbol)

Dynamic resource scaling

•  In general, two opposing approaches exist –  “Race to sleep”

•  Idea is to use all available resources when have work to do •  Sleep rest of the time, i.e. get to sleep as fast as possible

–  Scaling proportionally •  Scale resource consumption all the time

•  Example: multimedia streaming –  Race to sleep: transmit data in bursts, sleep in between –  Scaling: transmit CBR traffic and adjust modulation to match the

stream rate

Example 4: Traffic shaping

•  Mobile media streaming drains battery quickly –  Constant bit rate multimedia traffic is not energy friendly –  Forces the network interface to be active all the time

•  Idea: Shape traffic into bursts so that it is more energy efficient to receive –  Remember the linear relationship with throughput –  “Race to sleep”

12/11/14

Datarate (kBps)

Start-up Time (s)

WLAN power (W) 3G power (W)

PSM CAM 48kBps 2Mbps

8 18 0.53 1.06 1.30 1.30 16 10 0.99 1.07 1.30 1.30 24 10 1.04 1.07 1.27 1.35

Mobile Internet Radio power draw on E-71 (TCP-based streaming)

Traffic Shaping with Proxy

•  Client sends request to proxy •  Proxy

–  forwards request to radio server –  receives and buffers media stream –  repeatedly sends in a single burst to client

•  802.11 –  PSM is enabled –  WNI wakes up to receive a burst at a time –  Waste only one timeout per burst

•  3G & LTE –  Long enough burst interval à inactivity timers expire à switch to lower power state or activate DRX in

between bursts

53

What is the right burst size?

•  Use as large as burst size as possible –  Maximize sleep time in between bursts

•  Burst size that offer maximal energy savings exists –  Option 1: Due to limited buffer size at

mobile device •  Max burst size = playback buffer size

+TCP receive buffer size •  Larger burst will be received at stream

rate à lower energy utility –  Option 2: Max burst interval & size

limited by amount of initially buffered content

•  Cannot let the playback buffer run dry

How much energy can be saved?

•  Wi-Fi: 65% for audio streaming, 20% for video streaming •  3G: 36% for audio streaming, 30% for video streaming •  LTE: 60% for audio streaming, 55% for video streaming

App / Network type Samsung Nexus S (Android, 3G)

Nokia N900 (Maemo, 3G)

Nokia E-71 (Symbian, 3G)

HTC Velocity (Android, LTE)

Internet Radio/Wi-Fi 23%–128–14 s 62%–128–14 s 65%–128–6 s –

Internet Radio/3G/LTE 36%–128–14 s 24%–128–14 s 2%–128–4 s 60%–128–18 s

YouTube Bro/Wi-Fi 14%–912–36 s 20%–328 –39 s 18%–280–4 s –

YouTube Bro/3G/LTE 20%–328–38 s 14%–328–39 s 4%–280–3 s 50%-2000-31 s

YouTube App/ Wi-Fi 13%–458–39 s – – –

YouTube App/3G/LTE 27%–458–39 s – – 54%–2000–39 s

Dailymotion/Wi-Fi 15%–452–33 s – – –

Dailymotion/3G/LTE 30%–452–33 s – – 55%–452–33 s

cell info: energy savings(%)–stream rate (kbps)–optimal burst interval

How much energy can be saved? (cont.)

•  Savings depend largely on network type –  3G has long inactivity timers and no discontinuous reception

(yet)

•  Network parameters have also a large impact –  They determine the tail energy that can be saved

•  Stream rate matters as well –  Bursting lower rate stream yields larger savings

•  Smaller savings with video streaming compared to audio –  Display draws significant amount of power –  Video decoding is more work than audio decoding

How to save energy?

•  Can we just turn off unnecessary hardware?

•  Can we reduce the Joule per Bit, per Cycle, per instruction?

•  Can we reduce the workload (e.g traffic size)?

57

How can we reduce the workload?

•  Getting by with less traffic –  Clever transport protocols –  Smart application design

•  Doing less computation –  Offload the work

•  Trading transmission to computation

58

Example 5: Data compression

•  Communication energy consumption ~ Traffic size •  Compression can reduce amount of traffic generated

–  But computation costs also energy

•  Tradeoff always exists Communications

cost (reduced traffic size)

Computational cost

(compression, decompression)

Compression vs. communication

•  Compress ratio differs between data type –  Same work but varying savings in bytes

•  Must make decision beforehand whether compression would be beneficial –  Should we spend energy trying to compress or not? –  Must compare communication energy savings (compress ratio)

and energy to compress/decompress –  Can use model based estimates

•  Compression Effectiveness: ce

Evaluation (mobile E-mail)

61

File Extension/Type

With compression Without Compression ce

Energy (J)

Duration (s)

Energy (J)

Duration (s)

.doc 9.61 7.0 18.31 11.8 6.90

.bmp 5.86 5.4 15.74 9.7 2.67

.pdf 25.55 22.8 28.45 23.0 1.03

.txt 13.80 12.2 18.97 13.0 2.68 Binary data 12.8 11 17.57 11.8 2.68

10 – 60% energy savings

Example 6: Computation offloading •  Consider apps designed and implemented to be run on

standalone mobile OS •  Execute part of the application code in a remote machine

Smartphone

Offloading framework

app  

app  app  

app  

app  

app  

Remote server (Cloud)

Offloading framework

app  

app  app  

Mobile OS Mobile OS

Virtualization

callMethod()

return result

Offloading work to save energy •  Main objective is to save energy

–  Tradeoff: less computing with some extra communication –  Transfer state back and forth between smartphone and cloud

•  Often involves dynamic decision making because the tradeoff is not constant

•  May also improve other performance metrics (response time) –  High performance computing in cloud

Energy for communication

Energy for computation

Offloading frameworks •  Most rely on having source code available

–  MAUI at Mobisys’10 (Duke, UMass, UCLA, MSR) –  Cuckoo at MobiCASE’10 (Vrije Universiteit) –  ThinkAir at Infocom’12 (DT Labs, Cambridge, Nottingham, Huawei)

•  One modifies the underlying system (VM) –  CloneCloud at EuroSys’11 (Intel Labs)

•  Impressive results with computationally intensive apps –  45% energy savings for chess AI [MAUI] –  20x speedup and energy savings for a large image search

[CloneCloud] •  Augmented Reality is an interesting use case

–  Offload real time video and image processing to network (edge computing)

–  Apple’s Siri does this for NLP

What else could be done?

•  General computing –  Liquid cooling for servers, use the hot water to heat other

premises –  Run servers in (freezing) cold areas –  Compute things where energy is temporarily abundant

•  Energy storage is an issue, moving computation is easier

•  Mobile devices –  Smarter (cooperative) scheduling to reduce contention –  Leverage alternative low-power radios (e.g. Zi-Fi or Blue-Fi) –  Energy harvesting

•  Kinetic, solar, ambient radiation, … –  Detect and quarantine energy bugs

•  Check out Carat (http://carat.cs.berkeley.edu)

65

Summary

•  Energy efficiency is a hot topic for several reasons –  Saving energy means saving money (and natural resources) –  Battery operated devices benefit from energy efficient protocols

•  Measuring and modeling energy consumption necessary –  Understand how energy is consumed –  Improve energy efficiency of protocols and apps –  Develop energy aware protocols and apps

•  Several ways to save energy –  Switch off hardware dynamically –  Reduce joules per bit, per cycle, per instruction

•  Low-power hardware & smart power management –  Reduce workload

•  Trade some computation to communication

Want to know more?

•  Book out: –  S. Tarkoma, M. Siekkinen, E. Lagerspetz, Y. Xiao: Smartphone

Energy Consumption: Modeling and Optimization –  Published by Cambridge University Press in September –  At least one copy should be at the library