Consumi

From I.N.F.N. Wiki
Revision as of 17:55, 2 February 2009 by Dario (talk | contribs) (Metodologie di risparmio)

Jump to: navigation, search

Introduzione

Breve introduzione dello scenario di lavoro e obbiettivi perseguiti


Metodologie di risparmio

Ci sono molti possibili interventi sulla configurazione di un sistema di calcolo, al fine di migliorarne l'efficienza energetica. L'idea in generale e' di rallentare o spegnere alcuni sottosistemi (cpu,dischi) quando non sono utilizzati al limite delle loro capacita'. Il concetto puo' essere esteso, su una farm, al completo spegnimento completo delle macchine non utilizzate in un certo istante.

Abbiamo dato la precedenza a tecniche che non comportassero modifiche sostanziali, per preservare la compatibilita' dell'ambiente software (al momento, principalmente linux SL4).

In quest'ottica una possibilita' interessante e' utilizzare la capacita' delle cpu moderne di poter variare il clock dinamicamente, questa tecnologia esiste da tempo ma in precedenza veniva implementata soprattutto sui portatili. La tecnologia e' conosciuta come Speedstep (Intel) o Powernow (AMD).

E' necessario che sia l'hardware (cpu, motherboard) che il software (bios della macchina, SO) abbiano questa capacita'. Nel nostro caso, la maggior parte delle macchine dedicate al calcolo, e i pc desktop acquistati nell'ultimo anno, sono risultati adeguati dal punto di vista hardware.

Abbiamo allora analizzato il SO Scientific Linux 4, nonostante questo sistema non sia recentissimo, il risultato e' stato che non sono necessarie modifiche. Il kernel ufficiale gestisce il cambiamento di clock mettendo a disposizione un'interfaccia standard (cpufreq). Sono presenti i driver per pilotare l'hardware in nostro possesso (cpu AMD). La gestione e' effettuata poi tramite dei governor, moduli che decidono quando variare effettivamente il clock, tra quelli presenti ci sono: performance – non ci interessa, non fa altro che mantenere il massimo delle prestazioni powersave – anche questo non ci serve, mantiene il clock al minimo livello ondemand – sarebbe l'ideale, modula il clock a seconda dell'utilizzo della cpu; purtroppo nella SL4, almeno col nostro hardware, sembra che non funzioni in maniera adeguata (con la SL5 invece, il funzionamento e' regolare). userspace – questo e' quello che abbiamo scelto di utilizzare, in realta' questo governor non fa altro che mettere a disposizione un interfaccia che un programma in userspace puo' utilizzare, a questo punto l'effettivo cambio di clock deve essere fatto da un apposito daemon. Esistono vari programmi adibiti a questo, la distribuzione SL4 include di default anche uno di essi (cpuspeed). Questo programma, monitorando l'utilizzo della cpu, reagisce di conseguenza.

Nei test effettuati, cpuspeed ha dimostrato di funzionare adeguatamente, e' bastato modificare le impostazioni di default. Infatti nei primi test, l'attivazione del governor userspace in combinazione con cpuspeed aveva come risultato un effettivo risparmio energetico, associato pero' con un rallentamento, valutabile fino al 20% con alcuni tipi di programma. Le impostazioni si sono dimostrate non adatte al nostro scopo, probabilmente sarebbero accettabili in un portatile, dove lo scopo e' aumentare il piu' possibile la vita della batteria. E' bastato pero' modificare alcuni parametri per limitare il rallentamento a meno dell 1%, senza alterare in maniera significativa il risparmio ottenuto.

Misure

Esaurita la parte di ottimizzazione della configurazione di cpuspeed abbiamo intrapreso una campagnia di misurazioni dei consumi utilizzando le piattaforme hardware disponibili in Sezione. Le misurazioni sono state eseguite su sistemi completamente "idle", cioè con il solo sisteam operativo e nessun applicativo utente in esecuzione, utilizzando un amperometro a pinza Fluke 322. Le tipologie di macchine prese in esame sono 4, tre sistemi per il calcolo tecnico scientifico ed un sistema desktop recente. Di seguito riportiamo le caratteristiche hardware dei sisyemi:

1. IBM x3455: 2 AMD Opteron 2218 con 4GB di ram (calcolo scientifico)

2. UniWide: 2 AMD Opteron 280 con 4GB di ram (calcolo scientifico)

3. Dell PowerEdge 1950: 2 Intel Xeon E5420 con 8GB di ram (calcolo scientifico)

4. Sistema assemblato: 1 AMD Athlon64 5000+ con 4GB di ram (desktop)

su tutti i sistemi è installato Scientific Linux versione 4.x. I risultati delle misure effettuate (in Ampere) sono riportati nella tabella seguente:

Macchina no CPUspeed si CPUspeed Risparmio
desktop 0.42 0.22 0.20
Uniwide 0.98 0.76 0.22
IBM 0.78 0.53 0.25
Dell 0.76 0.76 0

Abbiamo qundi applicato questa configurazione di CPUspeed ad un intero rack di macchine IBM composto da 25 nodi per un totale di 100 core. Attraverso il sistema di distrubizone elettrica abbiamo misurato i consumi prima e dopo l'applicazione della modifica verificando che il consumo è passato da 22.1A a 15.2A, con un risparmio di 6.9A equivalente a circa 1.5KW.

Incrociando questi risultati con le statistiche di utilizzo delle CPU dei sistemi IBM e Uniwide del mese di Gennaio si conclude che l'applicazione della configurazione CPUspeed a queste macchine avrebbe comportato un risparmio medio di circa 6KW, per questo motivo abbiamo deciso di applicare questo metodo a tutti i nodi della farm grid.

Conclusione