triage: balancing energy and quality of service in a microserver
Post on 21-Mar-2016
20 Views
Preview:
DESCRIPTION
TRANSCRIPT
University of Massachusetts, Amherst
Triage: Balancing Energy and Quality of Service in a
Microserver
Nilanjan Banerjee, Jacob Sorber, Mark Corner, Sami Rollins†, Deepak Ganesan
http://prisms.cs.umass.edu/hpm
†University of San Francisco, San Francisco
Scenario : Deploying Remote Sensor Network
Imagine you want to deploy a large scale sensor network
What do you need ?lot of sensors of course also need powerful battery-powered server nodes
These nodes are traditionally called Microservers [Girod et al.]
What do these Microservers do ?can be used for routing, query processing or storagecan act as a web server, information kioskcan be used as a router
What does the Microserver Workload look like ?
Workload is often heterogeneous and sporadicsimple requests: store data, synchronize timecomplex requests: return all images with >2 objects
Microserver
MicroserverAcoustic Sensors
Video Sensors
Vibration Sensors
Sensor Node
Wireless Link
Conflicting Goals : Performance and Energy !
Microservers have high performancehighly responsive as a conventional serverprovide performance guarantees to applicationsshould have a powerful CPUshould have lots of RAM
Remember that microservers are untethered and battery poweredthey must be highly energy-efficient for longer lifetime however, powerful platforms implies more energy consumption !
How do we design microservers which balance performance and energy !
MicroserverEnergy
Efficiency Performance
Use a single tiered powerful platformuse PSM and DVFS on the powerful platformsystem suffers from the huge idle cost of the powerful tier
0 50 100 150 200 250 300 350 400 450 5000.5
1
1.5
2
2.5
Time (secs)
Pow
er C
onsu
med
(mW
)
Possible Approaches
Possible Approaches
Use a dual tier system (similar to Wake on Wireless [Shih et al.])tier-0 (Mote) as low power tier, tier-1 (Stargate) as a more powerful tierkeep Stargate in power down modewake Stargate whenever a task arrives at Motesystem suffers from a huge transition cost of Stargate
0 50 100 150 200 250 300 350 400 450 5000
0.5
1
1.5
2
2.5
3
Time (secs)
Pow
er C
onsu
med
(W)
Our Approach : Triage
Combine powerful platform (Stargate) and low power sensor (Mote)Try to amortize transition costs by batching tasks at the sensorThe tasks arriving should meet soft real time deadlines
accurately profile execution time for tasks wake the Stargate platform only for long batch of tasks if possible execute simple tasks on the Mote
0 100 200 300 400 50000.5
11.5
22.5
3
Time (sec)
Pow
er C
onsu
med
(W)
OutlineDesign goals governing the Triage systemOverall Triage ArchitectureTriage components
surrogates profilerscheduler
Triage PrototypeExperimental Setup and EvaluationRelated Work and Conclusions
Design Goals
Triage architecture should be generalapplicable to microservers in wide variety of networks
Triage should be highly responsive to tasks
Triage should provide soft real time QoS guarantee
Triage should be highly energy efficientmaximize lifetime while meeting QoS guaranteesmeet lifetime constraints while providing QoS guarantees
Triage Software Architecture
Tasks arrive at tier-0 (Mote), tier-1 (Stargate) is in low power modeSurrogate services execute tasks or batch (log) them for Stargate Profiler calculates the amount of energy and time taken by a taskScheduler decides when to wake Stargate
Storage Surrogate
Query ProcessingSurrogate
Delayed Request Log/ Cache
Wakeup Control
Forwarding Surrogate
Profiler QoS Scheduler
Tier-0 Subsystem (Mote)
Network Requests
Task 2 Task 1
Hardware Power Measurement
Tier-1 Subsystem (Stargate) Task Execution
SurrogatesStorage Surrogate
enables in-network storage applicationsaccepts reads, writes, and delete requestsrequest are either served from the cache or inserted into log
Query Processing Surrogateprovides query interface for data stored on the microserver queries could be simple or complexeither queries are served from tier-0 or are inserted into log
Forwarding Surrogateefficient routing using tier-0 and tier-1 network interfacesdetermines which radio should be used to send the packetif tier-0 radio is used, packet send immediately
ProfilerMeasures the typical execution time and energy usage of tasks
measurements done through hardware assisted profilingtypical execution time : p % of the requests are likely to be satisfied
Online profiling involves two stepstask grouping – classify tasks based on the nature of taskparameter estimation
Parameter Estimation is the probability distribution of time taken by task
and are the mean and variance of the distribution applying Chebyschev’s inequality execution time of task is bounded by
)( itf
X
SchedulerUses information about tasks from the profiler
Schedules tasks to minimise the number of Stargate wakeups
We could use different scheduling algorithms under different scenarios the focus might be to meet maximum deadlines using minimum energy the aim make the batteries last for a 100 days
Triage uses two example schedulers depending on optimization criterion deadline scheduler : meets maximum deadlines at minimum energy lifetime scheduler : satisfy lifetime constraint and meet max deadlines
Example Scheduler : Deadline Scheduler
Scheduler first queries the profiler for execution time for taskAlgorithm then computes the Batch time (B )
batch time at which Stargate can be woken upall tasks and the new task meets its deadline
Let the new task be inserted at position of the sorted listFor each task , sets the latest start time
New Batch time is equal to B = B – L(Ti)
If B less than or equal to 0 tier-1 is woken up else tier-1 wakeup timer fires after time B
)( iTLiT li1
)}()(),(min{)( 1 iiii TETLTLTL
Deadline Scheduler : ExampleLet there be two batched tasks TA: deadline=60 sec execution=3 sec TB: deadline=64 sec execution=3 sec L(TA) = 57 sec L(TB) = 61 sec B = 50 secNew task TC arrives TC : deadline=62 sec execution=3 secTask is inserted between TA and TB
Pushes task TA forwardNew Batch time B = 48 sec
EB=3D=64L=61
EA=3D=60L=57
64 61 5760
W=7
50
B=50
0
EB=3D=64L=61
EA=3D=60L=55
64 61 5558
W=7 B=48
048
EC=3D=62L=58
Example Scheduler : Lifetime Scheduler
Microserver generates tokensrate of energy constraint
Calculate energy for present batch
If energy greater than tokens collecteddo not wake the Stargate
Else wake Stargate to execute batch
new new tokenstokens
Battery Capacity
?
Tasks
Batch Taken
Decide Wakeup of Tier-1
OutlineDesign goals governing the Triage systemOverall Triage ArchitectureTriage components
surrogates profilerscheduler
Triage PrototypeExperimental Setup and EvaluationRelated Work and Conclusions
Triage Prototype
StargateTelosB
Power Profiling Board
Battery
Evaluating TriageDoes Triage have power savings over other systems
single tiered system which uses PSM and DVFS (PSM-DVFS)dual tier system based on the Wake-on-Wireless (WoW*)dual tier system which used batching at tier-0 (Triage-Batch)
What benefit do tier-0 surrogates provide ?
How does the profiler perform ?
Do the scheduler algorithms meet their objective ?
What are the potential bottlenecks in the Triage system ?
Experimental Setup : Camera Sensor Network
CLIENT
BASE STATION
MICROSERVER
SENSOR CAMERA
802.15.4 Link
802.11b Link
HELP
ALPHA
SHIFT
ENTERRUN
DG ER FI
AJ BK CL
7M 8N 9O
DG DG DG
DG T 3U
0V .WX Y Z
TAB
% UTILIZATION
HUB/MAU NIC
2BNC4Mb/s
NI-PCI 6251 DAQ
TelosB motes act as sensor camerasTelosB and laptop acts as client generating image requests for the microserver
Power measurements taken using a NI-PCI 6251 DAQClient equipped with both 802.11b and 802.15.4 radios
Profiler Performance
Triage consumes slightly more energy than a batching system
Images arrive at constant rateQueries arrive at a regular rate
100 150 200 250 3000
200
400
600
800
1000
1200
Average Latency Constraint (sec)
Ave
rage
Pow
er C
onsu
med
(mW
)
TriageTriage-Batch
Profiler Performance
Triage system meets more than 90% of all the deadlinesTriage-Batch meets less than 75% of the deadlines
100 150 200 250 3000
0.1
0.2
0.3
0.4
0.5
0.6
0.7
0.8
0.9
1
Average Latency Constraint (sec)
Perc
enta
ge o
f Dea
dlin
es m
et
Triage
Triage-Batch
Lifetime Scheduler Performance
0 10 20 30 40 50 600
10
20
30
40
50
60
70
80
90
100
Time (minutes)
Bat
tery
Cap
acity
Rem
aini
ng (m
Ah)
Lifetime ConstraintTriageWoW*PSM-DVFS
Triage meets the lifetime constraint WoW* and PSM-DVFS batteries die long before the
deadline
Initial battery capacity = 100 mAh , lifetime constraint = 1hr First 30 mins : tasks with long deadlines, 30-60 mins : tasks with short deadlines
System Bottlenecks
The USB transfer energy is a huge bottleneck on Triage !
Triage leads to 300% improvement in battery lifetime
Triage WoW* PSM-DVFS0
200
400
600
800
1000
1200A
vera
ge P
ower
Con
sum
ed (m
W)
TelosBSuspendTransitionUSB-TransferWifi+computeStargate-idle
Related WorkWake-On-Wireless [Shih et al.]
low-power radio receives wakeup messagesrequires in-network supportfocus on when to wake up
Wireless optimizations [Anand et al.]Disk Spindown [Helmbold et al.]Multiple radios [Pering et al.]Multiple processor cores [Mayo & Ranganathan]
none provide orders-of-magnitude scaling of powerm-Platform [MSR06-142], LEAP [IPSN06] and LEAP2
heterogenous stack-based sensor network platformno intelligent profiling or scheduling to decide high power tier wakeups
Microserver platforms throwboxes [infocom 07]
Conclusions
We presented Triage : a highly capable, energy efficient microserver
Triage uses Hierarchical Power Managementintegrate multiple independent platformspass control between tierssuspend unneeded tiers
Triage leads to 300% improvement in battery lifetimeTriage meets all lifetime goals and provides probabilistic QoSTriage used for building highly energy efficient microservers
application in sensor deployment, mobile computing
University of Massachusetts, Amherst
Triage: Balancing Energy and Quality of Service in a
Microserver
Nilanjan Banerjee, Jacob Sorber, Mark Corner, Sami Rollins†, Deepak Ganesan
http://prisms.cs.umass.edu/hpm
University of San Francisco, San Francisco
top related