Infraestrutura de Redes de Sensores Sem fio paraMonitoramento Térmico de CPDs

Gustavo Z. Bruno, Giulio Bottari, Breno Carvalho, Raphael Guerra, Julius LeiteInstituto de Computação

Universidade Federal FluminenseNiterói, RJ 24210-240

e-mail: {zanatta, gbottari, brenocarvalho, rguerra, julius}@ic.uff.br

Resumo—A sociedade é cada vez mais dependente de grandescentros de processamento de dados (CPDs). Sistemas de busca,sistemas de comércio eletrônico e computação em nuvem sãoexemplos de aplicações que necessitam de grandes CPDs. Um dosgrandes desafios da Computação Verde é conciliar a demandacomputacional desses centros com a necessidade de reduzir oseu custo de operação e o impacto ambiental causado pelo seualto consumo de energia. Entre os principais responsáveis poresse consumo está o sistema de arrefecimento dessas instalações.Para aumentar a eficiência desses sistemas de arrefecimentoprimeiramente precisa-se monitorá-los com o objetivo de obterinformações sobre o seu comportamento. Para fazer isso deuma maneira indireta e que seja o menos intrusiva possívelpara a instalação, propõe-se uma rede de sensores sem fio paramonitoramento térmico distribuída pelo ambiente. A rede foiimplantada em um CPD real e tem uma infraestrutura quepermite a ela ser capaz de prover em tempo real os dados térmicosda instalação, com garantia de entrega acima de 99% e comprecisão de milissegundos do instante de coleta.

I. INTRODUÇÃO

As Tecnologias de Informação e Comunicação (TIC) con-tribuem diretamente para mais de 2% das emissões globais deCO2. A tendência é que esta quantidade dobre até 2020 [1].Neste cenário, as TIC ultrapassariam emissões de indústriasaltamente poluentes, como a de aviação. Um estudo realizadopela U.S. Environmental Protection Agency [2] em 2007 es-timou a demanda de pico desses sistemas em 7 gigawatts.Os CPDs de todo mundo emitiram aproximadamente 116milhões de toneladas anuais de carbono até 2008, mais quetoda emissão da Nigéria [3].

Por conta do calor dissipado pelos diversos equipamentospresentes em um CPD, os servidores precisam de refrigeraçãoadequada para operar de forma confiável. Assim, sistemas dearrefecimento em muitos CPDs são ajustados para operaremem temperaturas muito baixas. Grandes clusters comerciaisrequerem milhares de processadores e uma grande área paraa sua instalação, e na maioria das vezes a instalação, osservidores e a distribuição de carga são heterogêneas. Destaforma, surge naturalmente um desbalanceamento térmico emdiversas localidades do CPD. Esse tipo de fenômeno (i.e. ilhasde calor) é bem complexo e difícil de prever sem uma quanti-dade de informações precisas da instalação. Estima-se que paracada watt gasto com o processamento de dados, outro watt éconsumido com arrefecimento [4]. Além disso, os gerentesde CPDs, por falta de informações para diagnosticar a causareal do problema, tendem a aumentar ainda mais a potência

do sistema de arrefecimento quando alguns dos servidores seencontram próximos a um limiar térmico operacional.

Um sistema de monitoramento baseado em redes de sen-sores sem fio (RSSF) tem a principal vantagem de ser inde-pendente do ambiente a ser monitorado (não-intrusivo), poisa alimentação dos dispositivos é autônoma, através de bate-rias. Adicionalmente, graças ao baixo consumo, apresenta umgrande tempo de vida. Em CPDs, principalmente aqueles quelidam com informações sensíveis (e.g., CPDs de instituiçõesfinanceiras), a baixa intrusão é condição fundamental para aadoção de qualquer solução de monitoramento.

RSSFs também operam de forma eficiente e genéricaindependentemente das características do CPD monitorado,superando inúmeras restrições que podem ser encontradasem CPDs (i.e. acessibilidade, interação). Além disso, umaRSSF possibilita uma boa granularidade nos dados coletadosindependentemente do estado dos servidores do CPD (e.g.ligado, dormindo ou desligado).

O ambiente do CPD configura uma ampla fonte de inter-ferências a qualquer tipo de comunicação sem fio, principal-mente em dispositivos de baixa potência, como os utilizadosneste trabalho. Além disso existe a problemática comum atodas RSSF que possuem alimentação por meio de baterias,isto é, baixa longevidade dos nós. Por fim, há a necessidadede garantir uma precisão temporal do instante em que os dadosforam coletados.

Nesse contexto, o objetivo deste trabalho é investigar aviabilidade de uma rede de sensores sem fio para monito-ramento térmico de CPDs. Para tanto, utilizou-se uma redede sensores funcional instalada em um CPD real que coletouinformações térmicas durante a operação normal da instalação.A infraestrutura da rede é baseada na agregação de tecnologiasdisponíveis para RSSF. A escolha das tecnologias priorizouampla utilização e bom suporte da comunidade desenvolve-dora. Essa solução é genérica, pois pode atender uma grandevariedade de tipos de CPDs pelo fato de não necessitar denenhuma interação direta com os sistemas da instalação. Arede proposta é capaz de coletar dados térmicos relativos aoambiente do CPD com precisão de milissegundos.

Nas próximas seções são apresentados alguns trabalhosrelacionados que utilizam RSSF como solução para o problemade monitoramento térmico de CPDs. Na sequência são expos-tos a topologia da rede, seus componentes e configurações,

bem como protocolos utilizados. Por fim, discutem-se osprincipais experimentos realizados neste trabalho.

II. TRABALHOS RELACIONADOS

Dentre as abordagens já existentes para tratar o monito-ramento termoenergético em CPDs predomina a característicadelas serem altamente intrusivas (e.g. [5]), ou seja, não sãotransparentes para as aplicações que rodam nos servidores.Esse é o caso das políticas de gerenciamento de energia paraCPDs que empregam alteração de frequência de operaçãodo processador, ou desligamento de partes do hardware, porexemplo [6], [7]. Tais abordagens requerem uma avaliaçãocaso-a-caso, de modo a respeitar os requisitos da aplicação.

Até o momento, de acordo com o conhecimento dosautores, há duas abordagens baseadas em redes de sensorespara o monitoramento térmico de CPDs: o ThermoCast [8] eo RacNet [9].

O ThermoCast é uma modelagem para previsão do com-portamento térmico com o foco em grandes CPDs. Essa abor-dagem utiliza informações em tempo real da carga de trabalho,temperatura e fluxo do ar obtidos através de um conjuntode sensores do ambiente para modelar e prever temperaturasem torno dos servidores. Estes dados são obtidos a partir desensores de temperatura colocados em alguns servidores. Como intuito de obter alta previsibilidade, ThermoCast utiliza umaabordagem híbrida que leva em consideração à termodinâmicae as informações de carga. Entretanto, a abordagem é conside-rada altamente intrusiva, pois o algoritmo para previsão térmicaexecuta distribuído entre os servidores. Além disso, utilizasensores cabeados para coleta das informações do ambienteem torno dos servidores, e também coleta as informações dacarga de trabalho dos servidores em tempo real e distribui atarefa de modelagem para previsão térmica de anomalias atodos servidores.

O RACNet [9] consiste em uma RSSF de grande escala ealta fidelidade para monitoramento ambiental (principalmentetérmico) de CPDs. RACNet usa nós sensores, do tipo Ge-nomote, que empregam uma combinação de comunicaçõescom e sem fio. Como contribuição essencial do trabalho,desenvolveu-se um protocolo sem fio escalável e confiávelpara coleta de dados WRAP (Wireless Reliable AcquisitionProtocol). Todavia, a solução tem duas características quedeixam a desejar. A primeira delas é o fato de usar fio, mesmoque seja para interligar as cadeias de monitoramento, gerandoalgum transtorno ao ambiente dos CPDs, e consequentementeaos seus administradores. O segundo ponto é o fato de usaremalimentação USB, característica essa que soluciona o problemada economia de energia em RSSF e proporciona uma granu-laridade fina nos dados coletados (i.e. uma coleta periódicaa cada 30 segundos), porém, acaba tornando a solução maisintrusiva.

III. TOPOLOGIA

Uma organização comum de CPDs é à disposição dos racksem corredores frios e quentes. A Figura 1 ilustra um cortetransversal em um CPD típico. Os racks de servidores sãoinstalados em um piso elevado, e o ar frio é injetado pelosistema de arrefecimento através de grelhas nos corredoresfrios. Por sua vez, os servidores sugam ar frio e expelem

Figura 1. Dinâmica do fluxo de ar em um CPD típico.

ar quente (nos chamados corredores quentes) através de suasventoinhas. De forma a diminuir a recirculação de ar, os rackssão dispostos de forma que as saídas dos servidores (ar quente)fiquem face a face.

Além dos desafios impostos pelo sistema de arrefecimento,também existem as diferenças térmicas geradas pelas hetero-geneidades do CPD. Essas heterogeneidades causadas pelasdiferenças de hardware, software e carga computacional podemgerar um comportamento térmico indesejável no ambiente (i.e.ilhas de calor).

De forma a capturar as informações térmicas, os nós sãodispostos verticalmente, em várias alturas nos racks. Nos casosem que o nó base estiver muito longe dos nós coletores,são inseridos nós roteadores. A quantidade de sensores porrack varia em função de granularidade da informação térmicadesejada.

IV. COMPONENTES DA RSSF

A RSSF proposta neste trabalho é composta por dois tiposde dispositivos de comunicação e processamento: o modelo Iris[10] e o Micaz [11]. Os dispositivos que estão conectados aocomputador são acoplados a uma placa gateway modelo MIB520 [12] que possibilita a comunicação entre a RSSF e umservidor por meio de uma porta no padrão Universal SerialBus (USB). Nos demais dispositivos são acoplados a placade sensoriamento MDA 100 [13] que provê sensoriamento detemperatura e luminosidade.

V. CONFIGURAÇÕES DA RSSF

Nesta Seção são discutidos detalhes da infraestrutura desuporte utilizada para desenvolvimento da RSSF e do sistemapara monitoramento, disponibilização e exibição dos dados.Serão descritos o hardware, a plataforma de desenvolvimentoe detalhes dos protocolos utilizados.

Durante os estudos iniciais para o desenvolvimento da pro-posta aqui apresentada optou-se por utilizar "soluções de pra-teleira"1. Diante disso, foram escolhidas para desenvolvimentoas soluções que possuem maior aceitação na comunidade quetrabalha com RSSF.

1Um software ou hardware pré-desenvolvido por um fornecedor terceiro.Ele pode ser alugado, comprado ou gratuito (código aberto).

A. Sistema Operacional

O SO adotado para desenvolvimento da aplicação embar-cada para a RSSF é o TinyOS [14] na versão 2.1.2. Ele tem ummodelo de programação baseado em componentes, codificadona linguagem NesC [15], um dialeto da linguagem de pro-gramação C. O TinyOS é uma estrutura de programação parasistemas embarcados que agrega um conjunto de componentesque permitem a construção de uma aplicação específica paracada contexto.

B. Protocolo MAC

O protocolo utilizado na camada MAC é o Box-MAC-1[16], [17], uma versão melhorada do popular Berkeley MAC(B-MAC) [18] para gerenciamento do duty-cycle dos rádiosdos nós da RSSF.

No Box-MAC-1, quando um nó deseja enviar um pacote elefica enviando pacotes de despertar até o nó destinatário acordare fazer a verificação do meio. Assim que o nó destinatárioacorda e checa o meio, percebe que tem algum nó desejandoenviar algo e ativa seu rádio para receber o pacote. Estatécnica visa a economia de energia permitindo que o rádio dosnós fique desligado por mais tempo quando não há envio depacotes. No entanto, quanto maior o período que um nó dorme,maior o tempo no pior caso que um nó deve enviar mensagensde despertar. Logo, o tráfego na rede deve ser levado em contaao definir o tempo máximo que cada nó fica com o rádiodesligado.

C. Protocolo de Rede

O protocolo utilizado para manter a topologia da rede epossibilitar a comunicação por múltiplos saltos é o CTP [19].Ele provê um serviço básico e bastante comum em redes desensores, que é coletar dados de vários sensores espalhados noambiente e transportá-los a um ou mais nós centrais (i.e. roots),como é ilustrado na Figura 2. A ideia básica é a construçãoautomática de uma rede mantendo a topologia em árvore, comuma ou mais raízes dependendo da escala e densidade daRSSF. O protocolo de coleta constrói e mantém um caminhocom custo mínimo para o(s) nó(s) que anunciam-se como raizda árvore. O protocolo é livre de endereço: quando existemmúltiplas raízes, ele envia para uma com o custo mínimo e semsaber seu endereço. Não há especificação de destino direta nasmensagens trocadas pelos nós. O endereçamento de destino éindireto e sempre para uma raiz (root) da rede.

D. Protocolo para Sincronia de Relógios

Para manter os relógios dos nós na rede sincronizados,o FTSP [20] foi utilizado. Esse protocolo possui precisãode microssegundos e é escalável a redes com centenas denós, mantendo a robustez independentemente de mudançasna topologia da rede e falhas diversas. Periodicamente o nóroot de sincronia (i.e. on nó com menor id ativo na RSSF)envia o tempo para os demais nós que o propaga e assimsucessivamente até o tempo convergir em toda a RSSF. Oalgoritmo utilizado pelo protocolo compensa os erros ao em-pregar o conceito de MAC timestamp [21], isto é, a timestampé inserida na camada MAC pouco antes do envio minimizandoo risco de acumular atrasos devido a processos internos donó. O desvio entre as frequências dos relógios é compensado

Figura 2. Funcionamento básico do CTP [19].

utilizando uma técnica baseada em regressão linear para evitaro envio frequente de mensagens de sincronia.

Neste trabalho fez-se algumas adaptações para adequar oprotocolo às necessidades da aplicação. Seguem os detalhesdas alterações: (i) a frequência de envio de mensagens desincronia é de uma mensagem a cada dez minutos; (ii) operíodo máximo para um nó se declarar root é a expiração deduas vezes o período de sincronia, isto é, se o nó ficar por 20minutos sem receber a mensagem de sincronia ele se declararoot, com exceção do nó com ID 0, que é o nó base, que assimque entra na RSSF já se declara root; (iii) um nó qualquer darede, após se declarar root, ignora por duas vezes o período desincronia de mensagens de outro nó root qualquer (esse meca-nismo provê mais estabilidade na eleição do root de sincronia);(iv) um nó só pode sinalizar como sincronizado caso tenhapelo menos duas entradas na tabela utilizada para regressão,mas pode disseminar mensagens de sincronia imediatamenteapós o recebimento da primeira; (v) por fim, se o erro entreo relógio local e o global for maior que 100 milissegundos, atabela de pontos de referência temporais utilizada no cálculo daregressão linear é apagada. Vale observar que o nó root nessecontexto é o nó responsável pela disseminação do tempo naRSSF, não sendo necessariamente um nó consumidor.

E. Protocolo para Disseminação de Código

Para facilitar os testes e as futuras atualizações no códigoda aplicação embarcada, utilizou-se o protocolo Deluge [22].Esse protocolo fornece uma maneira eficiente para dissemina-ção de grandes conjuntos de dados, como programas binários,para muitos nós pertencentes a uma RSSF, eliminando otrabalho de inserir/atualizar o código em cada sensor individu-almente. Combinando este mecanismo com um comando paradisseminação e um mecanismo para gerenciamento de boot,ambos providos pelo protocolo, torna-se viável a programaçãoremota dos nós da RSSF.

F. Aplicação para Coleta de Informações

A aplicação embarcada para coleta de informações temcomo função principal a aquisição dos dados térmicos deforma confiável (precisão temporal do instante de coleta). Elaé composta basicamente por uma thread que faz verificaçõesperiódicas na temperatura, no estado da bateria e na topologiada rede e transmite esses dados em função de dois fatores: caso

alguma dessas variáveis se alterem mais de que um determi-nado limiar (e.g. a temperatura varie 0,5◦C, a luminosidade doambiente ou topologia se altere), ou um nó fique sem enviarpor um determinado limiar de tempo (e.g. 5 minutos). Essescritérios visam reduzir a quantidade de informações que sãogeradas pela rede e filtrar variações mínimas de temperaturado ambiente. Os experimentos efetuados para analisar e deter-minar esses critérios são descritos na Seção VI-A.

VI. EXPERIMENTOS

A. Avaliação de Estratégias de Agregação de Dados

Para execução dessa avaliação, a leitura de dados doambiente pelos nós da RSSF foi emulado utilizando um tracecontendo dados de temperatura reais que foram coletadosanteriormente no CPD em que a RSSF foi imlantada. Oobjetivo é verificar qual estratégia de envio gera menos tráfegona RSSF, no contexto do monitoramento térmico de CPDs, econsequentemente diminui o consumo energético. Para tanto,é feita uma análise do comportamento do número de transmis-sões em função da estratégia de envio utilizada.

O arquivo utilizado para simular os dados coletados pelaRSSF continha três valores: uma identificação do nó que feza leitura do dado, uma timestamp contendo a hora que foicoletado e a temperatura coletada.

Tabela I. TRÁFEGO GERADO PELAS ESTRATÉGIAS DE ENVIO.

Estratégia Parâmetros (segundos) TransmissõesIngênua Coleta/envio a cada 1 6065538 (100%)Aditiva min: 1, max: 30, incr: 1 252093 (4,2%)Aditiva min: 1, max: 10, incr: 1 562455 (9,3%)Aditiva min: 1, max: 8, incr: 1 688039 (11,3%)Aditiva min: 1, max: 2, incr: 1 2934492 (48,4%)Aditiva min: 2, max: 2, incr: 2 3032773 (50,0%)Aditiva min: 3, max: 3, incr: 3 2021850 (33,3%)Faixa delta = 0,001◦C; max = 10 684811 (11,3%)Faixa delta = 0,1◦C; max = 10 571899 (9,4%)Faixa delta = 0,2◦C; max = 10 554298 (9,1%)Faixa delta = 0,2◦C; max = 30 202227 (3,3%)Faixa delta = 0,5◦C; max = 60 100544 (16,6%)Faixa delta = 0,5◦C; max = 600 13420 (0,02%)Faixa delta = 1,0◦C; max = 30 195835 (3,2%)

Nesse experimento foram abordadas as seguintes estra-tégias: Ingênua, Aditiva e Faixa. A estratégia Ingênua é aque coleta e envia as amostras térmicas a cada segundo. Aestratégia Aditiva consiste em um valor mínimo e máximopara o intervalo de coleta/envio das amostras e um valor paraincremento do intervalo do ciclo. Conforme a temperaturapermanece estável, o valor do intervalo é incrementado como valor de incremento, se a temperatura se alterar o valor doincremento volta para o mínimo e o envio volta a ser frequente.A estratégia Faixa consiste em coletar amostras a cada segundoe somente enviá-las quando houver uma variação mínima entreas amostras ou quando atingir um intervalo máximo para envio.

Como se pode observar na Tabela I, a melhor abordagempara o nosso cenário é a Faixa. Pode-se observar nos resultadosdas simulações com essa estratégia que quanto maior o valordo Delta e do tempo máximo para envio menos transmissõesocorrem. Entretanto, quanto maior for o valor do Delta, maioré a granularidade dos dados coletados e mais informações sãoperdidas. Devido a limitação de hardware, a precisão dos dadoscoletados pelos nós da RSSF é de 0,2◦C, portanto, valores para

um Delta menor que esse foram desconsiderados. Para obterum equilíbrio entre a necessidade de informações precisas ea necessidade de reduzir o tráfego da RSSF foi escolhido oDelta de 0,5◦C. Por fim, o tempo limite máximo para envioé o mínimo possível que atenda as restrições de consumoenergético da RSSF sem comprometer a segurança do CPD.Esse parâmetro é estudado com mais detalhes na Seção VI-Be fica definido como cinco minutos.

B. Frequência da Verificação de Atividade dos Nós da RSSF

O objetivo desse teste é identificar qual é o tempo limiteque um ou mais nós podem ficar sem enviar nenhuma in-formação sem correr o risco de comprometer a supervisãodo CPD pela falta de alerta ao administrador do CPD porfalha na coleta dos dados pela RSSF. Para a análise foi levadaem conta como o pior caso uma situação em que o sistemade arrefecimento falhe completamente. Esse intervalo mereceuma atenção especial pois, durante este período, não é possívelidentificar uma falha na rede.

Os dados críticos para execução desse experimento cor-respondem a uma falha elétrica que desligou o sistema dearrefecimento do CPD monitorado. Os servidores ficaramativos até que um mecanismo de proteção de hardware osdesligassem. A RSSF colocada em torno dos servidores estádescrita no layout ilustrado na Figura 3. A taxa de coleta/enviono contexto era de uma amostra de temperatura a cada minuto.

Figura 3. Layout da RSSF no momento da falha do sistema de arrefecimento.

Como se pode observar na Figura 4, após o desligamentodo sistema de arrefecimento os servidores (06:25) levaramaproximadamente 40 minutos para desligar, isto é, paralisartodos os serviços que estavam sendo providos pelo CPDnaquele instante (07:05). O nó que registrou o maior aumentode temperatura foi o 251. Por estar localizado em cima dorack da esquerda e receber o fluxo de ar direto do sistema dearrefecimento, ele registra um aumento de aproximadamente8◦C nos primeiros dez minutos sem refrigeração. Esse nó,durante todo o período de operação sem refrigeração (das 6:25até as 7:05), detecta um aumento de 16◦C, pois inicialmenteestava registrando temperaturas em torno de 17 ◦C e, quandoos servidores falharam chegou a registrar 33◦C. O nó queregistrou temperatura mais elevada foi o 252 que, por estar nasaída de um servidor bem em baixo do rack, como ilustradona Figura 3, tem maior dificuldade de receber o fluxo de ar do

sistema de arrefecimento. Esse nó no instante da falha (06:25)já registrava 39◦C chegou a registrar no pior instante (07:05)50◦C.

Figura 4. Perfil do comportamento térmico no instante da falha do sistemade arrefecimento.

Com base nesse experimento, pode-se observar que o idealé enviar informações com a maior frequência possível, a fim dedetectar a falha de um ou mais nós o quanto antes. Entretanto,em oposição a essa necessidade, tem-se o requisito básico deeconomizar energia, o que é feito principalmente minimizandoo número de transmissões de dados dos nós da RSSF. Comobjetivo de manter esse compromisso, e por conta desse expe-rimento não avaliar o impacto da periodicidade de transmissãono consumo energético, foi executado o experimento paraavaliar o impacto do tempo limite de envio dos dados coletadosno consumo energético do nó descrito na Seção VI-C.

C. Impacto do Tempo Limite de Envio dos Dados Coletadosno Consumo Energético do Nó

Esse experimento tem como objetivo verificar qual o tempolimite máximo possível para envio das informações coletadasde modo que não comprometa o tempo de vida dos nóssensores da RSSF. Para execução desse teste, foram utilizadosquatro nós, cada um com um tempo limite para envio distinto,sendo eles: 5, 10, 15 e 30 minutos. Foram escolhidos essesvalores pois, em experimentos realizados para intervalos me-nores que 5 minutos, o consumo energético aumenta de formasignificativa, e consequentemente o tempo de vida dos nós cai.Para valores acima que 30 minutos, em caso de falhar a RSSFe coincidentemente acontecer alguma anomalia na instalação,um aviso com esse atraso pode ser muito tarde. Como podeser visto da Figura 4 a temperatura registrada pelo nó 251 sobeaproximadamente 15◦C em 30 minutos.

Como se pode observar no gráfico da Figura 5 e diante dosdados exibidos na Tabela II, houve um ganho aproximado de9,5% em tempo de vida dos nós utilizando o maior intervalo,ou seja 30 minutos, com relação ao menor intervalo, queé de cinco minutos. Assim, optou-se por perder esse ganhoem tempo de vida e utilizar o menor intervalo para o tempomáximo para envio do nó, pelo fato desse valor possibilitaruma detecção precoce de falha nos nós da RSSF e no CPD.

Figura 5. Resultado do experimento variando o intervalo máximo para enviodos dados coletados. Obs.: Gráfico gerado pelo sistema apresentado nestadissertação.

Tabela II. DETALHAMENTO DE RESULTADOS DO EXPERIMENTO PARACÁLCULO DO CONSUMO ENERGÉTICO DO nó, VARIANDO O INTERVALO

MÁXIMO PARA ENVIO DOS PACOTES.

Intervalo deEnvio (min)

Consumomédio/dia (v)

Tempo de vidaestimado (dias)

5 0,031 38,0510 0,030 38,5020 0,030 38,8830 0,028 41,69

D. Quantidade de Pacotes Perdidos Variando o Alcance doRádio

Essa simulação tem como objetivo variar a potência detransmissão do rádio dos nós da RSSF para verificar o efeitono número de saltos dos pacotes que trafegam pela RSSF.Excepcionalmente nesse caso foi escolhido utilizar uma simu-lação no lugar de um experimento prático para ter um controlepreciso da potência do rádios dos nós. Para efeito de cálculolevou-se em conta as transmissões e retransmissões de pacotesda aplicação no trajeto dos nós consumidores até o nó root etambém considerou o número de pacotes recebidos. Com basenesses valores, é possível calcular o número médio de saltos,bem como das perdas de pacotes (lembrando-se que essa perdanão implica no não recebimento das informações pelo nó root,mas sim em reenvio dos pacotes a cada salto por conta de umatransmissão mal sucedida).

Para execução da simulação, foi utilizado o simulador deaplicações nativas do TinyOs, o Tossim [23]. A aplicaçãoutilizada para simulação foi o Multihope Osciloscope, presentenos aplicativos exemplos do TinyOs.

Tabela III. RESULTADOS DA SIMULAÇÃO PARA CONTAGEM DONÚMERO DE PACOTES ENCAMINHADOS PERDIDOS VARIANDO A POTÊNCIA

DO RÁDIO DOS nós NA RSSF.

Atenuação de potência Média de saltos Perdas %50 dB a cada 6 metros. 2.25 42.6250 dB a cada 3 metros. 2.66 43.93

30 dB a cada metro. 2.68 41.2150 dB a cada metro. 3.41 67.6960 dB a cada metro. 0 100

Com base nas informações mostradas na Tabela III, pode-se observar que, quanto maior a atenuação do sinal, maior éo número de saltos e de perdas. Perda implica em retrans-missão e como consequência, em maior consumo energético.Concluiu-se então que para fazer sentido reduzir a potência de

transmissão, esta ação deve fornecer um aumento de eficiênciaenergética maior que o gasto com retransmissões a cada saltona RSSF. Para isso, foi feito um experimento prático ondefoi medido o consumo energético de dois nós, um com o seurádio configurado na potência de transmissão máxima e umna mínima disponível. Por meio desse experimento verificou-se que não é viável para uma RSSF com mais de um salto nocaminho do nó produtor ao root reduzir a potência do rádio,pois o consumo energético global da RSSF tende a ficar maiore consequentemente a longevidade da RSSF menor.

VII. CONCLUSÃO

Esse trabalho tem como objetivo verificar a viabilidadeda utilização de uma RSSF de forma eficiente na coleta deinformações térmicas do ambiente de um CPD. Para isso,a abordagem proposta teve que explorar alguns desafios im-postos pela utilização RSSFs: confiabilidade, escalabilidade elongevidade. Esses desafios foram encontrados pelo fato doambiente do CPD configurar uma ampla fonte de interferên-cias a qualquer tipo de comunicação sem fio, principalmenteem dispositivos de baixa potência, como os utilizados nestetrabalho. Para tratar esses problemas, empregou-se o protocoloCTP ajustado para esse contexto, que aborda esses desafiosatravés da combinação de três mecanismos: manutenção daárvore de coleta de dados dinamicamente; redundância dospontos de coleta em combinação com a utilização de umprotocolo assíncrono para um baixo consumo energético nacomunicação, o Box-MAC-1 e, por consequência do atraso naentrega dos pacotes para o nó root em virtude do protocoloMAC utilizado, é também usado o protocolo FTSP para tratarsincronização dos relógios locais dos nós da RSSF.

Com base nos diversos experimentos ficou evidente que aRSSF não só é capaz de coletar os dados do CPD, mas alémdisso faz isso de forma precisa e eficiente energeticamente. ARSSF consegue atingir uma longevidade (tempo de operaçãosem troca de bateria) que chega aos 40 dias de operação etambém provê uma taxa de entrega de pacotes de mais de 99%graças à utilização do protocolo CTP. Características comoessas, permitem que esses dados possam ser utilizados, porexemplo, para técnicas que façam a distribuição de carga detrabalho do CPD em função do comportamento térmico dainstalação ou, até mesmo em técnicas que busquem detectare prever anomalias térmicas no CPD. Por fim, as principaiscontribuições do trabalho são: a definição e implementação deuma RSSF para coleta de dados de um CPD e a experimenta-ção dessa em um ambiente real.

REFERÊNCIAS

[1] K. Christensen, “Green networks: Opportunities and challenges,” in 34thIEEE Conference on Local Computer Networks, Zurich, Suíça, Outubro2009, p. 13.

[2] EPA, “Report to congress on server and data center energy efficiency,”2007.

[3] J. Mankoff, R. Kravets, and E. Blevis, “Some computer science issuesin creating a sustainable world,” IEEE Computer, vol. 41, no. 8, pp.102–105, Agosto 2008.

[4] D. Mossé, J. Leite, and A. de Barros, “Introdução aos Clusters Ver-des de Servidores,” in Atualizações em Informática, W. M. Jr. andA. de Carvalho, Eds. Porto Alegre, RS, Brasil: Sociedade Brasileirade Computação, Junho 2010, pp. 41–50.

[5] D. Meisner, B. T. Gold, and T. F. Wenisch, “Powernap: eliminating ser-ver idle power,” in Architectural Support for Programming Languagesand Operating Systems, Março 2009, pp. 205–216.

[6] F. Ahmad and T. Vijaykumar, “Joint optimization of idle and coolingpower in data centers while maintaining response time,” in ACM SigplanNotices, New York, EUA, Março 2010, pp. 243–256.

[7] W. Huang, M. Allen-Ware, J. B. Carter, E. Elnozahy, H. Hamann,T. Keller, C. Lefurgy, J. Li, K. Rajamani, and J. Rubio, “Tapo: thermal-aware power optimization techniques for servers and data centers,” in2nd IEEE Green Computing Conference and Workshops, Orlando, EUA,Julho 2011, pp. 1–8.

[8] L. Li, C.-J. M. Liang, J. Liu, S. Nath, A. Terzis, and C. Faloutsos,“Thermocast: a cyber-physical forecasting model for data centers,” in17th ACM Conference on Knowledge Discovery and Data Mining,vol. 11, San Diego, EUA, Agosto 2011.

[9] C.-J. M. Liang, J. Liu, L. Luo, A. Terzis, and F. Zhao, “Racnet: ahigh-fidelity data center sensing network,” in 7th ACM Conference onEmbedded Networked Sensor Systems, Novembro 2009, pp. 15–28.

[10] MEMSIC, “Iris datasheet,” http://www.memsic.com.[11] ——, “Micaz datasheet,” http://www.memsic.com.[12] ——, “MIB 520 datasheet,” http://www.memsic.com.[13] ——, “MDA 100 datasheet,” http://www.memsic.com.[14] P. Levis, S. Madden, J. Polastre, R. Szewczyk, K. Whitehouse, A. Woo,

D. Gay, J. Hill, M. Welsh, E. Brewer et al., “TinyOs: an operatingsystem for sensor networks,” in Ambient intelligence. Springer, 2005,pp. 115–148.

[15] D. Gay, P. Levis, R. Von Behren, M. Welsh, E. Brewer, and D. Culler,“The nesc language: A holistic approach to networked embeddedsystems,” vol. 38, no. 5, pp. 1–11, Maio 2003.

[16] D. Moss and P. Levis, “Box-macs: Exploiting physical and link layerboundaries in low-power networking,” Stanford University, Tech. Rep.,2008.

[17] D. Moss, J. Hui, and K. Klues, “TEP 105: low power listening,” 2007,http://www.tinyos.net/tinyos-2.x/doc/html/tep105.html.

[18] J. Polastre, J. Hill, and D. Culler, “Versatile low power media accessfor wireless sensor networks,” in ACM 2nd International Conferenceon Embedded networked Sensor Systems, Baltimore, EUA, Novembro2004, pp. 95–107.

[19] O. Gnawali, R. Fonseca, K. Jamieson, D. Moss, and P. Levis, “Collec-tion tree protocol,” in 7th ACM Conference on Embedded NetworkedSensor Systems, Novembro 2009, pp. 1–14.

[20] M. Maróti, B. Kusy, G. Simon, and Á. Lédeczi, “The flooding timesynchronization protocol,” in 2nd ACM International Conference onEmbedded Networked Sensor Systems, Baltimore, EUA, Novembro2004, pp. 39–49.

[21] M. Maroti and J. Sallai, “TEP 133: packet-level time syn-chronization,” TinyOS Core Working Group, Tech. Rep., 2008,http://www.tinyos.net/tinyos-2.1.0/doc/html/tep133.html.

[22] J. Hui, “Deluge 2.0 - TinyOs network programming,” 2005,http://www.cs.berkeley.edu/ jwhui/deluge/deluge-manual.pdf.

[23] P. Levis, N. Lee, M. Welsh, and D. Culler, “TOSSIM: Accurateand scalable simulation of entire tinyos applications,” in 1st ACMInternational Conference on Embedded Networked Sensor Systems, LosAngeles, California, EUA, Outubro 2003, pp. 126–137.