Consumi

Introduzione

Breve introduzione dello scenario di lavoro e obbiettivi perseguiti

Metodologie di risparmio

L'idea generale per diminuire il consumo energetico e' di rallentare o spegnere alcuni sottosistemi (cpu,dischi) quando non sono utilizzati al 100%. Il concetto potrebbe essere esteso, su una farm, allo spegnimento delle macchine non utilizzate, da riavviare poi se necessario.

Abbiamo dato la precedenza alle tecniche che rispondessero ai seguenti requisiti: 1) Non comportassero una diminuzione sensibile delle prestazioni. Nel nostro caso non c'e' un vero tradeoff consumo/prestazioni, come potrebbe essere nel caso di sistemi alimentati a batteria. 2) Non richiedessero modifiche sostanziali dell'ambiente software (Linux SL4). Questo per ovvi motivi (compatibilita' delle applicazioni).

Abbiamo indagato sull'utilizzo della capacita' che hanno le cpu piu' moderne di variare il clock dinamicamente, questa tecnologia esiste da tempo ma in precedenza veniva utilizzata solo su sistemi portatili. La tecnologia e' conosciuta come Speedstep (Intel) o Powernow (AMD).

Innanzi tutto e' necessario che sia l'hardware (cpu, motherboard) che il firmware (bios della macchina) abbiano questa capacita'. Nel nostro caso la maggior parte delle macchine dedicate al calcolo, e i pc desktop acquistati nell'ultimo anno, sono risultati compatibili 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.