Une approche holistique pour l’informatique verte dans les ...Introduction Contribution 1 Contribution 2 Contribution 3 Contribution 4 ConclusionAnnexes Plan 1 Introduction 2 Localisation

Une approche holistique pour l’informatique vertedans les reseaux sans fil

Apport de la collaboration entre systemes autonomes pour unpartage efficace de ressources

Martin Peres

LaBRI, Universite de Bordeaux

19/12/2014

Introduction Contribution 1 Contribution 2 Contribution 3 Contribution 4 Conclusion Annexes

Plan

1 Introduction

2 Localisation des traitements dans les reseaux de capteurs

3 Partage efficace de spectre RF pour les communications sans fil

4 Gestion d’energie materielle autonome

5 Prise de decision energetique en temps reel

6 Conclusion

1 / 54


L’informatique verte : Un enjeu societal

Impact de l’informatique [1]

10% de la consommation electrique mondiale en 2007

10% d’augmentation chaque annee

0.82 Gtonnes de CO2 (1.43 Gtonnes predis pour 2020)[1] EPA, “EPA report to congress on server and data center energy efficiency,” Tech. Rep., 2007. [Online]

L’informatique verte

Reduire et maıtriser l’usage des ressources :

Energie

Radio frequence

2 / 54


Garantir la disponibilite des reseaux sans fil

L’informatique verte dans les reseaux sans fil

Augmente la disponibilite du reseau

Defi 1 : Reduire les echanges et garantir la capacite de com.

Protocoles efficaces et decentralises

Adaptation a l’environnement Radio Frequence (RF)

Defi 2 : Maximiser et garantir l’autonomie sur batterie

Conscience du support executif

Adaptation des performances / consommation

3 / 54


L’autonomie dans l’informatique verte

Besoin de l’informatique verte

Re-configuration frequente

Probleme : La ressource humaine

Explosion des systemes informatiques

Diminution des moyens humains

Vitesse de reconfiguration

Solution : L’informatique autonome

S’auto-configure : Assurer sa mission

S’auto-optimise : Diminuer sa consommation

S’auto-protege : Se defendre contre les intrusions

S’auto-repare : Corriger les problemes

4 / 54


Objectif de la these

Defi 1 : Reduire les echanges et garantir la capacite de com.

Decentralisation du traitement des donnees

Partage efficace du spectre RF

Defi 2 : Maximiser et garantir l’autonomie sur batterie

Gestion autonome de l’energie

Prise de decision energetique en temps reel

Approche Holistique

Contributions aux niveaux reseau, materiel et OS

5 / 54


Plan

1 Introduction





6 Conclusion

6 / 54


Les reseaux de capteurs ad-hoc

Reseau de capteurs ad-hoc

Collecte

Envoi / Routage

Traitement externe

Probleme : Le routage

Utilisation du spectre RF

Consommation energetique

Solution

Decentralisation des traitements

7 / 54


Exemple de reseau de capteurs ad-hoc : La surveillance

ANR DIAFORUSDIstributed Applications and Functions Over Redundant Unattended Sensors

8 / 54


Reseaux de surveillance (ANR DIAFORUS)

Propositions

Traitement separe :

detection localecorrelation de zone

Abstraction des capteurs

Correlation temporelle

Definition autonome du seuil

Sensornodes

Correlationnode Sink

alert alarm

t0 t0

threshold

criticalitylevel f(t)

t1 t2 t3t4 t5

9 / 54


Historique & reputation des capteurs

Historique

Stockage priorise

score(e) = criticity(e)∗local max time(e)

1− age(e)max storage time

Reputation des capteurs

Calcul interne au reseau

reputation false positive(a, s) = area detection count involving(a,s)sensor events count(s)

reputation false negative(a, s) = sensor correlated count(s)area detection count(a)

a : Numero de zones : Numero de capteur

10 / 54


Evaluation de l’approche

Approches de l’etat de l’art

Sink : Communication directe des capteurs vers la passerelle

Aggregation cluster : Centralisation des donnees avant envoi

Detection locale : Envoi seulement lors d’une detection

Type de WSN lectures courte-distance longue-distanceSink 5400 0 (0%) 5400 (100%)Aggregation cluster 5400 3600 (67%) 1800 (33%)Detection locale 5400 0 (0%) 540 (10%)DIAFORUS 5400 ≤ 540 (10%) < 180 (3.33%)

Table: Comparaison des differents types de reseaux avec une zone de 3noeuds et une probabilite de faux positifs de (p = 0,1; f = 1Hz)

11 / 54


Conclusion

Avantages

Reduit les emissions mais reste auditable

Auto-configuration : Ajout dynamique de capteurs

Auto-optimisation : Reputation des capteurs

Auto-reparation : Perte de noeuds

Inconvenients

Traitement differe impossible

Redondance necessaire

Complexite en cas de panne

12 / 54


Plan

1 Introduction





6 Conclusion

13 / 54


Communications dans les reseaux sans fil

Le spectre Radio Frequence (RF)

Medium partage

Vision locale de chaque noeud

Probleme : Les collisions

Interference entre deux messages

Genere des re-emissions

Peut etre limite : codes, FHSS et/ou CSMA/CA

Solution : La radio cognitive

Comprehension

Agilite

14 / 54


La radio logicielle

La radio logicielle

Acces au spectre RF

Largeur et frequence parametrables

Exemple : Le BladeRF de NUAND

Plage de frequences : 300 MHz to 3 GHz

Largeur de bande : 28 MHz Full duplex (40MSps)

Avantages

RX/TX multiples

Pile reseau totalement logicielle

15 / 54


Synchronisation des noeuds radio cognitive (CR)

CCC : Common Control Channel

Canal de synchronisation fixe et commun

Que faire quand il est indisponible ?

Synchronisation avant chaque trame (DMPJS10 [2])

Envoi d’une requete sur chaque canal, attente de l’ACK

Pas de RX/TX multiples, latence forte a chaque trame[2] : R. Doost-Mohammady, P. Paweczak, G. Janssen, and H. Segers, “Physical layer bootstrappingprotocol for cognitive radio networks,” in 2010 7th IEEE CCNC, Jan. 2010

Synchronisation avant communication (LLCL13 [3])

Algorithme pour maximiser les chances de rendez-vous

Pas extensible a plus de deux nœuds[3] : Z. Lin, H. Liu, X. Chu, and Y.-W. Leung, “Enhanced jump-stay rendezvous algorithm for cognitiveradio networks,” IEEE Communications Letters, vol. 17, no. 9, Sep. 2013

16 / 54


Schema global de notre utilisation de la radio logicielle

Figure: Vue generale du processus d’ecoute - Remplissage de la table desevenements radios depuis le flux d’echantillons de la radio logicielle

17 / 54


Proposition : Protocole de signalisation PHY

<beacon_frame>{ node_id=23, tx_pwr=10dBm,

[

{ {band1}, len=0.4, period_offset=0.0 },



],

period=1000ms, cur_period_offset=0.126 }

Synchronisation par beacon

Decouverte des voisins

Synchronisation temporelle

Affaiblissement du canal

18 / 54


Evaluation des protocoles de signalisation

0 2 4 6 8 10 12 14 16

DMPJS10

LLCL13

SW radios

HW radios

Time to Rendez-Vous (s)

Average TTR MTTR

Lower is better

Figure: Comparaison du temps moyen de rendez-vous (Average TTR) etdu temps maximal (MTTR) entre DMPJS10, LLCL13 et notreproposition sur une radio logicielle (25 MHz) et une radio materielle

19 / 54


Conclusion

Avantages

Auto-configuration : Decouverte des voisins

Auto-optimisation : Cycles de sommeil

Auto-reparation : Changement de bande

Inconvenients

Cout des radios logicielles

Contraintes legales

Cout energetique potentiel

Communications longue distance (SNR)

20 / 54


Plan

1 Introduction





6 Conclusion

21 / 54


La consommation electrique materielle

n+ n+

p

x

L

Source DrainGate

Body

Oxide

Consommation statique

Effet tunnel

Facteurs : temperature et tension

Consommation dynamique

Capacite interne

Pdynamic ∝ CfV 2

C : Capacite du transistorf : Frequence en Hz a laquelle le transistor change d’etatV : Tension d’alimentation du transistor

22 / 54


La consommation electrique materielle : NVIDIA GTX 660

(a) Prediction de 2003

18

20

22

24

26

28

30

32

34

36

38

30 40 50 60 70 80 90

Pow

er c

onsu

mp

tion

(W)

Temperature (°C)

Voltage = 0.8250 VVoltage = 1.2125 V

Cubic fit for Voltage = 0.8250 VCubic fit for Voltage = 1.2125 V

(b) Impact de la temperature

23

24

25

26

27

28

29

30

31

0.8 0.85 0.9 0.95 1 1.05 1.1 1.15 1.2 1.25

Pow

er c

onsu

mp

tion

(W)

Voltage (V)

boot freqboot freq fit

(c) Impact de la tension

20

25

30

35

40

45

50

55

0.8 0.85 0.9 0.95 1 1.05 1.1 1.15 1.2 1.25

Pow

er c

onsu

mp

tion

(W)

Voltage (V)

high freqmedium freq

boot freqlow freq

(d) Impact de la frequence23 / 54


Performances, frequence et tension

Processeurs simples

Performance lineaire avec la frequence d’horloge

fmax ∝ (V − Vth)2/V

fmax : Frequence maximale possibleV : Tension d’alimentation du processeurVth : Tension de seuil des transistors (gate)

Performance vs consommation

24 / 54


Performances, frequence et tension

Processeurs modernes

Plusieurs domaines d’horloges

Goulot d’etranglement ?

(a) NVIDIA Fermi

Core clock Memory clock Execution time Power1023 MHz 6008 MHz 12.3 s 43.3 W1023 MHz 1620 MHz 12.3 s 31.3 W

(b) NVIDIA Kepler

Figure: Consommation energetique et temps d’execution de noyaux adifferentes frequences sur deux familles de GPU

25 / 54



L’unite de gestion d’energie

Compteurs de performance

Processeur minimaliste

Applique la politique energetique

300

400

500

600

700

800

900

1000

1100

1200

0 2 4 6 8 10 12 14 16 1850

55

60

65

70

75

Clo

ck fr

equ

ency

(M

Hz)

GR

Usa

ge (

%)

Time (s)

Core (MHz) Perf_Core (%)

300

400

500

600

700

800

900

1000

1100

1200

0 2 4 6 8 10 12 14 16 1850

55

60

65

70

75

Clo

ck fr

equ

ency

(M

Hz)

GR

Usa

ge (

%)

Time (s)

Core (MHz) Perf_Core (%)

Figure: Reponse de la politique de NVIDIA a un changement d’utilisation

26 / 54



500

600

700

800

900

1000

1100

10000 15000 20000 25000 30000 35000 40000 450000

10

20

30

40

50

60

70

80

90

100

Clo

ck fr

equ

ency

(M

Hz)

Pow

er (

W)

& G

R u

sage

(%

)Time (ms)

Perf Core (%)

80W Power Cap

Power (W)

Core (MHz)

Power (W)80W power cap

Core (MHz)Perf_Core (%)

(a) Limitation de puissance

30

40

50

60

70

80

90

100

110

120

130

0 20000 40000 60000 80000 100000 120000 1400000

5

10

15

20

25

Pow

er (

W)

& T

empe

ratu

re (

°C)

FS

RM

Div

Time (ms)

Temperature (°C)

Power (W)

FSRM div

Power (W)FSRM div

Temperature (°C)

First threshold: 97°CSecond threshold: 100°C

(b) Limitation de temperature

Figure: Limitation de la consommation energetique et de la temperature

27 / 54


Conclusion

Bilan

Architecture interne de NVIDIA

Politique de gestion d’energie de NVIDIA

Test-bed open source (Nouveau) integre a Linux

Avantages

Economies energetiques possibles

Auto-optimisation : Adaptation frequence/tension

Auto-reparation : Temperature et Consommation

Limites de notre travail

Changement de frequence instable

Gestion automatique des frequences

28 / 54


Plan

1 Introduction





6 Conclusion

29 / 54


La prise de decision energetique en temps reel

Contexte : Ordinateurs heterogenes

Interfaces reseaux multiples

Processeurs multiples

Probleme : Selection du materiel le plus efficace

Materiel optimise pour differents scenarios

Configurations statiques non-optimales

30 / 54


La prise de decision energetique en temps reel

Migrations possibles

Processeurs big.LITTLE : Quelques millisecondes

Reseau : MPTCP

Proposition

Moteur de decision energetique a l’execution

Limites de l’etat de l’art

Temps-reel

Modeles materiels arbitraires

31 / 54


Exemple : Selection d’interface reseau

Abstraction des decisions

Metriques : Etat courant du systeme

Predictions : Evolution future

Modeles HW : Configuration et son impact

Score : Impact du modele sur les predictions

Decision : Selection du materiel

Decision Flowgraph

Metrics Prediction Models

Scoring

Scoring_Model_1

Scoring_Model_2

DecisionM1 Predicted_M1

M2 Predicted_M2

Model1

Model2

Scored_M1

Scored_M2

Scored_M1

Scored_M2

Score

W(0)

W(1)

Decision

ScoreW(0)

W(1)

32 / 54


RTGDE : Un moteur de decision generique a l’execution

(a) Sortie etage prediction (b) Sortie etage score

(c) Sortie etage de decision

33 / 54


Evaluation de RTGDE

Le cadritiel RTGDE

Implemente le graphe de flot precedent

Permet l’ecriture de blocs externes

Evaluation et comparaison avec Octave

Genericite :

1 : Selection d’interface radio WiFi et GSM2 : Selection du type de processeur big.LITTLE

Temps d’execution : 43.95 µs (± 13.19)

RAM minimum : 168 KB vs 25.3 MB pour Octave

34 / 54


Conclusion

Avantages

Comparaison de modeles arbitraires

Impact faible et predictible

Debogage simplifie

Reutilisation possible de blocs

Execution de plusieurs decisions en parallele

Limites

Chaque graphe de flot doit etre independant

35 / 54


Plan

1 Introduction





6 Conclusion

36 / 54


Conclusion

Rappel des defis

1 : Reduire les echanges et garantir la capacite de coms.

2 : Maximiser et garantir l’autonomie sur batterie

Contributions

Localisation des traitements dans les reseaux de capteurs

Partage efficace de spectre RF pour les com. sans fil

Gestion d’energie materielle autonome

Prise de decision energetique en temps reel

37 / 54


Perspectives

Reseaux verts de noeuds capteurs d’energie

Contexte : Alimentation par un panneau solaire

Objectif : Garder le reseau connecte et garantir une QoS

Defis :

Capacite de traitement dynamiqueCapacite de communication dynamique

Politique d’allocation de spectre RF decentralisee

Contexte : Radio cognitive

Objectif : Partage de spectre efficace entre CR

Defis :

Faire co-exister differentes couches physiquesLimiter la fragmentation du spectre RF

38 / 54


Perspectives

Politique de gestion d’horloges generique

Contexte : Processeurs modernes avec de multiples horloges

Objectif : Trouver la configuration optimale dynamiquement

Defis :

Predire l’impact d’un changement de frequenceReactivite face aux changements

Utilisation transparente des accelerateurs materiels

Contexte : Processeurs modernes avec accelerateurs

Objectif : Cadritiel pour optimiser les performances/l’energie

Defis :

Quantifier les gains possibles a l’executionRendre l’utilisation des accelerateurs automatique

39 / 54


Merci pour votre attention!

40 / 54


Annexe de la contribution 1

t0 t0+Δlpt0 t0+Δlp+Y

Publish an alertbecause:f(t) > threshold

threshold

sensorvalue

f(t)

Δsp

Publish an alertbecauce:f(t) > thresholdAND t > t0+Δlp

Publish an alertbecause:f(t) > f(t-Δsp)+Δv

f

OR OR

Δlp: Long retention period (example: 1 minute)Δsp: Short retention period (example: 10s)Δv: A significant value change (example: 20%)Δlp > Y > Δsp

Figure: Exemple de correlation locale

41 / 54



(a) Criticality level of an area (b) Types of packets received

Figure: Example of the real-time visualisation capabilities of Diase

42 / 54



(a) Deploying aThales infraredbarrier

(b) Deploying aThales seismicsensor

(c) Deploying a16-beam infraredsensor

Figure: Deployment of some sensors for protecting a farm in a militaryfield

43 / 54



(a) Four sensor nodes with anunidirectional infrared barrierattached

(b) A close-up on the sensornode, when attached to itsdemonstration board

Figure: Deployment of some sensors for protecting a farm in a militaryfield

44 / 54



Figure: Testing different area sensitivities

45 / 54



(a) Time, no transmission (b) Time, transmission

(c) Freq, no filtering (d) Freq, with filtering

46 / 54



f (x |µ, σ) =1

σe

x−µσ e−e

x−µσ (1)

(a) Noise-only (b) Noise + frequent transmissions

Figure: Histogram of the received power at one frequency

47 / 54



100 101 102 103 104

100

101

102

103

104

Beaconing period (ms)

Ave

rage

ren

dez

-vou

sd

elay

(s)

shp = 1msshp = 10msshp = 0.1sshp = 1s

shp = 10s

Figure: Influence of the beaconing and sensing-hopping period on theaverage rendez-vous delay.

48 / 54



2 4 6 8 100

2

4

6

8

Beacon count

Ave

rage

ren

dez

-vou

sd

elay

(s) radio 5MHz

radio 12.5MHzradio 25MHzradio 50MHz

Figure: Influence of the number of beacon sent and the sensing radio’sbandwidth on the average rendez-vous delay. shp = 10ms, bp = 10ms

49 / 54



0 20 40 60 80 100

10−2

10−1

100

101

102

Sensing radio’s bandwidth (MHz)

Ave

rage

ren

dez

-vou

sd

elay

(s)

minimumaverage

maximum

Figure: Variance of the rendez-vous time with shp = 10ms, bp = 10ms,bc = 2, 1 million iterations

50 / 54



0

1

Tim

e (

seco

nd

s)

CentralFrequency

Keymap

WTS frameRTR frameRTS frameCR data framePU data frame

Radio Frequency Spectrum

Beacon frame

Figure: Example of the spectrum usage done by relays in the proposednetwork

51 / 54



Cycles

Events

Signal

Clock 4

1

(a) Example of asimple performancecounter

Cycles

Events

Macro

signal

Clock X

XTruth

Table

Multi-

plexer

S0

S1

S3

S4

Events

Macro

signal XTruth

Table

Multi-

plexer

S0

S1

S3

S4

Events

Macro

signal XTruth

Table

Multi-

plexer

S0

S1

S3

S4

Signals

Events

Macro

signal XTruth

Table

Multi-

plexer

S0

S1

S3

S4

/256

/256

/256

/256

/256

(b) Schematic view of a clock domain inNVIDIA’s PCOUNTER engine

52 / 54



0 50 100 150 200 2500

1

2

3

4

·108

Obtained

Expected

FSRM’s PWM duty cycle (8 bit)

Cor

efr

equ

ency

(Hz)

(a) Frequency of the core clock (@408MHz, 16-divider) when varying theFSRM

53 / 54



0 5 10 15 20 25

80

100

120

140

up 2

up 1

low 1

low 2

Refresh cycles

Inst

anta

neo

us

pow

er(W

)

100

150

200

250

FS

RM

’sP

WM

du

tycy

cle

(8b

it)

PowerFSRM

(a) Example of the power limiter in the dual window mode

54 / 54

Documents

Une approche holistique pour l’informatique verte dans les ...Introduction Contribution 1 Contribution 2 Contribution 3 Contribution 4 ConclusionAnnexes Plan 1 Introduction 2 Localisation