Profilazione utente in ambienti virtualizzati

UNIVERSITÀ DEGLI STUDI DI TRIESTE

Dipartimento di Ingegneria e ArchitetturaCorso di Laurea Magistrale in Ingegneria Informatica

Tesi Di Laurea

Pro�lazione utente in ambientivirtualizzati

LaureandoPietro Corona

Matricola IN1400023

RelatoreProf. Nolich Massimiliano

Anno Accademico 2012/2013

Dedicato alla mia famiglia e a Greta

Ringraziamenti

• La mia gratitudine va al prof. Nolich per il suo preziosissimo aiuto e perla sua in�nita disponibilità.

• Ringrazio il prof. Mumolo per i preziosi consigli dati in fase di analisidei risultati.

iii

Introduzione

Nei moderni sistemi di elaborazione dati delle aziende, sia grandi che medio-piccole, la virtualizzazione è una tecnica sempre più di�usa. Essa permette,ad esempio, di consolidare numerosi server in un'unica macchina �sica, oppureai provider di servizi di Web hosting di o�rire ai propri clienti una macchi-na dedicata senza la necessità di aggiungere una macchina �sica all'internodel loro data center. Questo comporta numerosi vantaggi dal punto di vistadella gestione (manutenzione, backup ecc...). In tale scenario risulta fonda-mentale un e�ciente utilizzo delle risorse. La pro�lazione dell'utente, intesosia come utente umano che come programma in esecuzione su una macchina,è una tecnica che permette di predire il comportamento dell'utente attraversol'identi�cazione con un modello noto a priori. Per pro�lare l'utente, quindi, ènecessaria la creazione di uno o più modelli che rappresentino i comportamentidi interesse dell'utente nell'ambito considerato. Ad esempio questi comporta-menti potrebbero riguardare l'utilizzo delle risorse. Per la creazione dei modelliè necessario raccogliere dati sul comportamento dell'utente, da cui si estrarran-no le features di interesse per la creazione dei modelli e / o l'identi�cazione delcomportamento utilizzandone uno esistente. Se il comportamento che si vuo-le modellare è l'utilizzo delle risorse, questo processo viene de�nito workloadcharacterization. In letteratura esistono delle proposte (esempio [MAER09] )di framework per il workload characterization in ambienti virtualizzati.

Obiettivo della tesi

Partendo da tali premesse, il problema a�rontato nella tesi, che fa parte del pro-blema più generale della pro�lazione utente, è l'identi�cazione di un program-ma in esecuzione su una macchina virtuale. L'obiettivo principale è realizzareun sistema che permetta di riconoscere, attraverso i dati ricavabili dall'APIdel Virtual Machine monitor, il programma in esecuzione sulla macchina vir-tuale. L'obiettivo principale comporta il raggiungimento dei seguenti obiettiviintermedi:

iv

INTRODUZIONE v

• capire se è possibile ricavare dati utili dai virtual machine monitor pre-senti sul mercato;

• assicurarsi che la raccolta dei dati non impatti eccessivamente nelle per-formance;

• realizzare i modelli dei programmi;

• testare i modelli realizzati;

il tutto in un ambiente il più simile possibile agli ambienti reali. La realizza-zione di un sistema che risolva il problema esposto è da ritenersi importantein quanto:

• potrebbe interessare ai sistemisti come strumento di scheduling e alloca-zione ottimale delle risorse;

• potrebbe interessare ai gestori di server virtualizzati per monitorare ilworkload del server;

• potrebbe essere impiegato per modellare il comportamento di malware.

Struttura della tesi

Il primo capitolo tratta il problema della virtualizzazione in generale, conl'obiettivo di inquadrare il problema nella giusta prospettiva.Nel secondo capitolo viene fatta una carrellata sulle tecniche di machinelearning impiegate nella realizzazione del sistema di user pro�ling.Il terzo capitolo tratta la suite di benchmark Spec CPU2006, utilizzata peravere dei programmi la cui esecuzione è facilmente ripetibile nelle stesse con-dizioni.Nel quarto capitolo viene fatta una valutazione dei principali Virtual Ma-chine Monitor presenti sul mercato al �ne di scegliere quello più adatto alloscopo, illustrandone vantaggi e svantaggiIl quinto capitolo descrive il Virtual Machine Monitor VirtualBox, assiemealla sua API.Nel sesto capitolo viene trattata l'analisi dei dati che estratti dall'API diVirtualBox.Il settimo capitolo contiene una descrizione del software realizzato.L'ottavo capitolo contiene la descrizione e i risultati degli esperimenti rea-lizzati.

Indice

Introduzione ivObiettivo della tesi . . . . . . . . . . . . . . . . . . . . . . . . . . . . ivStruttura della tesi . . . . . . . . . . . . . . . . . . . . . . . . . . . . v

Indice vi

Elenco delle �gure x

1 Macchine Virtuali 11.1 Introduzione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Virtualizzazione . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.3 Vantaggi delle macchine virtuali . . . . . . . . . . . . . . . . . . 21.4 Tassonomia della macchine virtuali . . . . . . . . . . . . . . . . 3

1.4.1 Macchine virtuali a livello di processo . . . . . . . . . . . 41.4.2 Macchine virtuali a livello di sistema . . . . . . . . . . . 5

2 Tecniche di Machine Learning 62.1 Introduzione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.2 Reti neurali . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.2.1 Il neurone arti�ciale . . . . . . . . . . . . . . . . . . . . 82.2.2 Connessioni tra i neuroni . . . . . . . . . . . . . . . . . . 102.2.3 Funzioni di attivazione e output . . . . . . . . . . . . . . 102.2.4 Topologie di rete . . . . . . . . . . . . . . . . . . . . . . 102.2.5 Addestramento di una rete neurale . . . . . . . . . . . . 11

2.3 K-means . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.4 Modelli di Markov nascosti . . . . . . . . . . . . . . . . . . . . . 132.5 DCT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152.6 Dempster-Shafer Therory . . . . . . . . . . . . . . . . . . . . . . 15

3 Spec 163.1 Introduzione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

vi

INTRODUZIONE vii

3.2 CPU2006 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163.3 Benchmarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.3.1 401.bzip2 . . . . . . . . . . . . . . . . . . . . . . . . . . 173.3.2 445.gobmk . . . . . . . . . . . . . . . . . . . . . . . . . . 173.3.3 458.sjeng . . . . . . . . . . . . . . . . . . . . . . . . . . . 183.3.4 403.gcc . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183.3.5 464.h264ref . . . . . . . . . . . . . . . . . . . . . . . . . 183.3.6 400.perlbench . . . . . . . . . . . . . . . . . . . . . . . . 183.3.7 429.mcf . . . . . . . . . . . . . . . . . . . . . . . . . . . 193.3.8 462.libquantum . . . . . . . . . . . . . . . . . . . . . . . 193.3.9 456.hmmer . . . . . . . . . . . . . . . . . . . . . . . . . 193.3.10 471.omnetpp . . . . . . . . . . . . . . . . . . . . . . . . 193.3.11 473.astar . . . . . . . . . . . . . . . . . . . . . . . . . . . 193.3.12 483.xalancbmk . . . . . . . . . . . . . . . . . . . . . . . 20

3.4 Input dei benchmark . . . . . . . . . . . . . . . . . . . . . . . . 20

4 Valutazione di diversi VMM 214.1 Introduzione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214.2 Valutazione dei VMM . . . . . . . . . . . . . . . . . . . . . . . 21

4.2.1 VMware vSphere Hypervisor . . . . . . . . . . . . . . . . 214.3 VMware Player . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

4.3.1 Virtual Box . . . . . . . . . . . . . . . . . . . . . . . . . 22

5 Virtual Box 245.1 Introduzione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245.2 VirtualBox . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

5.2.1 Virtualizzazione software-based . . . . . . . . . . . . . . 245.2.2 Virtualizzazione hardware-assisted . . . . . . . . . . . . . 255.2.3 Virtualizzazione delle periferiche . . . . . . . . . . . . . . 25

5.3 API di Virtual Box . . . . . . . . . . . . . . . . . . . . . . . . . 265.3.1 Considerazioni sulla API . . . . . . . . . . . . . . . . . . 26

6 Analisi dei dati 296.1 Introduzione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296.2 Aspetti legali . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296.3 Memory References . . . . . . . . . . . . . . . . . . . . . . . . . 30

6.3.1 Caratterizzazione della sequenza dei memory references . 306.3.2 Divisione in frame . . . . . . . . . . . . . . . . . . . . . 306.3.3 Divisione in blocchi . . . . . . . . . . . . . . . . . . . . . 326.3.4 Analisi spettrale tramite DCT . . . . . . . . . . . . . . . 33

6.4 Indicatori sull'utilizzo delle risorse . . . . . . . . . . . . . . . . . 34

INTRODUZIONE viii

6.4.1 Caratterizzazione della sequenza di indicatori sull'utiliz-zo delle risorse . . . . . . . . . . . . . . . . . . . . . . . . 36

7 Software realizzato 387.1 Introduzione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 387.2 Strumenti utilizzati . . . . . . . . . . . . . . . . . . . . . . . . . 387.3 Sistema di acquisizione dati . . . . . . . . . . . . . . . . . . . . 39

7.3.1 Architettura . . . . . . . . . . . . . . . . . . . . . . . . . 407.3.2 Funzionamento . . . . . . . . . . . . . . . . . . . . . . . 417.3.3 Problemi riscontrati durante lo sviluppo . . . . . . . . . 42

7.4 Creazione delle frame . . . . . . . . . . . . . . . . . . . . . . . . 457.4.1 Funzionamento . . . . . . . . . . . . . . . . . . . . . . . 467.4.2 Problemi riscontrati durante lo sviluppo . . . . . . . . . 48

7.5 Divisione in blocchi e clustering . . . . . . . . . . . . . . . . . . 487.5.1 Funzionamento . . . . . . . . . . . . . . . . . . . . . . . 487.5.2 Problemi riscontrati durante lo sviluppo . . . . . . . . . 50

7.6 Addestramento e test di rete neurale . . . . . . . . . . . . . . . 517.6.1 Funzionamento . . . . . . . . . . . . . . . . . . . . . . . 51

7.7 Addestramento e test di HMM . . . . . . . . . . . . . . . . . . . 547.8 Software per la fusione con Dempster-Shafer . . . . . . . . . . . 54

7.8.1 Funzionamento . . . . . . . . . . . . . . . . . . . . . . . 557.8.2 Problemi riscontrati durante lo sviluppo . . . . . . . . . 57

7.9 Riepilogo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

8 Esperimenti 598.1 Introduzione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 598.2 Preparazione ambiente . . . . . . . . . . . . . . . . . . . . . . . 598.3 Dataset acquisiti . . . . . . . . . . . . . . . . . . . . . . . . . . 59

8.3.1 Sistema utilizzato per i test . . . . . . . . . . . . . . . . 608.4 Esperimenti preliminari . . . . . . . . . . . . . . . . . . . . . . . 60

8.4.1 Test tempi di acquisizione . . . . . . . . . . . . . . . . . 618.4.2 Impatto sulle performance . . . . . . . . . . . . . . . . . 61

8.5 Clusterizzazione Kmeans . . . . . . . . . . . . . . . . . . . . . . 628.6 Test del sistema realizzato Kmeans - Rete neurale con memory

reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 638.6.1 Dimensioni e tempo di sovrapposizione delle frame . . . 648.6.2 Coe�cienti della DCT da considerare . . . . . . . . . . . 658.6.3 Numero di blocchi . . . . . . . . . . . . . . . . . . . . . 658.6.4 Numero di cluster . . . . . . . . . . . . . . . . . . . . . . 668.6.5 Numero di epoche di addestramento . . . . . . . . . . . 678.6.6 Selezione dei programmi per i test . . . . . . . . . . . . . 67

INTRODUZIONE ix

8.6.7 Riepilogo . . . . . . . . . . . . . . . . . . . . . . . . . . 698.6.8 Confronto rete neurale con HMM . . . . . . . . . . . . . 698.6.9 Impatto della frequenza di campionamento sui memory

references . . . . . . . . . . . . . . . . . . . . . . . . . . 708.7 Test del sistema realizzato Kmeans - Rete neurale con gli indi-

catori sull'utilizzo delle risorse . . . . . . . . . . . . . . . . . . . 718.8 Test della fusione dati con la tecnica di Dempster-Shafer . . . . 728.9 Esempio di funzionamento in ambiente reale . . . . . . . . . . . 73

Conclusioni e sviluppi futuri 75Riepilogo del lavoro svolto . . . . . . . . . . . . . . . . . . . . . . . . 76Sviluppi futuri . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

Bibliogra�a 79

Elenco delle �gure

1.1 La virtualizzazione consiste nella costruzione di un isomor�smo. . . 31.2 Il codice portabile viene eseguito sull'implementazione speci�ca del-

la macchina virtuale per una certa piattaforma. . . . . . . . . . . . 5

2.1 Componente base della rete neurale: il neurone. La regola dipropagazione è la somma pesata standard degli ingressi. . . . . . . 8

2.2 Neurone biologico. . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.3 Modello di Markov nascosto . . . . . . . . . . . . . . . . . . . . . . 13

5.1 VirtualBox ha un'architettura a livelli . . . . . . . . . . . . . . . . 265.2 Misurazioni puntuali dei tempi di risposta dell'API nei due modi

di utilizzo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

6.1 Sequenza di valori del registro IP assunti durante l'esecuzione delprogramma PerlBench . . . . . . . . . . . . . . . . . . . . . . . . . 31

6.2 Sequenza di valori del registro IP assunti durante un'altra esecu-zione del programma PerlBench . . . . . . . . . . . . . . . . . . . . 31

6.3 Operazione di framing del segnale . . . . . . . . . . . . . . . . . . . 326.4 Operazione di divisione in blocchi di una frame del segnale . . . . . 326.5 DCT del segnale . . . . . . . . . . . . . . . . . . . . . . . . . . . . 336.6 Percentuale utilizzo CPU User per 3 programmi in 2 esecuzioni

ciascuno. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 346.7 Percentuale utilizzo CPU Kernel per 3 programmi in 2 esecuzioni

ciascuno. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 356.8 Ram libera per 3 programmi in 2 esecuzioni ciascuno. . . . . . . . . 356.9 Fusione degli indicatori. . . . . . . . . . . . . . . . . . . . . . . . . 37

7.1 Architettura del software di acqusizione dati dalla VM. . . . . . . . 407.2 Esempio di struttura del database delle frame. . . . . . . . . . . . . 477.3 Architettura del software di fusione con Dempster-Shafer a partire

dai riconoscitori di memory reference e dati sull' utilizzo delle risorse. 557.4 Flusso dei dati nei programmi sviluppati. . . . . . . . . . . . . . . . 58

x

Elenco delle �gure xi

8.1 Tempi di acquisizione dati misurati per 1000 campioni. . . . . . . . 618.2 Tempi di esecuzione di bzip e gcc sulla macchina virtuale durante

l'acquisizione e non. . . . . . . . . . . . . . . . . . . . . . . . . . . 628.3 Tasso di corretto riconoscimento in funzione della durata della frame 638.4 Tasso di corretto riconoscimento in funzione del numero di programmi 648.5 Tasso di corretto riconoscimento in funzione della durata della frame 658.6 Tasso di corretto riconoscimento in funzione della percentuale di

sovrapposizione delle frame . . . . . . . . . . . . . . . . . . . . . . 668.7 Tasso di corretto riconoscimento in funzione del numero dei coe�-

cienti della DCT, con e senza componente continua. . . . . . . . . . 678.8 Tasso di corretto riconoscimento in funzione del numero di blocchi. 688.9 Tasso di corretto riconoscimento in funzione del numero di cluster. . 698.10 Tasso di corretto riconoscimento in funzione del numero di epoche

di addestramento. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 708.11 Tasso di corretto riconoscimento in funzione del numero di pro-

grammi. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 718.12 Tasso di corretta identi�cazione in funzione dell'abbattimento della

frequenza . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

1 Distribuzione di dettaglio del carico di lavoro. . . . . . . . . . . . . 772 Distribuzione per tipologia del carico di lavoro. . . . . . . . . . . . 77

Capitolo 1

Macchine Virtuali

1.1 Introduzione

I moderni computer sono delle strutture complesse e la loro esistenza è pos-sibile solo grazie all'abilità dei progettisti di gestire questa complessità. Lachiave per gestire la complessità nei computer è la loro divisione in livelli diastrazione separati da interfacce ben de�nite. I livelli di astrazione permettonodi nascondere o sempli�care i dettagli implementativi dei livelli inferiori e nelcontempo di sempli�care la progettazione dei livelli superiori. Ad esempio unprogrammatore può leggere e scrivere i �le senza nessuna conoscenza su co-me funziona l'hard disk. I livelli sono organizzati gerarchicamente con i livellibassi implementati nell'hardware e i livelli alti implementati nel software. Neilivelli hardware, tutti i componenti sono �sici, hanno proprietà tangibili e leinterfacce sono de�nite in modo tale da permettere la connessione �sica trale varie parti. Nei livelli software i componenti sono logici con pochi vincoliimposti dalle caratteristiche �siche. Ogni livello viene eseguito su una parti-colare macchina. Ad esempio, dal punto di vista del sistema operativo, unamacchina è composta in gran parte dall'hardware mentre dal punto di vistadei programmi utente, la macchina è una combinazione del sistema operativoe delle porzione dell'hardware accessibili tramite istruzioni di livello utente.Il vantaggio di de�nire delle interfacce tra i vari livelli consiste nel fatto chegli sviluppatori hardware e software possono lavorare più o meno in modo in-dipendente. Ad esempio i set di istruzioni permettono di slegare lo sviluppodei processori da quello dei compilatori. Il problema maggiore è dovuto al-l'esistenza di diverse speci�che di interfaccia[JS05]. Quindi programmi scrittiper processori con diversi set di istruzioni (Intel IA-32 e IBM PowerPC), oper diversi sistemi operativi (Windows e Linux) non sono compatibili tra diloro, nel senso che programmi scritti per una certa piattaforma non possono

1

CAPITOLO 1. MACCHINE VIRTUALI 2

essere eseguiti su un'altra. Un altro problema consiste nella dipendenza delsoftware dalle risorse hardware. Per risolvere questo problema i sistemi opera-tivi mettono a disposizione un'interfaccia astratta per l'accesso all'hardware,ad esempio per la memoria e per l'I/O. Questo approccio assume implicita-mente che le risorse hardware di un sistema siano gestite da un unico sistemaoperativo. Tuttavia questo approccio limita la �essibilità del sistema non solovincolando il software che può esservi eseguito ma anche in termini di sicurezzae robustezza, specialmente quando il sistema è multiutente.

1.2 Virtualizzazione

La virtualizzazione permette di rilassare i vincoli sopra esposti in modo da au-mentare la �essibilità del sistema nel senso sopra esposto. Quando un sistema(o sottosistema) è virtualizzato, la sua interfaccia e le sue risorse sono mappa-te nell'interfaccia e nelle risorse del sistema reale che lo implementa. Questotrasforma il sistema reale in un sistema diverso o addirittura in un insieme disistemi diversi. Formalmente la virtualizzazione consiste nella costruzione diun isomor�smo, illustrato in �gura 1.1, che mappa un sistema virtuale ospite(guest) in un sistema ospitante (host) [GJP74]. Questo isomor�smo mappalo stato del sistema guest nello stato del sistema host (funzione V in �gura)in modo tale che per ogni sequenza di operazioni ei che modi�ca lo stato nelguest da Si a Sj ci sia una corrispondente sequenza di operazioni ei

′nell'host

che ne modi�ca lo stato da Si′a Sj

′.

Sebbene un tale isomor�smo possa essere utilizzato anche per caratteriz-zare un'astrazione del sistema sottostante facciamo la seguente distinzione: lavirtualizzazione di�erisce dall'astrazione in quanto essa non maschera il livellosottostante. Infatti il livello di astrazione in un sistema virtuale è spesso lo stes-so del sistema sottostante. Il concetto di virtualizzazione può essere applicatoai sottosistemi, come i dischi, ma anche a intere piattaforme. Una macchinavirtuale è implementata aggiungendo uno strato software alla macchina reale.

1.3 Vantaggi delle macchine virtuali

In generale, una macchina virtuale, può risolvere i problemi di compatibilitàe i limiti dell'hardware delle macchine reali garantendo così un elevato gradodi portabilità del software. L'utilizzo di più macchine virtuali in un sistemamultiutente garantisce una migliore sicurezza grazie all'isolamento. Inoltre èpossibile sfruttare al meglio le risorse disponibili. Le macchine virtuali rendo-


Figura 1.1: La virtualizzazione consiste nella costruzione di un isomor�smo.

no inoltre possibile, impiegando tecniche di emulazione, l'utilizzo di softwarescritto per altre piattaforme.

1.4 Tassonomia della macchine virtuali

Dal punto di vista di un processo utente, la macchina consiste nella spaziodi memoria indirizzabile assegnato al processo, i registri della CPU e le istru-zioni che ne permettono l'esecuzione. L'I/O è accessibile solo attraverso lechiamate al sistema operativo, spesso raggruppate in librerie che sono parteintegrante del processo. Dal punto di vista del processo utente, la macchina ècostituita dal sistema operativo e dall'hardware sottostante. Dal punto di vistadel sistema operativo, invece, la macchina è costituita soltanto dell'hardwaresottostante. In modo analogo possiamo de�nire macchine virtuali a livello diprocesso e a livello di sistema operativo. Una macchina virtuale a livello di pro-cesso è in grado di eseguire un singolo processo. In questo caso il software dellamacchina virtuale si colloca sopra il sistema operativo. La macchina virtualeemula sia le istruzioni a livello utente sia le chiamate di sistema. Una macchinavirtuale a livello di sistema fornisce un ambiente completo. In questo caso ilsoftware di virtualizzazione viene collocato idealmente sopra l'hardware. Nellemacchine virtuali a livello di sistema, il software virtualizzante viene spessochiamato anche Virtual Machine Monitor (VMM).


1.4.1 Macchine virtuali a livello di processo

Le macchine virtuali a livello di processo forniscono alle applicazioni utenteun ambiente ABI (Application Binary Interface) virtuale. Un ambiente ABIè l'insieme delle chiamate di sistema e delle istruzioni della CPU che sonoeseguibili a livello utente. Di questa tipologia di macchine virtuali fanno partele categorie descritte in seguito.

• Multiprogrammazione. La maggior parte dei moderni sistemi opera-tivi supporta l'esecuzione contemporanea di più processi utente. Ogniprocesso ha l'illusione di avere a disposizione l'intera macchina. Il siste-ma operativo assegna al processo uno spazio di indirizzamento, l'accessoai �le e alle periferiche. Inoltre gestisce l'assegnazione delle risorse inbase ad una certa politica (es. round robin). Il sistema operativo quindicrea una macchina virtuale a livello di processo per ogni processo utentein esecuzione.

• Emulatori. Vengono impiegati quando è necessario eseguire program-mi compilati per un'ISA di�erente (ma stesso sistema operativo). Unesempio è il Digital FX!32 System che permette l'esecuzione di program-mi scritti per Windows NT su piattaforma IA-32, su Windows NT perarchitettura Alpha.

• Ottimizzatori binari SAME-ISA. L'ISA dei sistemi host e guest è lostesso. E�ettuano pro�ling del codice eseguibile al �ne di ottimizzarlodinamicamente.

• High level language virtual machines. Le macchine virtuali de-scritte in precedenza hanno come obiettivo primario quello di rendereportabili i programmi utente da un sistema ad un altro. Le High levellanguage virtual machines risolvono il problema in un modo diverso. In-fatti l'ambiente virtualizzato non corrisponde a nessun ambiente reale. Ilsistema viene progettato focaliazzndo l'attenzione sulla portabilità multi-piattaforma, evitando l'implementzione di macchine virtuali per ciascunacoppia host - guest. Il software compilato per la macchina virtuale è fa-cilmente portabile a patto che esista l'implementazione della macchinavirtuale per la piattaforma di destinazione (si veda la �gura 1.2). Esempidi questa categoria sono Java VM e Microsoft CLI (Common LanguageInfrastructure).


Figura 1.2: Il codice portabile viene eseguito sull'implementazione speci�cadella macchina virtuale per una certa piattaforma.

1.4.2 Macchine virtuali a livello di sistema

Le macchine virtuali a livello di sistema forniscono un ambiente virtualizza-to completo a partire dall'hardware. Possono impiegare anche tecniche diemulazione nel caso di di�erenti ISA. Vengono impiegate principalmente perpermettere l'esecuzione (anche simultanea) di di�erenti sistemi operativi (es.Linux su Windows) e per fornire maggiori garanzie di isolamento negli ambien-ti multiutente. Il VMM cattura le istruzioni privilegiate eseguite dal sistemaoperativo guest, controlla la loro correttezza e le esegue sulla macchina realein modo trasparente. Il VMM può essere posto direttamente sull'hardwareoppure sopra il sistema operativo host. Nel primo caso è richiesta la rimozionedi eventuali sistemi operativi installati. Nel secondo caso, invece, il VMM èinstallato come un comune programma sopra il sistema operativo host. In que-sto caso parleremo di hosted VM. Il principale vantaggio di questa soluzioneè che vengono sfruttati i servizi di sistema per la gestione delle periferiche edelle risorse che non devono essere implementati nel VMM. Lo svantaggio con-siste nell'avere molti strati software aggiuntivi a discapito dell'e�cienza. Unesempio del primo tipo è il famoso VMware vSphere Hypervisor. Esempi delsecondo tipo sono VMware Player e Oracle Virtual Box

Capitolo 2

Tecniche di Machine Learning

2.1 Introduzione

Per machine learning si intende il processo che porta alla costruzione, a partireda un insieme di dati, di un modello che descriva i dati stessi. Un modo tipi-camente utilizzato per realizzare quanto espresso, è postulare l'esistenza di unqualche tipo di meccanismo parametrico per la generazione dei dati, di cui nonconosciamo però i valori esatti dei parametri. Questo processo fa tipicamenteriferimento a tecniche di tipo statistico. L'estrazione di leggi generali a partireda un insieme di dati osservati viene denominata induzione, e si contrapponealla deduzione in cui, a partire da leggi generali, si vuole prevedere il valore diun insieme di variabili. L'induzione è il meccanismo fondamentale alla base delmetodo scienti�co, attraverso il quale si vogliono derivare delle leggi generali(tipicamente descritte in linguaggio matematico) a partire dall'osservazione dialcuni fenomeni. L'osservazione comprende la misurazione di un insieme divariabili del fenomeno oggetto di studio, e la successiva acquisizione dei datiche sono rappresentativi del fenomeno osservato. Il modello ottenuto potràquindi essere utilizzato per e�ettuare previsioni sull'evoluzione del fenomenoanalizzato. Questo metodo si de�nisce inferenza.

2.2 Reti neurali

Le reti neurali arti�ciali sono nate per riprodurre attività tipiche del cervelloumano come la percezione di immagini, il riconoscimento di forme, la com-prensione del linguaggio, il coordinamento senso-motorio, ecc. Le reti neuraliarti�ciali possono essere caratterizzate come modelli di computazione in cui lacomplessità computazionale viene mutuata da una maggiore complessità spa-ziale. La computazione è di tipo collettivo ed emerge come proprietà dell'evo-

6

CAPITOLO 2. TECNICHE DI MACHINE LEARNING 7

luzione dinamica della rete. Ogni decisore locale (neurone) non ha visibilitàdella computazione globale e concorre alla soluzione globale in modo sfuma-to. La rete è robusta rispetto a malfunzionamenti locali. Vengono impiegatesolitamente per le loro capacità di adattamento (apprendimento), di genera-lizzazione, di classi�cazione (o clusterizzazione) delle informazioni. In seguitoillustriamo pregi e difetti di questo modello computazionale.

• Pregi:

� largo impiego come classi�catori;

� robustezza rispetto ai pesi (guasti);

� risposte in tempo reale nel caso di realizzazione hardware e moltoveloci quando emulate via software;

� la metafora biologica lascia ben sperare in futuri miglioramenti.

• Difetti:

� manca una loro formalizzazione matematica adeguata;

� non ci sono garanzie sulla qualità delle soluzioni trovate; e in gene-rale non si ottengono soluzioni ottime;

� problema dei falsi minimi;

� escono sempre scon�tte nel confronto con algoritmi dedicati;

� altissima complessità strutturale;

� dipendenza dei pesi dal problema (il che rende di�cile la realizza-zione hardware) determinati durante l'addestramento;

Una rete neurale arti�ciale è composta da un insieme di semplici unità dielaborazione le quali comunicano inviando segnali l'una all'altra attraverso ungran numero di connessioni pesate. Per de�nire una rete neurale arti�cialedobbiamo de�nire:

• insieme di unità di elaborazioni (neuroni,celle)

• uno stato di attivazione yk per ogni unità, il quale è equivalente all'uscitadell'unità

• connessioni tra le unità. Generalmente ogni connessione è de�nita da unpeso wjk che determina l'e�etto che il segnale di uscita dell'unità j hasull'unità k

• una regola di propagazione, che determina l'e�ettivo complessivo degliinput, detto sk, di una unità a partire dagli ingressi esterni


• una funzione di attivazione Fk la quale determina il nuovo livello diattivazione, basandosi sull'e�etto complessivo degli input sk(t) e il livellocorrente di attivazione yk(t)

• un ingresso di disturbo θk per ogni unità

• le regole di apprendimento

• un ambiente nel quale il sistema dovrà operare, cioè nel quale prelevarei segnali di ingresso e fornire i i segnali in uscita

La �gura 2.1 rappresenta questi concetti. Si confronti con un neurone biologico2.2.

Figura 2.1: Componente base della rete neurale: il neurone. La regola dipropagazione è la somma pesata standard degli ingressi.

2.2.1 Il neurone arti�ciale

Il neurone arti�ciale è un modello matematico molto sempli�cato del neuronebiologico. Ad ogni input yj è associato un peso wjk. Il disturbo θk vienefatto fariare secondo la propensione del neurone ad attivarsi, per modi�care lasoglia di attivazione del neurone stesso. Una singola unità (chiamata neuroneper analogia biologica) kesegue un lavoro semplice: riceve gli input dai vicinio dall'esterno ed elabora il segnale di uscita il quale sarà propagato agli altrineuroni secondo questo algoritmo:

1. per ogni connessione i caricare i valori degli input yi e dei pesi relativiwik


Figura 2.2: Neurone biologico.

2. calcolare il valore sk tenendo conto degli input, dei pesi, e del disturbo

3. calcolare il valore della funzione di attivazione Fk con sk

4. l'output del neurone yk è il risultato della funzione di attivazione

Riassumendo:yk(t) = F (sk(t) + θk) (2.1)

Oltre a questo deve essere in grado di modi�care i pesi delle connessioni. Ilsistema è intrinsecamente parallelo nel senso che le unità eseguono la compu-tazione contemporaneamente. Si distinguono tre tipi di neuroni: neuroni diinput, che ricevono i dati dall'esterno della rete, neuroni di output, che forni-scono i dati in uscita dalla rete e neuroni nascosti, i cui segnali, cioè, restanocon�nati all'interno della rete. Nel corso del funzionamento, i neuroni possono


aggiornarsi in modo sincrono o asincrono. Nel modo sincrono tutti i neuro-ni aggiornano la loro funzione di attivazione contemporaneamente; nel modoasincrono ogni neurone ha una creta probabilità di aggiornare la sua funzio-ne di attivazione al tempo t, e solitamente un solo neurone alla volta vieneaggiornato.

2.2.2 Connessioni tra i neuroni

Nella maggior parte dei casi si assume che ogni neurone porti un contributoadditivo al neurone al quale è collegato. L'input totale sk è semplicemente lasomma pesata dei diversi output dei neuroni collegati più il disturbo θk:

sk(t) =∑j

wjk(t)yj(t) + θk(t) (2.2)

Per wjk positivi si dice che l'ingresso eccita il neurone e per wjk negatitvi sidice che l'ingresso inibisce il neurone. De�niamo neuroni sigma, i neuroni lacui regola di propagazione segue la 2.2.

2.2.3 Funzioni di attivazione e output

è necessario avere delle regole per stabilire quale sia l'e�etto dell'input com-plessivo sull'attivazione del neurone. Resta così de�nata una funzione Fk che,sulla base dell'input complessivo sk(t) e l'attivazione corrente del neurone yk(t)produce il nuovo valore dell'attivazione:

yk(t+ 1) = Fk(yk(t), sk(t)) (2.3)

Molto spesso Fk dipende solo dall'input complessivo in quell'istante e quindila 2.3 può essere scritta come

yk(t+ 1) = Fk(sk(t)) = Fk(sk(t) =∑j

wjk(t)yj(t) + θk(t)) (2.4)

Normalmente Fk ha valori nell'intervallo [−1,+1]. Le funzioni più usate sonola funzione segno, la funzione lineare, o la funzione sigmoide 2.5

yk = F (sk) =1

1 + e−sk(2.5)

2.2.4 Topologie di rete

Come topologia, le reti neurali possono essere distinte in due casi:


• reti feed-forward, dove il �usso delle informazioni tra l'ingresso e l'uscitaviaggia a senso unico verso l'uscita. L'elaborazione può essere estesa amolti livelli di neuroni, ma non deve essere presente nessun feedback,ossia non sono presenti connessioni dall'uscita all'ingresso dei neuronidei livelli precedenti o dello stesso livello.

• reti ricorsive. Contrariamente alle feed-forward queste reti presentanoconnessioni di feedback. La dinamica della rete è importante. La re-te è vincolata ad evolvere verso uno stato stabile in cui le funzioni diattivazione non cambiano.

Esempio classico del primo tipo è il Perceptron, mentre del secondo tipo è larete di Hop�eld.

2.2.5 Addestramento di una rete neurale

Una rete neurale deve essere con�gurata in modo tale che l'applicazione degliingressi produca l'uscita desiderata. È quindi necessario modi�care il pesodelle connessioni. Una tecnica potrebbe essere impostare direttamente i pesi,usando una qualche forma di conoscenza a priori. Un altro metodo potrebbeessere quello di addestrare la rete modi�cando iterativamente i pesi in basea qualche regola di apprendimento. Possiamo ulteriormente dividere questosecondo caso in:

• Apprendimento supervisionato: la rete è addestrata fornendo una seriedi esempi composti da input e rispettivo output atteso.

• Apprendimento non supervisionato: un neurone di uscita è addestratoa rispondere a delle classi di input. In questo paradigma, il sistemadeve dividere autonomamente gli input in classi. A di�erenza dell'altrometodo non vengono de�nite a priori le classi in cui gli input sono divisi.

Per maggiori approfondimenti sugli algoritmi di apprendimento si rimanda a[BK96] e [PBL]

2.3 K-means

K-means [Mac67] è un algoritmo di apprendimento non supervisionato che ri-solve il problema di clusterizzare, ovvero di classi�care, un insieme di nvettoridi dimensione m in k classi, con k �ssato a priori. L'idea principale è de-�nire k centroidi, uno per ogni cluster. Come primo passo dell'algoritmo, icentroidi devono essere posizionati nello spazio (m-dimensionale) in modo da


massimizzare la distanza tra essi. Il passo successivo prevede di prendere tuttigli n vettori appartenenti all'insieme dei dati e associarli al centroide più vi-cino, creando così k cluster. Successivamente si ricalcolano i centroidi comebaricentro dei cluster risultanti dal passo precedente. Nel passo seguente siriassociano i vettori ai nuovi centroidi. Si rieseguono questi ultimi passi �nchéla posizione dei centroidi varia sensibilmente da un'interazione ad un altra.Formalmente, l'algoritmo ha come scopo la minimizzazione di una funzioneobiettivo:

J =k∑

j=1

n∑i=1

‖x(j)i − cj‖2

(2.6)

dove con la scrittura x(j)i si intende che il vettore xi partecipa alla somma se

appartiene al cluster j e ‖x(j)i − cj‖2è la distanza tra il vettore xi e il centroide

cj. Formalmente l'algoritmo è composto dai seguenti passi:

1. Scegliere K punti dello spazio m-dimensionale dove si trovano gli n datida classi�care. Questi punti rappresentano i centroidi iniziali;

2. Assegnare ogni vettore xi al centroide cj più vicino;

3. Ricalcolare la posizione dei K centroidi come baricentro di ciascun clu-ster;

4. Ripetere i passi 2 e 3 �no a che i centroidi restano nella medesima posi-zione da un'iterazione alla successiva. Il risultato è un raggruppamentodegli oggetti che porta alla minimizzazione della funzione 2.6.

Sebbene si possa dimostrare che l'algoritmo termina sempre, non necessaria-mente esso trova la con�gurazione ottimale, corrispondente al minimo dellafunzione obiettivo. L'algoritmo è sensibile alla selezione iniziale dei centroidi.Esso può essere eseguito con diversi centroidi iniziali per ridurre questo e�etto.L'algoritmo si può classi�care come algoritmo greedy (avido). Esso presentaalcuni difetti:

• Il modo di inizializzare i centroidi non viene speci�cato dall'algoritmo.Di solito si scelgono a caso k vettori nell'insieme dei dati

• Il risultato ottenuto dipende dalla scelta dei centroidi iniziali, e frequen-temente porta ad una soluzione subottima. La soluzione, come già detto,consiste nel ripetere l'algoritmo con diversi centroidi iniziali e considerareil valore migliore della funzione obiettivo;


• Può accadere che ad una certa iterazione dell'algoritmo, alcuni cluster ri-sultino vuoti e quindi che il relativo centroide non possa essere ricalcolato.La soluzione di questo problema è lasciata alle varie implementazioni.

• Il risultato dipende dalla metrica utilizzata per misurare ‖xi − cj‖.

• Il risultato dipende dal valore k

L'ultimo problema in particolare è dovuto al fatto che non si conosce a prioriil numero di cluster in cui si vuole dividere l'insieme. Sfortunatamente nonesiste, in generale, un metodo per trovare il numero ottimale di cluster. Unapproccio semplice consiste nel provare diversi valori di k incrementando ilvalore di volta in volta. Un valore troppo elevato porta ad un numero maggioredi cluster vuoti. Per approfondimenti si veda [Moo]

2.4 Modelli di Markov nascosti

Figura 2.3: Modello di Markov nascosto

Una catena markoviana a tempo discreto è una sequenza aleatoria qn taleche la variabile successiva dipende solamente dalla variabile precedente. Ilsistema può essere quindi descritto da una sequenza di stati, che corrispondonoa degli eventi osservabili. Ad ogni istante del tempo discreto il sistema passa dauno stato all'altro con una certa probabilità di transizione. Lo stato attualeqn riassume quindi la storia del sistema per prevedere l'elemento successivoqn+1. Una catena di Markov è un modello troppo restrittivo per poter essereapplicato al problema di interesse. Il modello può essere esteso al caso incui le osservazioni siano una funzione probabilistica dello stato e quindi non


osservabili direttamente. Le osservazioni sono cioè nascoste. Un modello diMarkov nascosto è caratterizzato da:

• il numero di stati N , con l'insieme degli stati S = S1, ..., SN e con qt lostato al tempo t

• il numero di simboli osservati M , ovvero la dimensione dell'alfabetodiscreto. Indichiamo l'insieme dei simboli con V = V1, ..., VM

• la matrice di transizione tra stati A = [aij]dove

aij = P [qt+1 = Sj|qt = Si], 1 ≤ i, j ≤ N (2.7)

è la probabilità di passare dallo stato Si allo stato Sj .

• la distribuzione delle osservazioni nello stato j : bj(k), dove

bj(K) = P [Vk|qt = Sj], 1 ≤ j ≤ N, 1 ≤ k ≤M (2.8)

è la probabilità di osservare il simbolo Vk se all'istante t il sistema sitrova nello stato j.

• il vettore delle probabilità iniziali π, dove

πj = P [q1 = Sj], 1 ≤ j ≤ N (2.9)

è la probabilità che il sistema si trovi all'istante iniziale nello stato Sj

Si può quindi indicare un modello di Markov nascosto con λ = (A,B, π). Ilprocesso di apprendimento di un modello di Markov implica la ricerca dei pa-rametri (A,B, π) tali da massimizzare la probabilità di riconoscere la sequenzadi osservazioni. Poiché non si conosce una soluzione analitica che trovi un mas-simo assoluto si utilizza una procedura iterativa. L'algoritmo di Baum-Welchin [LEBW70] fa questo in modo e�ciente utilizzando soltanto la sequenza disimboli emessi come dati di addestramento. La parte nascosta di un hmm,cioè la sequenza di stati, non può essere scoperta, ma può essere interpretatain qualche modo signi�cativo. L'algoritmo di Viterbi in [JF73] permette digenerare la sequenza più probabile di stati relativi ad un dato modello hmm.Inoltre avendo una sequenza di simboli l'algoritmo di Viterbi rende possibileveri�carne l'a�nità con un modello hmm calcolandone la probabilità.


2.5 DCT

La trasformata discreta del coseno o DCT (dall'inglese Discrete Cosine Tran-sform), è la più di�usa funzione che provvede alla compressione spaziale, capacedi rilevare le variazioni di informazione tra un'area e quella contigua trascu-rando le ripetizioni[Wik]. Ad esempio, è utile per ridurre la ridondanza di unsegnale in quanto tende a concentrare più energia possiblie in meno coe�cientipossibile (compressione energetica)[Str99].

2.6 Dempster-Shafer Therory

La teoria di Dempster-Shafer è una teoria matematica delle attestazioni, in-tendendo con attestazione qualsiasi cosa supporti un'asserzione. Permette dicombinare insieme attestazioni provenienti da diverse fonti e arrivare ad ungrado di credibilità (belief) dell'asserzione, tenendo conto di tutte le attesta-zioni disponibili. Per maggiori informazioni si veda [Sga11]. Tale tecnica èstata considerata nel corso della tesi in quanto applicata con successo in casianaloghi. L' articolo [AM13] fornisce uno spunto per l'utilizzo di tale tecnicanegli esperimenti successivi.

Capitolo 3

Spec

3.1 Introduzione

Spec 2006 si presenta come lo standard per la misura e la valutazione delleprestazioni di un sistema. L'utilizzo di un set di benchmark standard rendepossibile la comparazione dei risultati tra macchine, compilatori e opzioni dicompilazione di�erenti tra loro.

3.2 CPU2006

Spec CPU2006 si concentra sulla performance del processore, sull'architetturadella memoria e sulla capacità del compilatore di produrre codice ottimizzato[Doc]. Altri fattori che spesso incidono sulle performance delle applicazioni(networking, I/O) sono qui considerati trascurabili, in quanto i singoli ben-chmark sono stati sviluppati per ottenere il maggiore impatto possibile sullacpu e sulla memoria rispetto al resto delle componenti del sistema. Spec sicompone di due suite di benchmark principali:

• CINT2006

• CFP2006

La prima e�ettua un'analisi delle performance del sistema nelle operazioni suvalori interi, la seconda nel caso di operazioni a virgola mobile ( foating point).Ognuna delle due suite si compone di diversi benchmark (12 per CINT2006,17 per CFP2006).

16

CAPITOLO 3. SPEC 17

3.3 Benchmarks

SpecCPU2006 si pre�gge di calcolare le prestazioni di un sistema simulando unworkload il più verosimile possibile, per questo molti dei benchmark sono delleversioni adattate e modi�cate di applicazioni reali. Tali applicazioni hanno incomune un'elevata intensità computazionale: la maggior parte del tempo spesoda esse è dedicato ad operazioni di calcolo, con pochissimo overhead causatoda input/output. Sono state apportate delle modi�che ai sorgenti a�nché itest eseguano la gran parte delle operazioni di IO in memoria e non su �le,e a�nché la memoria utilizzata rimanga inferiore ad 1GB per evitare che ilsistema debba e�ettuare swap verso il disco. Le applicazioni sono state sceltebasandosi anche su criteri di portabilità, in quanto Spec- CPU2006 può esserecompilato su una moltitudine di architetture e sistemi operativi di�erenti.

3.3.1 401.bzip2

401.bzip2 è la versione adattata a SpecCPU2006 del programma bzip2, il qualee�ettua compressione dati. 401.bzip2 si basa sulla versione 1.0.3 di bzip2 diJulian Seward, con la di�erenza che 401.bzip2 non e�ettua operazioni di I/Ose non nella lettura dei �le da comprimere. Tutta la compressione e la decom-pressione avviene quindi in memoria. Ogni �le viene compresso e decompresso3 volte, a fattore crescente: 5, 7 e 9. I risultati della decompressione sono poiconfrontati con il set di input per validare la buona riuscita del test. 401.bzipinizializza in memoria 3 bu�er di dimensione adeguata ad ospitare il �le di in-put, lo stream compresso e lo stream decompresso. Dopo aver caricato il �le,le successive operazioni di lettura e scrittura sono e�ettuate tutte in memoriasenza snaturare il codice di bzip2 tramite le de�ne:

./bzlib.h:98: #define read(a,b,c) spec_read(a,b,c)

./bzlib.h:104: #define write(a,b,c) spec_write(a,b,c)

spec_read e spec_write non sono altro che wrapper di memcpy che gestisconogli EOF e che fanno corrispondere ai �le descriptor i bu�er precedentementeallocati.

3.3.2 445.gobmk

445.gobmk è una versione di GNU Go alla quale vengono presentate diverseposizioni di gioco. Il gioco del Go è considerato un problema di intelligenzaarti�ciale che richiede uno sforzo computazionale elevato in quanto le combina-zioni possibili di pezzi sulla scacchiera (goban) nella partita sono moltissime.

CAPITOLO 3. SPEC 18

I �le di input utilizzati benchmark sono �le di testo che descrivono diverseposizioni di gioco, l'output corrisponde nella mossa successiva da e�ettuare.

3.3.3 458.sjeng

458.sjeng è una versione leggermente modi�cata di Sjeng 11.2, un programmache gioca a scacchi ed analizza e valuta posizioni di gioco. La versione propostada Spec rende le ricerche nell'albero delle varianti delle mosse deterministichee quindi il workload del test sempre uguale. L'input di riferimento del test ècomposto da 9 di�erenti posizioni di gioco e dalla profondità alla quale vannoanalizzate da Sjeng.

3.3.4 403.gcc

403.gcc è basato sulla versione 3.2 di GNU gcc, con�gurato per generare codiceassembly x86-64 per un processore AMD Opteron con diversi �ag di ottimiz-zazione abilitati. 403.gcc è stato adattato da Spec alterando l'euristica nellescelte di utilizzare funzioni inline a�nché il programma spendesse più temponell'analisi del codice sorgente e utilizzasse più memoria della versione stan-dard. L'input è dato da �le sorgenti per i quali deve essere generato l'assemblycorrispondente.

3.3.5 464.h264ref

464.h264ref è l'implementazione di Karsten Sühring dello standard di compres-sione video H.264/AVC. Le modi�che introdotte dal team di Spec facilitanola portabilità del codice ma sono state ridotte al minimo per garantire che iltest si avvicinasse il più possibile ad un caso d'uso reale di video encoding.In particolare, è stata rimossa la parte dei sorgenti riguardante il decoder (iltest e�ettua solo la compressione in h264, non la decompressione) ed è statosoppresso l'output a �le di log per minimizzare l'I/O. L'input è composto dadue video in formato raw ognuno dei quali viene compresso con due pro�lidi�erenti (good compression e best compression).

3.3.6 400.perlbench

400.perlbench è Perl v5.8.7 al quale sono state rimosse tutte le feature relativeai singoli sistemi operativi. A questi sono stati aggiunti alcuni moduli esterni:SpamAssassin, MailTools, Digest-MD5, HTMLParser... I moduli vengono uti-lizzati per la manipolazione di messaggi email trasformandoli in pagine html,calcolandone checksum md5 e rilevando con che probabilità si tratta di spam.

CAPITOLO 3. SPEC 19

3.3.7 429.mcf

429.mcf deriva da un software di scheduling del tra�co utilizzato in ambitopubblico. 429.mcf genera un elevato carico sulla cpu eseguendo un algorit-mo che implementa il metodo del simplesso su rete. Il codice del programmaoriginale è stato modi�cato per ridurre il numero di cache miss e quindi in-crementare l'impatto sulla cpu rispetto alla memoria. Questo è stato ottenutomodi�cando l'ordine degli elementi persenti nelle struct maggiormente utilizza-te dal benchmark. L'input al benchmark consiste in un �le di testo contenenteun insieme di percorsi da ottimizzare.

3.3.8 462.libquantum

462.libquantum simula un computer quantistico, eseguendo l'algoritmo di fat-torizzazione di Peter Shor. Il benchmark si aspetta in input un numero eresituisce l'elenco dei suoi fattori. Su un computer quantistico l'algoritmo tro-va i fattori con margine d'errore arbitrariamente piccolo in tempo polinomialerispetto alla dimensione del numero in input.

3.3.9 456.hmmer

456.hmmer utilizza algoritmo hmm per analizzare sequenze di dna. In input ilbenchmark si aspetta un �le database contente i modelli di riferimento e unasequenza nella quale e�etuare la ricerca delle sequenze del database.

3.3.10 471.omnetpp

471.omnetpp simula una vasta rete ethernet basandosi sul sistema di simula-zione discreto OMNeT++. OMNeT++ implementa completamente CSMA/CD, i frame ethernet e IP per una simulazione del carico sulle reti. Il ben-chmark simula una rete contente circa 8000 computer e 900 tra switches ehubs suddivisi in diverse subnet. Il benchmark prende in input la topologia diuna rete e la con�gurazione degli host, e procede aumentando esponenzialmen-te il volume di tra�co simulando anche perdite di pacchetti. In ouput sonoprodotte statistiche dettagliate sulla simulazione.

3.3.11 473.astar

473.astar deriva da una libreria di ricerca del percorso minimo utilizzata per leintelligenze arti�ciali nei videogames. In input accetta una mappa in formatobinario e il tipo di algoritmi da applicare per poi stampare le vie possibili peril raggiungimento della destinazione.

CAPITOLO 3. SPEC 20

3.3.12 483.xalancbmk

483.xalancbmk deriva da Xalan-C++, un software che processa documentiXML trasformandoli secondo fogli di stile XSL. Implementa lo standard W3Cdelle XSL Transformations e di XML. Per renderlo un benchmark di Spec èstato selezionato un test-set da processare di notevole dimensioni (100MB)consistente in un �le XML e un foglio di stile XSL da trasformare in HTML.

3.4 Input dei benchmark

Per ciascun benchmark sono presenti 3 di�erenti classi di input, che riportiamoin ordine di complessità:

• test;

• train;

• ref.

Per ogni benchmark sono stati misurati i tempi di esecuzione di ciascuna classedi input. Utilizzando un parametro è possibile speci�care il numero di esecu-zioni del programma da e�ettuare in ogni esecuzione del benchmark. Consi-derando una durata temporale �ssata a priori è pertanto possibile calcolare ilnumero di esecuzioni del programma per ogni benchmark.

Capitolo 4

Valutazione di diversi VMM

4.1 Introduzione

Al �ne di perseguire l'obiettivo del lavoro è stato necessario esaminare alcuniVMM presenti sul mercato. Ovviamente la scelta naturale è ricaduta su mac-chine virtuali di sistema in modo da avere a disposizione tutte le statistichee le informazioni necessarie. Tra queste in particolare sono stati presi in con-siderazione i seguenti VMM: VMware vSphere Hypervisor, VMware Player eVirtual Box.

4.2 Valutazione dei VMM

Nelle fasi preliminari della tesi sono stati presi in considerazione vari prodottisia gratuiti che a pagamento. I prodotti a pagamento, pur presentando featuresdi notevole pregio per un utilizzo commerciale, non si sono rivelati migliori diquelli gratuiti ai �ni della tesi. Un altro fattore tenuto in considerazione è ladi�usione sul mercato di questi prodotti.

4.2.1 VMware vSphere Hypervisor

Versione gratuita del software VMware vShpere. è un VMM da installaradirettamente sull'hardware. La gestione avviene completamente da remoto.Vantaggi:

• non essendoci il sistema operativo host ha un overhead ridotto;

• API ben documentate.

Svantaggi:

21

CAPITOLO 4. VALUTAZIONE DI DIVERSI VMM 22

• API non permettono di collezionare dati sul funzionamento (registri cpu);

• necessità di una macchina dedicata all'installazione.

4.3 VMware Player

VMware Player è un software freeware di virtualizzazione (virtual machine)prodotto da VMware la cui prima versione è stata rilasciata nel dicembre del2005. Si tratta di un hosted VMM. è in grado di creare ed eseguire qualunqueimmagine di macchina virtuale precedentemente creata.Vantaggi:

• si installa come una normale applicazione;

• API ben documentate;

• ottime performance.

Svantaggi:

• API non permettono di collezionare dati sul funzionamento (registri cpu);

• overhead maggiore dovuto a un maggior numero di strati software;

• non open source.

4.3.1 Virtual Box

VirtualBox o Oracle VM VirtualBox (e precedentemente Sun VirtualBox, SunxVM VirtualBox e Innotek VirtualBox), è un hosted VMM open source perarchitettura x86 che supporta Windows, GNU/Linux e Mac OS X come sistemioperativi host, ed è in grado di eseguire Windows, GNU/Linux, OS/2 Warp,OpenBSD e FreeBSD come sistemi operativi guest.Vantaggi:

• le API disponibili permettono di collezionare statistiche e dati relativiallo stato interno;

• software open source;

• semplicità di utilizzo paragonabile ad analoghi prodotti commerciali.

Svantaggi:

• scarsa documentazione delle API (mancano sopratutto esempi);

CAPITOLO 4. VALUTAZIONE DI DIVERSI VMM 23

• leggermente meno performante rispetto a VMware Player [VMSD12].

Tenendo conto dell'obiettivo della tesi, Virtual Box è risultato il migliore, so-pratutto perché sono disponibli le API che permettono di raccogliere informa-zioni di basso livello sulla macchina virtuale. Esiste, in ambiente VMware untool denominato VProbe che è in grado di fornire analoghe informazioni sullamacchina virtuale. Il suo utilizzo è possibile solo tramite console e la raccoltadati risulta di�coltosa in quanto il formato dei dati presentati in output nonè personalizzabile. Inoltre il tempo tra un dato e il successivo è superiore alladecina di millisecondi.

Capitolo 5

Virtual Box

5.1 Introduzione

In questo capitolo viene descritto il VMM VirtualBox insieme alla sua API.Verrà e�ettuata una breve presentazione del prodotto e verranno presentatele modalità di utilizzo. In particolare verranno descritti i metodi utilizzati percollezionare i dati.

5.2 VirtualBox

Come accennato precedentemente 4.3.1, Virtual Box è un VMM open sourcesviluppato da Sun Microsystems (oggi Oracle). Permette la creazione e l'e-secuzione di macchine virtuali. è multipiattaforma, funziona sia in ambienteWindows sia in ambiente Linux, su architettura x86 e x64. Può funziona-re anche in assenza di hardware dedicato alla virtualizzazione. In seguitovengono descritte le caratteristiche salienti di questo software. Per maggioriapprofondimenti consultare [Cora]

5.2.1 Virtualizzazione software-based

In assenza di virtualizzazione hardware-assisted, VirtualBox adotta la tecnicadella traduzione binaria per eseguire istruzioni privilegiate in modalità uten-te. Questa modalità supporta solo sistemi operativi guest a 32-bit. VirtualBox utilizza una tecnica detta Code Scanning and Analysis Manager (CSAM)per rilevare le istruzioni privilegiate prima della loro esecuzione e chiama ilPatch Manager (PATM) per operare una loro traduzione. La traduzione av-viene sostituendo il codice privilegiato con un salto a delle routine VM-safepresenti nel codice di Virtual Box. Il codice user-mode invece viene eseguito

24

CAPITOLO 5. VIRTUAL BOX 25

direttamente nell'hardware dell'host. Inoltre Virtual Box contiene un ricom-pilatore dinamico basato su QEMU per ricompilare il codice real mode (es.bios, bootloader)

5.2.2 Virtualizzazione hardware-assisted

VirtualBox supporta sia la virtualizzazione hardware VT-x di Intel sia AMD-Vdi AMD. Queste tecnologie permettono di eseguire ciascuna macchina virtualein uno spazio di indirizzamento separato e ogni istruzione privilegiata vieneeseguita del processore host. La compatibilità con alcuni sistemi operativiguest (es. 64bit) è subordinata alla presenza di tali tecnologie nel sistemahost.

5.2.3 Virtualizzazione delle periferiche

Le macchine virtuali create con Virtual Box supportano le seguenti periferiche:

• hard disk: sono supportate le immagini di dischi create anche con altriprodotti (es. VMware);

• dischi ottici: possono essere connessi a dispositivi �sici presenti nell'hostoppure essere agganciati a immagini ISO;

• sistem video: supporta una scheda video virtuale VESA compatibile.Programmi da installare nei sistemi guest permettono di migliorare leperformance video e di aggiungere funzionalità come ad esempio la rego-lazione automatica della risoluzione in base alle dimensioni della �nestradella VM;

• schede di rete: le schede di rete virtuali sono compatibili con la maggiorparte dei sistemi operativi senza necessità di driver speci�ci. I dispositivipossono essere con�gurati in vari modi, ad esempio in modo da e�ettua-re il NAT attraverso il VMM, condividere una speci�ca scheda di retedell'host oppure creare una rete solo tra host e guest;

• Scheda audio: sono disponibili le periferiche audio l'Intel HD Audio,l'Intel ICH AC'97 e la SoundBlaster 16;

• Controller USB: di default è emulato un controller USB 1.1 o, in alterna-tiva, installando opportune estensioni closed-source è possibile aggiun-gere un controller 2.0. Ogni periferica connessa con l'host può essereutilizzata da una VM.


5.3 API di Virtual Box

L'SDK, di cui è dotato Virtual Box, permette a terzi di sviluppare applicazioniinteragenti con Virtual Box. Come si può vedere in �gura 5.1 Virtual Box èstato progettato a livelli. L'area colorata in arancione rappresenta il codiceeseguito in modalità privilegiata, l'area colorata in blu rappresenta il codiceeseguito nello spazio utente.

Figura 5.1: VirtualBox ha un'architettura a livelli

Alla base troviamo il VMM vero e prorio (hypervisor). è il cuore del motoredi virtualizzazione, controlla l'esecuzione delle macchine virtuali e garantiscela sicurezza e l'assenza di con�itti tra le macchine virtuali e con l'host. Sopral'hypervisor troviamo dei moduli che forniscono funzionalità aggiuntive. Adesempio il server RDP (Remote Desktop Protocol). Il livello delle API è im-plementato sopra questi blocchi funzionali. Le funzionalità che questo livelloespone sono descritte in dettaglio nella SDK Reference [Corb]

5.3.1 Considerazioni sulla API

VirtualBox è dotato di un web service che, una volta in esecuzione, agisce daserver HTTP, accetta connessioni SOAP e le processa. L'interfaccia è descrittain un �le WSDL. In questo modo è possibile scrivere programmi client inqualsiasi linguaggio di programmazione che abbia a disposizione i tools perelaborare i �le WSDL, ad esempio Java, C++, .NET PHP, Python, Perl.Inoltre per Java e Python l'SDK contiene delle librerie già pronte all'uso.Internamente l'API è implementata utilizzando come modello di riferimento


COM. In Windows è utilizzato Microsoft COM. Negli altri host, dove COMnon è presente è possibile utilizzare XPCOM, un'implementazione gratuita diCOM. Segue un'analisi dei principali vantaggi e svantaggi delle due modalitàdi utilizzo dell'API.

Web service COM / XPCOM

VantaggiSupporta molti linguaggi diprogrammazioneI client possono essere sumacchie remote

Basso overhead

Molto semplice da utilizzarecon Java e Pyhton

SvantaggiOverhead signi�cativo do-vuto alla serializzazione edeserializzazione dell'XML

Usabile solo da linguaggiche supportano COM

I client devono stare sullostesso host della macchinavirtuale

Nonostante i vantaggi dell'utilizzo dell'API tramite web service si è utilizzatoil metodo COM perché permette un minor overhead e quindi una maggiorequantità di dati raccolti nell'unità di tempo. A riprova di quanto a�ermato èstato condotto un esperimento. I dati raccolti (valori del registro IP della cpu)sono stati a�ancati da un timestamp. Nella �gura 5.2 si nota come l'accessoall'API tramite COM è molto più veloce. L'esperimento ha dimostrato che ilmodo di utilizzo tramite web service è in grado, mediamente, di collezionareun dato ogni 5, 9621ms mentre utilizzando COM si riesce a collezionare undato ogni 0, 4901ms.

Altre funzioni interessanti riguardano la collezione di dati relativi a stati-stiche sull'utilizzo delle risorse. L'API prevede delle funzioni per:

• speci�care quali sono i gruppi di indicatori di interesse (CPU, RAM,Rete, Disco);

• impostare l'intervallo di misura (intervallo minimo di 1s);

• impostare la dimensione della frame per le statistiche (min, max, media);

• e�ettuare query di dettaglio sul singolo indicatore (CPU spazio utente,CPU spazio Kernel, dimensione del �le di paging...).

Per maggiori informazioni si veda [Cora].


Figura 5.2: Misurazioni puntuali dei tempi di risposta dell'API nei due modidi utilizzo

Capitolo 6

Analisi dei dati

6.1 Introduzione

Comprendere il funzionamento interno dei software commerciali a partire dalletracce di esecuzione richiede un grande sforzo. Il primo problema che si in-contra è l'enorme quantità di dati da elaborare. Normalmente queste tracce sicompongono di migliaia o milioni di eventi. In questo capitolo viene a�rontatal'analisi dei dati sui riferimenti alla memoria generati dall'IP della CPU e sugliindicatori di utilizzo delle risorse.

6.2 Aspetti legali

I dati che andremo ad acquisire riguardano lo stato interno di una macchinavirtuale. Questi dati sono raccolti idealmente dall'azienda proprietaria del-la server farm (o comunque dell'host sul quale esegue la macchina virtuale).Potrebbero sussistere problemi legali riguardo alla violazione della privacy de-gli utenti utilizzatori delle macchine virtuali. Dal Dl n. 196 06/2003 [Par]siriscontrano questi fatti:

• visto l' articolo 4, i dati raccolti dal sistema non rientrano nella de�ni-zione di dati personali in quanto risulta impossibile identi�care l'utentecome persona �sica o giuridica mediante l'uso dei dati raccolti;

• visto l'articolo 5 comma 3 l'utilizzo dei dati acquisiti non può ritenersiper uso personale. È quindi necessario informare l'utente in base alledisposizioni dell'articolo 7.

Da notare comunque che i dati raccolti non riguardano potenziali informazionisensibili:

29

CAPITOLO 6. ANALISI DEI DATI 30

• i memory reference sono gli indirizzi di memoria che legge la CPU, non ilsuo contenuto. Non viene letto in nessun caso il contenuto della memoriache, comunque, conterrebbe soltanto istruzioni e non dati;

• gli indicatori sull'utilizzo delle risorse sono informazioni già a disposizionedei sistemisti attraverso la console del VMM.

Idealmente quindi l'utente dovrà essere quindi informato (non è necessario ilsuo consenso) che il servizio acquistato (una o più macchine virtuali) prevedela raccolta dei dati sopra citati per scopi statistici e ad uso interno riservatoai sistemisti.

6.3 Memory References

Il VMM tramite le sue API è in grado di fornire informazioni riguardo allostato della macchina virtuale. Possiamo infatti leggere diversi registri dellaCPU. Tra questi è stato scelto il registro IP. I valori di tale registro, che leAPI forniscono, non sono puntuali ma sono campionati. Da studi compiutisull'API (si veda 5.3.1) possiamo ottenere un valore ogni 0, 5ms circa.

6.3.1 Caratterizzazione della sequenza dei memory

references

Con un tempo di campionamento così elevato rispetto al fenomeno di interesse,si corre il rischio che i dati non rappresentino delle features utilizzabili pergli scopi della tesi. Si rende pertanto necessaria un'approfondita analisi deidati. Saranno impiegate tecniche proprie dell'analisi dei segnali in quanto lasequenza dei memory reference raccolta sarà trattata come un segnale. Comesi vede in �gura 6.1 Tali valori possono essere caratterizzati come un segnalediscreto tempo variante. La tempo varianza è dovuta al fatto che i programmivengono caricati in porzioni diverse della memoria ad ogni esecuzione. Infattiin �gura 6.2 osserviamo la sequenza dei valori durante un'altra esecuzione dellostesso programma.

Dall'osservazione dei gra�ci si osserva che le proprietà fondamentali, ossialocalità spaziale e temporale dei riferimenti alla memoria, vengono mantenuteanche dopo il campionamento.

6.3.2 Divisione in frame

La divisione in frame è necessaria per il successivo addestramento dei modelliin quanto, a regime, il sistema che si vuole sviluppare deve permettere di


Figura 6.1: Sequenza di valori del registro IP assunti durante l'esecuzionedel programma PerlBench

Figura 6.2: Sequenza di valori del registro IP assunti durante un'altraesecuzione del programma PerlBench

riconoscere il comportamento dell'utente raccogliendo informazioni per breviperiodi di tempo. La sovrapposizione delle frame permette di coprire meglio la


casistica di un'acquisizione dati partendo da un qualsiasi istante dell'esecuzionedel programma. In �gura 6.3 è rappresentato il processo di divisione in frame.

Figura 6.3: Operazione di framing del segnale

La dimensione ottimale delle frame, quanto sovrapporle e quanti campioniscartare sono parametri da ricavare sperimentalmente. Da notare che, essendoi dati di interesse campionati, speci�care la lunghezza delle frame in unitàtemporali, o in numero di campioni è equivalente.

6.3.3 Divisione in blocchi

Ogni frame viene divisa in un certo numero di blocchi 6.4. Questa suddivisionein blocchi è giusti�cata dal fatto che le tecniche di machine learning usatenecessitano di un numero �nito e noto a priori di input. Tale tecnica, ad

Figura 6.4: Operazione di divisione in blocchi di una frame del segnale

esempio, è impiegata con successo nel caso del riconoscimento vocale [FAE08]. Il numero di blocchi in cui ogni frame viene divisa è un parametro da ricavaresperimentalmente.


6.3.4 Analisi spettrale tramite DCT

Durante l'esecuzione di un programma, le proprietà di località spaziale e tem-porale, fanno sì che esista una probabilità non nulla che la medesima istruzionevenga eseguita più volte. Nel dominio del tempo questo fenomeno si traducenel rilevare lo stesso valore del registro IP in istanti di tempo diversi. Ana-lizzando il fenomeno nel dominio della frequenza avremo dei picchi di energiain prossimità degli indirizzi ripetuti più frequentemente. Possiamo pertantoconsiderare come feature i coe�cienti con maggiore energia della trasformatadel segnale. Il numero di questi coe�cienti è un parametro da determinaresperimentalmente insieme con il fatto se sia opportuno o meno mantenere ilprimo coe�ciente, che in perfetta analogia con la teoria dei segnali, rappre-senta la componente continua. Viene scelta la trasformata discreta in coseno(DCT) [Wik] in quanto già utilizzata con successo in letteratura per lo stessoscopo [Pel11] Con questa tecnica, inoltre, viene premiata la località temporaledegli indirizzi. In �gura 6.1 e in �gura 6.5 si possono vedere il segnale originalee il segnale trasformato rispettivamente. Si noti come i primi coe�cienti sianoquelli con l'energia maggiore.

Figura 6.5: DCT del segnale


6.4 Indicatori sull'utilizzo delle risorse

Altre tracce di esecuzione dei programmi sono gli indicatori sull'utilizzo dellerisorse. Attraverso le API di Virtual Box, possiamo acquisire i dati relativi a:

• percentuale di utilizzo CPU da parte dell'utente 6.6;

• percentuale di utilizzo CPU da parte del Kernel6.7;

• memoria libera6.8;

• spazio su disco utilizzato;

• I/O di rete istantaneo.

Tali dati risultano signi�cativi al �ne di pro�lare l'utente in quanto permet-tono di discriminare il programma in esecuzione. Come si vede nelle �gure,esecuzioni di programmi diversi hanno andamenti temporali visibilmente di-versi, mentre lo stesso programma in diverse esecuzioni presenta un andamentosimile. La risoluzione di tali dati è molto minore rispetto a quella relativa

Figura 6.6: Percentuale utilizzo CPU User per 3 programmi in 2 esecuzioniciascuno.

ai memory reference in quanto le API aggiornano i loro valori ogni secondo.Anche in questo caso è stata e�ettuata un'attenta analisi dei dati.


Figura 6.7: Percentuale utilizzo CPU Kernel per 3 programmi in 2 esecuzioniciascuno.

Figura 6.8: Ram libera per 3 programmi in 2 esecuzioni ciascuno.


6.4.1 Caratterizzazione della sequenza di indicatori

sull'utilizzo delle risorse

L'andamento temporale dei singoli indicatori può essere interpretato come unsegnale discreto tempo invariante. La tempo-invarianza è data dal fatto che lepercentuali di utilizzo delle varie risorse non dipendono dall'istante iniziale del-l'esecuzione del singolo programma, ma dipendono solamente dall'evoluzionedel programma stesso. Questo a patto di considerare trascurabili gli e�etti delsistema operativo e di eventuali altri programmi che eseguono in backgroud.Considerare il singolo indicatore separatamente dagli altri potrebbe non es-sere signi�cativo ai �ni della pro�lazione utente in quanto presenterebbe unandamento temporale simile per programmi diversi. A tal proposito vederei programmi bzip2 e sjeng nella �gura 6.6. Considerando tutti i vari indica-tori nello stesso istante si ottiene un vettore N-dimensionale che rappresentail fenomeno in quell'istante. Questo procedimento di fusione dei dati, conte-stualizzato nel framework applicativo di interesse, richiede che i dati siano ilpiù possibile omogenei come valori. Tutti gli indicatori fusi insieme verrannopertanto normalizzati nell'intervallo [0,1]. Considerando tre indicatori pos-siamo rappresentare la fusione gra�camente. In �gura 6.9 si osserva come iprogrammi sono più facilmente isolabili nello spazio. Per quanto riguarda ilframing, la divisione in blocchi e l'analisi del dominio della frequenza, valgonoconsiderazioni analoghe a quelle fatte per i memory references. Si veda 6.3.26.3.3 6.3.4


Figura 6.9: Fusione degli indicatori.

Capitolo 7

Software realizzato

7.1 Introduzione

In questo capitolo verrà presentato il software sviluppato nell'ambito dellatesi. Verranno illustrati gli strumenti utilizzati e i vincoli di progetto. Inseguito verranno illustrati gli aspetti pratici e le scelte e�ettuate in fase diimplementazione.

7.2 Strumenti utilizzati

Vengono di seguito elencati i principali strumenti utilizzati durante questa fasedi progetto. L'hardware utilizzato viene omesso in quanto il software utilizzatoe realizzato è portabile su varie piattaforme.

• JDK 1.7;

• Eclipse IDE Juno;

• VirtualBox SDK versione 4.3.2;

• VirtualBox versione 4.3.2;

• sistema guest Linux debian 3.2.0-4-486;

• Benchmark Spec CPU 2006;

• Code::Blocks IDE versione 12.11;

• libreria OpenCv versione 2.4.6.1 [itS];

• sorgenti della libreria Fann versione 2.2 [Nis];

38

CAPITOLO 7. SOFTWARE REALIZZATO 39

• sorgenti libreria Dempster Shafer sviluppati da Thilo Michael e Je�reyJedele [eJJ];

• sorgenti software hmmface [Pie11].

Il sistema è stato sviluppato su un host Linux Debian.

7.3 Sistema di acquisizione dati

Questo componente software è stato sviluppato interamente nell'ambito diquesta tesi. Come spiegato in dettaglio in 5.3.1 sono state impiegate le APICOM di VirtualBox La scelta di Java come linguaggio host per le chiamateall'API è stata e�ettuata per i seguenti motivi:

• maggiore documentazione ed esempi di utilizzo dell'SDK rispetto ad altrilinguaggi;

• linguaggio orientato agli oggetti;

• gestione degli errori;

• portabile.

Obiettivo principale è realizzare un software che permetta di acquisire i datisulla sequenza di memory reference e delle statistiche sull'utilizzo delle risor-se nella macchina virtuale e di persisterli su �le. Il software realizzato devesoddisfare i seguenti requisiti:

• introdurre basso overhead tra le varie chiamate dell'API;

• essere facilmente modi�cabile;

• essere robusto, in quanto deve essere eseguito per lunghi periodi di temposenza supervisione;

• essere �essibile nel senso che deve essere possibile acquisire diversi daticontemporaneamente;

• avere la possibilità di controllo automatico per l'avvio e l'arresto dell'ac-quisizione dati.

Nel seguito viene descritto il software di acquisizione implementato. Vengonoanche descritte brevemente le soluzioni tecniche per soddisfare i requisiti.


7.3.1 Architettura

La �gura 7.1 mostra l'architettura del software realizzato. Una volta acquisitele informazioni tramite chiamate all'API è necessario persisterle su �le. Lascrittura dei dati su �le ad ogni chiamata introdurrebbe un overhead quan-ti�cabile in 0.2 − 0.5ms. All'opposto tenere tutti i dati raccolti in memoriapotrebbe provocare errori di Out of Memory in quanto non è possibile stabili-re a priori la mole di dati che si andranno ad acquisire. Una buona soluzionedi compromesso tra le due consiste nel leggere i dati a blocchi di dimensione�ssa (es. 1024) e persisterli tutti in una volta. Il progetto del software segueil paradigma della programmazione ad oggetti. Ogni oggetto pertanto godedelle proprietà di incapsulamento e disaccopiamento. Si è quindi proceduto altest delle varie parti e solo in seguito ad unire tutte le componenti in un unicoprogramma. Il software per l'acquisizione deve essere in grado di gestire pos-sibili anomalie di funzionamento. In particolare l'acqusizione dati in modalitàbatch, in caso di errori, deve proseguire �no alla �ne del lotto programmato.

Figura 7.1: Architettura del software di acqusizione dati dalla VM.


7.3.2 Funzionamento

Il software sviluppato funziona in due modalità:

• online: l'acquisizione viene pilotata interamente dal sistema host;

• batch: l'acquisizione viene pilotata da un client installato sulla macchi-na guest. Permette di eseguire le acquisizioni dati in corrispondenza adeterminati eventi.

Il programma necessita dei seguenti parametri:

• nome macchina virtuale: serve per agganciarsi alla macchina virtualedesiderata;

• tipoAcquisizione: mr per i memory references, perf per gli indicatorisull'utilizzo delle risorse;

• nomeFileOutput: solo per acquisizione online, indica il nome del �le incui scrivere i dati. Per la modalità batch va indicato il percorso basedove salvare i �le generati. Il nome del �le viene scelto dal client sullamacchina virtuale.

L'output del programma è un �le di testo in cui in ogni riga è presente uno opiù indicatori in funzione del tipo di acquisizione scelto:

• tipoAcquisizione mr: avremo un memory reference per ogni riga. Si vedacome esempio 7.1

• tipoAcquisizione perf: avremo una serie di indicatori sull'utilizzo dellerisorse. Si veda come esempio 7.2

Listing 7.1: Esempio di output nel caso di acquisizione di memory referencesTimestamp,Indirizzo,

701892704123559, 0x0804a1be,

701892810391985, 0x0804e880,

701892913970180, 0x0804aa4f,

701893017903703, 0x0804ad8c,

701893121866733, 0x0804eed4,

701893224354769, 0x0804b11b,

701893329880761, 0x0804a878,

701893433875587, 0x0804af18,

701893535744118, 0x0804a3c8,

701893637910209, 0x0804f990,


701893741889815, 0x0804a884,

701893845900845, 0x0804a11d,

701893949900057, 0xc1005272,

701894051790540, 0x0804a989,

701894153906958, 0x0804a154,

701894257888280, 0x0804a8e5,

701894361898999, 0x0804ab68,

701894465900826, 0x0804a10b,

701894569877787, 0x0804a88c,

701894673902637, 0x0804a888,

Listing 7.2: Esempio di output nel caso di acquisizione di indicatori sull'utilizzodelle risorseTimestamp, Disco, NetIn, NetOut, CPUU, CPUK, RAM

701892704123559, 8740.0, 0.0, 0.0, 52.0, 45.0, 1135984.0,

701892810391985, 8740.0, 0.0, 0.0, 52.0, 45.0, 1135984.0,

701892913970180, 8740.0, 0.0, 0.0, 52.0, 45.0, 1135984.0,

701893017903703, 8740.0, 0.0, 0.0, 52.0, 45.0, 1135984.0,

701893121866733, 8740.0, 0.0, 0.0, 52.0, 45.0, 1135984.0,

701893224354769, 8740.0, 0.0, 0.0, 52.0, 45.0, 1135984.0,

701893329880761, 8740.0, 0.0, 0.0, 52.0, 45.0, 1135984.0,

701893433875587, 8740.0, 0.0, 0.0, 52.0, 45.0, 1135984.0,

701893535744118, 8740.0, 0.0, 0.0, 90.0, 10.0, 1016784.0,

701893637910209, 8740.0, 0.0, 0.0, 90.0, 10.0, 1016784.0,

701893741889815, 8740.0, 0.0, 0.0, 90.0, 10.0, 1016784.0,

701893845900845, 8740.0, 0.0, 0.0, 90.0, 10.0, 1016784.0,

701893949900057, 8740.0, 0.0, 0.0, 90.0, 10.0, 1016784.0,

701894051790540, 8740.0, 0.0, 0.0, 90.0, 10.0, 1016784.0,

701894153906958, 8740.0, 0.0, 0.0, 90.0, 10.0, 1016784.0,

701894257888280, 8740.0, 0.0, 0.0, 90.0, 10.0, 1016784.0,

701894361898999, 8740.0, 0.0, 0.0, 90.0, 10.0, 1016784.0,

701894465900826, 8740.0, 0.0, 0.0, 90.0, 10.0, 1016784.0,

701894569877787, 8740.0, 0.0, 0.0, 97.0, 2.0, 1016784.0,

701894673902637, 8740.0, 0.0, 0.0, 97.0, 2.0, 1016784.0,

7.3.3 Problemi riscontrati durante lo sviluppo

In questo paragrafo vengono presentati i problemi riscontrati durante lo svilup-po del software. Il problema principale è stato la mancanza di esempi completiall'interno dell'SDK per quanto riguarda l'acquisizione dati.


• L'acqusizione del valore dei registri della CPU non viene contemplatoin nessuno degli esempi forniti con l'SDK. È stato pertanto necessariobasarsi sulla scarna documentazione fornita, procedendo per tentativi,�no ad ottenere un sistema funzionante.

• Per quanto riguarda l'acqusizione degli indicatori sull'utilizzo delle risorseè stato riscontrato un bug nell'implementazione della chiamata al meto-do queryMetricsData della classe IPerformanceCollector dell'SDK diVirtual Box, segnalato, tra l'altro, qui: [Smi] . Nel listato 7.3 è possibilevedere la correzione eseguita derivando la classa e ride�nendo il metodo.

• In una prima implementazione del software era presente un'unico pro-gramma per la gestione dell'acqusizione dati batch. Da prove sul campoè emerso che le API introducono una certa instabilità in caso di ese-cuzioni protratte nel tempo. Per prevenire questi errori, che non sonoeccezioni gestibili all'interno della JVM, è stato necessario aggiungereuno strato software (denominato factory in �gura 7.1) per limitare glie�etti di questi errori non gestibili solo all'acquisizione corrente e quindidi poter proseguire con le restanti acquisizioni dati..

Listing 7.3: Correzione eseguita al codice dell'SDK

public List<Integer> queryMetricsData(List<String> paramList,

List<IUnknown> paramList1, Holder<List<String>> paramHolder1,

Holder<List<IUnknown>> paramHolder, Holder<List<String>>

paramHolder2, Holder<List<Long>> paramHolder3, Holder<List<Long>>

paramHolder4, Holder<List<Long>> paramHolder5, Holder<List<Long>>

paramHolder6)

{

try {

String[][] arrayOfString1 =

(String[][])Array.newInstance([Ljava.lang.String.class, 1);

nsISupports[][] arrayOfnsISupports =

(nsISupports[][])Array.newInstance([Lorg.mozilla.interfaces.nsISupports.class,

1);

String[][] arrayOfString2 =

(String[][])Array.newInstance([Ljava.lang.String.class, 1);

long[][] arrayOfLong1 = (long[][])Array.newInstance([J.class,

1);


1);



1);


1);

int[] arrayOfInt =

getTypedWrapped().queryMetricsData(paramList.size(),

Helper.unwrapStr(paramList), paramList1.size(),

(nsISupports[])Helper.unwrap2(IUnknown.class,

nsISupports.class, paramList1), null, arrayOfString1, null,

arrayOfnsISupports, null, arrayOfString2, null,

arrayOfLong1, null, arrayOfLong2, null, arrayOfLong3, null,

arrayOfLong4, null);

paramHolder1.value = Helper.wrap(arrayOfString1[0]);

//Produceva errore

//paramHolder.value = Helper.wrap2(IUnknown.class,

nsISupports.class, arrayOfnsISupports[0]);

//correzione:

paramHolder.value = new ArrayList<IUnknown>();

for(int i=0;i<arrayOfnsISupports[0].length;i++){

IUnknown elm = new IUnknown(arrayOfnsISupports[0][i]);

paramHolder.value.add(elm);

}

//fine correzione

paramHolder2.value = Helper.wrap(arrayOfString2[0]);

paramHolder3.value = Helper.wrap(arrayOfLong1[0]);




return Helper.wrap(arrayOfInt);

}

catch (XPCOMException localXPCOMException)

{

throw new VBoxException(localXPCOMException.getMessage(),

localXPCOMException);

}

}


7.4 Creazione delle frame

Questo software è stato sviluppato interamente nell'ambito della tesi. Il soft-ware è scritto in linguaggio c++. La scelta del linguaggio c++ è stato e�et-tuata perché:

• ben supportato come linguaggio dalla libreria openCV;

• introduce meno overhead nell'elaborazione rispetto a Java;

• nessun limite alla memoria allocabile (in Java occorre settare opportu-namente la JVM).

Partendo dai �le di testo prodotti dal software di acquisizione si vuole:

• portare i dati in un formato facilmente leggibile e facilmente utilizzabile;

• dividere le tracce in frame;

• normalizzare i valori.

La prima esigenza è stata risolta impiegando il formato YAML [Eva] per per-sistere oggetti di tipo Mat della libreria OpenCV [odt]. La scelta è statae�ettuata per il fatto che YAML permette di serializzare gli oggetti in modoche non sia più necessaria la conversione da testo a valore numerico. Inoltre lalibreria openCV supporta in modo nativo tale formato e nella documentazionesono presenti numerosi esempi. La divisione in frame presuppone che venganoforniti due parametri di ingresso:

• lunghezza della frame (espressa come numero di campioni);

• intervallo tra l'inizio di una frame e la successiva (sempre in numero dicampioni);

• numero di campioni iniziali da scartare.

Con questi due parametri il problema della divisione in frame viene demandatocompletamente al chiamante. Per la normalizzazione dei valori è stato scelto:

• per i memory references, dato che si presentano come numeri interi divalore molto elevato, di sostituirli con il loro logaritmo naturale. Que-sta scelta permette di evitare problemi di arrotondamento nei successivicalcoli;

• per gli indicatori sull'utilizzo delle risorse essi vengono normalizzati da0 a 1. Questa scelta permette di uniformare le componenti del vettoreformato dai valori di questi indicatori.


Nei listati 7.4 e 7.5 si vedono degli esempi di output di questo programma.

Listing 7.4: Frame prodotto nel caso di memory reference%YAML:1.0

frame: !!opencv-matrix

rows: 15040

cols: 1

dt: f

data: [ 2.18982315e+01, 2.18982315e+01, 2.18982315e+01,

2.18982315e+01, 2.18982315e+01, 2.18982315e+01, 2.18982315e+01,

2.18982315e+01, 2.18982315e+01, 2.18982315e+01, 2.18982315e+01,

2.18982315e+01, 2.18982315e+01, 2.18982315e+01, 2.18982315e+01,

2.18986187e+01, 2.21492462e+01, 2.18982315e+01, 2.18982315e+01,

2.18982315e+01, 2.18982315e+01, 2.18982315e+01, 2.18982315e+01,

Listing 7.5: Frame prodotto nel caso di indicatori sull'utilizzo dell risorse%YAML:1.0


rows: 512

cols: 4

dt: f

data: [ 5.82666695e-01, 9.59999979e-01, 3.99999991e-02,

9.21773434e-01, 5.82666695e-01, 9.59999979e-01, 3.99999991e-02,

9.21773434e-01, 5.82666695e-01, 9.59999979e-01, 3.99999991e-02,

9.21773434e-01, 5.82666695e-01, 9.59999979e-01, 3.99999991e-02,

9.21773434e-01, 5.82666695e-01, 9.59999979e-01, 3.99999991e-02,

9.21773434e-01, 5.82666695e-01, 9.59999979e-01, 3.99999991e-02,

9.21773434e-01, 5.82666695e-01, 9.59999979e-01, 3.99999991e-02,

9.21773434e-01, 5.82666695e-01, 9.59999979e-01, 3.99999991e-02,

9.21773434e-01, 5.82666695e-01, 9.59999979e-01, 3.99999991e-02,

9.21773434e-01, 5.82666695e-01, 9.59999979e-01, 3.99999991e-02,

7.4.1 Funzionamento

Per semplicità di utilizzo il programma è stato diviso in due programmi distinti,l'uno per gestire i memory reference e l'altro per gli indicatori sull'utilizzo dellerisorse. Entrambi vengono invocati con questi parametri:

• numero campioni totali;

• numero campioni iniziali da scartare;


• lunghezza (in numero di campioni) della frame;

• step, cioè distanza tra l'inizio di una frame e la successiva, (in numerodi campioni);

• percorso + pre�sso per i �le di output.

Durante l'esecuzione vengono create le varie frame. I �le relativi si troverannolungo il path percorso/pre�ssoXXX.yml, dove XXX rappresenta il numero diframe generate a partire da una traccia in input. Per agevolare la creazionedelle frame è stato sviluppato uno script Bash. Tale script:

• seleziona le tracce per comporre gli insiemi di train e di test in modoopportuno;

• eventualmente elimina i database creati in precedenza;

• crea la struttura di directory per i database;

• avvia il programma opportuno (memory reference o indicatori sull'uti-lizzo delle risorse).

Alla �ne del processo otteniamo due strutture di directory simili a quelle in�gura 7.2, una con l'insieme di train, l'altra con l'insieme di test.

Figura 7.2: Esempio di struttura del database delle frame.



Nello sviluppo di questo software non si sono riscontrati particolari problemi.L'unico punto critico è stato trovare la corrispondenza tra tipi di dato in c++e in openCV per poter valorizzare correttamente l'oggetto Mat con i campioni.

7.5 Divisione in blocchi e clustering

Questo software è stato sviluppato nel corso della tesi utilizzando come base ilsoftware hmmface sviluppato nel corso di un'altra tesi. è stato completamentesvuotato delle logiche originali di addestramento, di gestione dei modelli e ditest. è stata modi�cata la parte di gestione del database delle frame in mododa essere compatibile con il formato scelto (YAML). è stata aggiunta la logicaper la divisione in blocchi, il calcolo dei centroidi, la clusterizzazione. Partendoda una frame (es. 7.4 o 7.5) il programma:

• suddivide in blocchi la frame;

• calcola la DCT di ciascun blocco;

• clusterizza i blocchi e ne salva le label (l'indice del vettore nell'insiemedei centroidi).

La clusterizzazione dei blocchi avviene attraverso l'algoritmo kmeans, di cuiviene utilizzata l'implementazione presente nella libreria openCV.

7.5.1 Funzionamento

Si presuppone che esistano due set distinti del tipo in �gura 7.2, uno per iltraining, l'altro per il test. Esistono due programmi distinti:

• modalità di addestramento (train): con questo programma vengono crea-ti i centroidi e calcolate le labels di tutti i blocchi generati dalle framepresenti nel database di train;

• modalità di test: con questo programma vengono calcolate le labels diciascun blocco relativo alle frame del set di test utilizzando i centroidicalcolati dal programma di train.

Il programma di train viene invocato con i seguenti parametri:

• path del database;

• numero di classi in cui clusterizzare i blocchi;


• numero di coe�cienti della DCT da utilizzare per rappresentare il blocco;

• �ag per escludere o mantenere il primo coe�ciente della DCT (la conti-nua);

• numero di blocchi per ciascuna frame.

I parametri devono soddisfare i seguenti vincoli:

• coe�cientiDCT < lunghezzaFrame / numeroBlocchi;

• lunghezzaFrame / numeroBlocchi deve essere pari (vincolo imposto dallatrasformata DCT).

L'output di questo programma sono dei �le in formato YAML (uno per ogniframe) in cui sono contenute le label associate a ciascun blocco della frame e unaltro �le in formato YAML in cui sono contenuti i centroidi 7.6 Il programmadi test viene invocato con i seguenti parametri:

• frame da clusterizzare;

• database di train da cui caricare i centroidi;

• gli altri parametri sono gli stessi del programma train.

Per ogni frame data in input viene creato un �le in formato YAML in cui sonocontenute le label associate a ciascun blocco della frame 7.7

Listing 7.6: Esempio di centroidi%YAML:1.0

centroids: !!opencv-matrix

rows: 6

cols: 16

dt: f

data: [ -3.06569855e-04, -1.08161084e-01, -2.09528431e-02,

-5.95307760e-02, -2.05521379e-02, -8.53601918e-02,

-9.92437708e-04, -5.45172021e-02, 8.12677108e-03,

-4.59062643e-02,

7.90587452e-04, -3.55328433e-02, -9.75481141e-03,

-2.52794530e-02,

6.57281652e-03, -1.59176998e-02, 2.22821274e+01,

-1.48326406e+01,

5.79074383e+00, 4.98687476e-02, -2.06306362e+00, 1.31559050e+00,

-4.15854096e-01, -7.15919957e-02, -2.04606757e-01,

7.09409654e-01,


-7.57185757e-01, 3.13336998e-01, -7.22765252e-02,

1.39015466e-01,

-2.08173409e-01, 1.76923886e-01, 2.99389458e+01, 5.69996595e+00,

-9.68416309e+00, 1.26773369e+00, -5.63507862e-02,

1.43814385e-01,

-6.83244884e-01, 1.34673274e+00, -1.66306064e-01,

-5.58102012e-01,

2.12694108e-01, -5.43488264e-02, -1.42198861e-01,

-3.48987505e-02,

1.43358961e-01, 1.33434787e-01, -2.28228397e+01,

-1.41331720e+01,

-5.11468792e+00, 1.06525861e-01, 1.23515630e+00, 5.28854549e-01,

3.11504863e-02, 3.12583178e-01, 7.44129896e-01, 8.15373898e-01,

6.31796658e-01, 4.53701407e-01, 3.36565971e-01, 2.18720809e-01,

1.08863287e-01, 7.41523802e-02, -2.59945030e+01, 1.02532911e+01,

7.03120279e+00, 1.28860879e+00, 3.20311785e-01, 2.82335639e-01,

1.21425414e+00, 4.42285724e-02, -1.99875876e-01,

-2.27946430e-01,

2.32838050e-01, 2.54056633e-01, 1.60251167e-02, 4.10910621e-02,

8.58983025e-03, -5.37593924e-02, 7.34245396e+00, 2.20151386e+01,

7.92218506e-01, -1.02159679e+00, 4.77390513e-02, 2.03271937e-02,

-4.43136990e-01, -1.00596659e-02, 2.20206037e-01,

5.13941526e-01,

-3.60902429e-01, -2.19827801e-01, 2.17572227e-02,

-4.06459242e-01,

-1.55029118e-01, -3.82144004e-02 ]

Listing 7.7: Esempio di labels%YAML:1.0


rows: 16

cols: 1

dt: i

data: [ 1, 1, 3, 1, 5, 1, 0, 0, 0, 1, 1, 2, 2, 2, 1, 3 ]


Durante lo sviluppo le di�coltà maggiori si hanno avute nella corretta suddi-visione in blocchi, in quanto è stato necessario tener conto delle diversità neidati tra frame di memory references e indicatori sull'utilizzo delle risorse. Le


prime consistono in un dato primitivo per riga. Le altre sono composte darighe con vettori di dati e vanno quindi gestite in modo opportuno.

7.6 Addestramento e test di rete neurale

Questo software, come il precedente, deriva da hmmface. È stata modi�catala parte di gestione del database delle frame in modo da essere compatibilecon il formato prescelto (YAML). Sono state modi�cate le parti relative allagestione (creazione, inizializzazione, caricamento) dei modelli e riscritte le partirelative all'addestramento e al test dei modelli. L'implementazione scelta perle reti neurali è quella e�ettuata nella libreria Fann (Fast Arti�cial NeuralNetwork). La topologia di rete è il multilayer perceptron a tre layer (input,hidden, output). L'input layer presenta tanti ingressi quanti sono i blocchi incui è stata divisa la frame. Gli ingressi sono i numeri delle label. L'outputlayer presenta una sola uscita che indica la probabilità che la frame data ininput appartenga ad un programma.

7.6.1 Funzionamento

Si presuppone che esistano due set distinti del tipo in �gura 7.2, uno per iltraining, l'altro per il test, di cui è stata eseguita in precedenza la divisione inblocchi e il clustering. Esistono due programmi distinti:

• modalità di addestramento (train): con questo programma vengono crea-ti i modelli (uno per ogni programma) utilizzando come input le labeldei blocchi di tutte le frame presenti nel database di train;

• modalità di test: con questo programma vengono testate tutte le framepresenti nel database di test. Viene scritto un �le con i risultati del test.

Il programma di train viene invocato con i seguenti parametri:

• path del database;

• numero di input della rete neurale;

• numero di neuroni dello strato nascosto;

• numero massimo di epoche di addestramento.

L'algoritmo di addestramento segue i seguenti passi:

• censimento di tutte le frame, divise per programma in base alla strutturadel database;


• generazione dei modelli coerentemente con i programmi presenti neldatabase e ai parametri in input;

• addestramento dei modelli, per ogni modello:

� preparazione set di train con metà esempi di appartenenza al mo-dello e metà esempi di non appartenenza. Questi ultimi scelti a casotra i rimanenti programmi;

� avvio procedura di addestramento;

� se raggiunto tasso di errore zero: stop;

� altrimenti proseguo �nché raggiunto numero massimo di epoche;

• salvataggio dei modelli addestrati.

L'output del programma di train sono i modelli relativi ai vari programmipresenti nel database. Nel listato 7.8 è possibile vedere un esempio di mo-dello generato, contenente la rete neurale addestrata per riconoscere frameappartenenti al programma.

Listing 7.8: Rete neurale creata come modello di un programmaFANN_FLO_2.1

num_layers=3

learning_rate=0.700000

connection_rate=1.000000

network_type=0

learning_momentum=0.000000

training_algorithm=2

train_error_function=1

train_stop_function=0

cascade_output_change_fraction=0.010000

quickprop_decay=-0.000100

quickprop_mu=1.750000

rprop_increase_factor=1.200000

rprop_decrease_factor=0.500000

rprop_delta_min=0.000000

rprop_delta_max=50.000000

rprop_delta_zero=0.100000

cascade_output_stagnation_epochs=12

cascade_candidate_change_fraction=0.010000

cascade_candidate_stagnation_epochs=12

cascade_max_out_epochs=150

cascade_min_out_epochs=50

cascade_max_cand_epochs=150


cascade_min_cand_epochs=50

cascade_num_candidate_groups=2

bit_fail_limit=1.00000001490116119385e-01

cascade_candidate_limit=1.00000000000000000000e+03

cascade_weight_multiplier=4.00000005960464477539e-01

cascade_activation_functions_count=10

cascade_activation_functions=3 5 7 8 10 11 14 15 16 17

cascade_activation_steepnesses_count=4

cascade_activation_steepnesses=2.50000000000000000000e-01

5.00000000000000000000e-01 7.50000000000000000000e-01

1.00000000000000000000e+00

layer_sizes=21 64 2

scale_included=0

neurons (num_inputs, activation_function, activation_steepness)=(0,

0, 0.00000000000000000000e+00) (0, 0, 0.00000000000000000000e+00)

(0, 0, 0.00000000000000000000e+00)

connections (connected_to_neuron, weight)=(0,

4.04511094093322753906e-01) (1, 6.03508576750755310059e-03) (2,

-5.56600034236907958984e-01) (3, -4.46860194206237792969e-01)

Il programma di test viene invocato con i seguenti parametri:

• frame clusterizzata da testare;

• database di train che contiene i modelli.

Il programma carica tutti i modelli creati in fase di train e testa la frame passa-ta in input con ogni modello. La frame viene riconosciuta come appartenenteal programma il cui modello risponde con un valore più alto in uscita. Peragevolare la fase di test è stato creato uno script per richiamare il programmadi test con tutte le frame clusterizzate nel database di test. In uscita abbiamoun �le che contiene l'esito del riconoscimento, ovvero le probabilità che ha laframe di appartenere a ciascun modello. Viene inoltre indicato il programmaa cui la frame appartiene. Nel listato 7.9 viene fornito un esempio di �le dioutput.

Listing 7.9: Output del programma per il testpVero;pTrovato;sjeng;perlbench;omnetpp;libquantum;gcc;bzip2;

bzip2;bzip2;0.130548;0.22756;0.235933;0.163479;0;0.242481;

bzip2;bzip2;0.210586;0.231984;0.111663;0.200375;0;0.245393;

bzip2;bzip2;0.2579;0.248842;0;0.11131;0.107966;0.273981;

bzip2;bzip2;0.189267;0.214833;0;0.0901389;0.198654;0.307107;

bzip2;bzip2;0.181434;0.184786;0.18922;0;0.0662469;0.378313;


bzip2;bzip2;0.2516;0.249429;0.211497;0;0.0259506;0.261523;

bzip2;bzip2;0.241213;0.307921;0.069095;0;0.070553;0.311219;

bzip2;bzip2;0;0.325681;0.18369;0.147379;0.0112246;0.332026;

bzip2;bzip2;0.161043;0.25991;0;0.218057;0.0786933;0.282297;

bzip2;bzip2;0.14622;0.259191;0.118856;0.210021;0;0.265712;

bzip2;sjeng;0.227629;0.224094;0.187735;0.226305;0;0.134237;

bzip2;sjeng;0.231306;0.228582;0.151684;0.163513;0;0.224915;

bzip2;bzip2;0.268863;0.214774;0;0.0581869;0.178839;0.279338;

bzip2;bzip2;0.0639456;0.244768;0;0.215536;0.200423;0.275327;

bzip2;bzip2;0.251042;0;0.163536;0.24025;0.0796963;0.265476;

bzip2;bzip2;0.238174;0.220301;0;0.226525;0.0712822;0.243718;

bzip2;bzip2;0.213192;0.209801;0.153829;0.203002;0;0.220177;

bzip2;bzip2;0.272146;0.155566;0.237197;0.059243;0;0.275849;

bzip2;bzip2;0.150479;0.336761;0.0484909;0;0.0922978;0.371971.

Ogni riga rappresenta l'esito del test di una frame. La prima colonna rap-presenta il programma vero da cui è stata estratta la frame. La seconda co-lonna rappresenta il programma riconosciuto. Le restanti colonne indicano,per ciascun modello nel database la probabilità della frame di appartenere almodello.

7.7 Addestramento e test di HMM

È stato utilizzato il software sviluppato in un'altra tesi di laurea. Per maggioridettagli si veda [Pie11]. È stata modi�cata la logica di caricamento delle frame,in quanto il programma originale lavora con immagini bitmap. Al loro postovengono impiegati �le in formato YAML.

7.8 Software per la fusione con

Dempster-Shafer

Utilizzando come base gli esempi di utilizzo di una libreria c++ che implemen-ta il metodo di Dempster-Shafer [eJJ] è stato sviluppato un programma che,partendo dai risultati di più sistemi di riconoscimento (nel nostro caso memoryreferences e indicatori sull'utilizzo delle risorse), esegue la fusione delle infor-mazioni al �ne di migliorare il tasso di corretto riconoscimento delle frame. èstato scritto un componente software che permette di leggere �le in formatocsv come quello descritto qui 7.9. Inoltre è stata modi�cata la logica internaper e�ettuare la fusione ne modo descritto in seguito. È possibile vedere lastruttura del programma in �gura 7.3


Figura 7.3: Architettura del software di fusione con Dempster-Shafer apartire dai riconoscitori di memory reference e dati sull' utilizzo delle risorse.

7.8.1 Funzionamento

Si presuppone che esistano due sistemi per il riconoscimento. I dati di inputdevono essere del formato descritto in 7.9. I due sistemi di riconoscimentodevono lavorare con lo stesso numero di frame. Il programma viene invocatocon i seguenti parametri:

• �le dei risultati del primo sistema;

• �le dei risultati del secondo sistema.

In fase di inizializzazione il programma:

• esamina l'header del �le csv per ricavare i programmi oggetto di ricono-scimento;

• imposta come ipotesi dell'universo i programmi.

In seguito il programma esegue i seguenti passi per ogni frame dei due �le diinput:

• per ogni sistema di riconoscimento:

� per ogni programma:

∗ leggo la probabilità di appartenenza al programma della framedal �le csv;∗ crea un'attestazione con massa pari alla probabilità letta per ilprogramma in esame;


∗ assegno la probabilità residua ai rimanenti sottoinsiemi;

• combino le attesatazioni create e calcolo l'ipotesi più probabile.

In uscita il programma fornisce il nuovo esito del riconoscimento dopo lafusione. Nel listato 7.10 viene mostrato l'output intermedio del programma.

Listing 7.10: Output intermedio della fusione Dempster-Shafer---------------------------------

### Frame: 000 ###

---------------------------------

sjeng| ##########-----------.............................

perlbench| ##-----------.....................................

omnetpp| ######-----------.................................

libquantum| -----------.......................................

gcc| #-----------......................................

bzip2| #################-----------......................

---------------------------------

classified as: bzip2

---------------------------------

---------------------------------

### Frame: 001 ###

---------------------------------

sjeng| #####------------.................................

perlbench| ######------------................................

omnetpp| #########------------.............................

libquantum| ##-------------...................................

gcc| #------------.....................................

bzip2| ############-------------.........................

---------------------------------

classified as: bzip2

---------------------------------

---------------------------------

### Frame: 002 ###

---------------------------------

sjeng| #####################----------...................

perlbench| ##----------......................................

omnetpp| ###----------.....................................

libquantum| ####-----------...................................

gcc| -----------.......................................

bzip2| #######----------.................................

---------------------------------


classified as: sjeng

---------------------------------

I caratteri # rappresentano la credibilità delle ipotesi mentre i caratteri -rappresentano la loro plausibilità.


Durante lo sviluppo di questo software non sono emersi particolari problemi.Parte consistente del tempo di sviluppo è stata spesa nella ricerca di librerieche implementassero il metodo di Dempster-Shafer adatte allo scopo. Altraparte consistente di tempo è stata spesa per la messa a punto dell'algoritmoutilizzato descritto nel capitolo precedente.

7.9 Riepilogo

In �gura 7.4 è possibile vedere il �usso complessivo dei dati nei programmisviluppati.


Figura 7.4: Flusso dei dati nei programmi sviluppati.

Capitolo 8

Esperimenti

8.1 Introduzione

In questo capitolo vengono presentati gli esperimenti e�ettuati e i risultatiottenuti. L'obiettivo principale è di riconoscere un programma in esecuzionesu una macchina virtuale, attraverso l'utilizzo dei memory references del regi-stro IP e/o degli indicatori sull'utilizzo delle risorse ottenuti tramite l'API delVMM.

8.2 Preparazione ambiente

È stata creata una macchina virtuale per Virtual Box che esegue il sistemaoperativo Linux Debian. Su di essa è stata installata la suite di benchmarkSpec CPU 2006. La scelta di utilizzare i programmi benchmark di Spec per lapro�lazione utente ha le seguenti ragioni:

• si crea un ambiente di test facilmente replicabile;

• in letteratura i programmi Spec sono già stati impiegati per scopi simili[Cec10];

• i programmi della suite sono simili ai rispettivi programmi reali.

8.3 Dataset acquisiti

Sono state eseguite numerose acquisizioni dati. Tutte le acquisizioni sono statee�ettuate adottando i seguenti criteri:

59

CAPITOLO 8. ESPERIMENTI 60

• tempo di esecuzione di ogni benchmark con un determinato input: circa10min;

• ripetizioni dell'esecuzione di ogni benchmark: 10;

• i benchmark vengono eseguiti uno dopo l'altro. Le ripetizioni avvengonodopo aver acquisito i dati di un intero set di benchmark.

Sono stati utilizzati tutti e 12 i programmi Spec più i programmi bzip e gcc.In totale sono stati acquisiti oltre 14 GByte di tracce divise in:

• 360 tracce con i memory references: 10 per ogni benchmark, con 3 inputdiversi ;

• 360 tracce con gli indicatori di utilizzo delle risorse: 10 per ogni bench-mark, con 3 input diversi;

• 40 tracce con i memory references di bzip e gcc con 2 diversi input;

• 40 tracce con gli indicatori di utilizzo delle risorse di bzip e gcc con 2diversi input.

Il tempo speso per l'acquisizione dati è circa di 8000 minuti, pari a 5 giorni emezzo.

8.3.1 Sistema utilizzato per i test

Il sistema impiegato per i successivi test è quello descritto in precedenza 7.9.Tutte le componenti software sono dapprima state testate con dei dati di pro-va. In questa fase del lavoro sono state inoltre apportate lievi modi�che aiprogrammi realizzati, solitamente con il �ne di renderli più adatti alle esigenzedell'utente nello svolgimento degli esperimenti.

8.4 Esperimenti preliminari

In una prima fase sono stati raccolti dei dati allo scopo di testare il sistema diacquisizione. In seguito sono stati acquisiti i dati relativi ad alcuni benchmarkSpec, per poi estendere la raccolta a tutto il set di benchmark.


8.4.1 Test tempi di acquisizione

In questo esperimento sono stati raccolti i dati (memory references e indicatorisull'utilizzo delle risorse) dei benchmark Spec bzip2 e gcc. Con questa primaraccolta dati sono stati messi appunto i programmi per l'acqusizione. Sonoinoltre stati misurati i tempi di campionamento dei dati acquisiti per veri�carel'assenza di fattori che introducono ritardi rispetto ai tempi misurati in fasedi test delle API 8.1. Il tempo di campionamento dei memory referencesrisulta compatibile con il tempo stimato in fase di studio dell'API 5.3.1. Perquanto riguarda gli indicatori sull'utilizzo delle risorse abbiamo forzato unritardo tra una lettura e la seguente di 100ms in quanto l'API aggiorna talevalore solo ogni secondo e quindi una lettura più �tta non avrebbe portatoinformazioni aggiuntive. Dal gra�co osserviamo inoltre come esistano dei picchinel tracciato. Essi rappresentano i ritardi introdotti dal sistema operativoquando, ad esempio, persistiamo i dati su disco.

Figura 8.1: Tempi di acquisizione dati misurati per 1000 campioni.

8.4.2 Impatto sulle performance

In questa fase abbiamo analizzato l'impatto del sistema di acqusizione sulleperformance della macchina virtuale. Utilizzando il programma time di linuxè sono stati misurati i tempi di esecuzione dei programmi bzip e gcc. In se-guito è stato agganciato alla macchina virtuale il programma di acquisizionee sono stati eseguiti i medesimi programmi con il medesimo input, misurandoil tempo di esecuzione con time. La prova è stata ripetuta 100 volte. Nel


gra�co 8.2 si possono osservare i tempi di esecuzione sulla macchina virtualecon e senza programma di acquisizione dati attivo. La media dei tempi di ese-

Figura 8.2: Tempi di esecuzione di bzip e gcc sulla macchina virtuale durantel'acquisizione e non.

cuzione di bzip senza il programma di acquisizione dati è di 8667ms, mentrecon il programma di acquisizione dati agganciato è di 8836ms, quindi supe-riore del 2%, mentre nel caso di gcc è stato ottenuto un tempo di 6262ms inun caso e 6250ms nell'altro caso, quindi addiritura inferiore dello 0.2%. Conquesta prova pertanto si ritiene che l'impatto sulle performance del sistema diacquisizione dati sia trascurabile rispetto ad altri fattori.

8.5 Clusterizzazione Kmeans

In questo esperimento si è voluto utilizzare la clusterizzazione per riconoscerele frame. Per ridurre la mole di dati si utilizza la trasformata DCT sull'interaframe. Nelle �gura 8.3 e 8.4 si possono vedere i risultati del riconoscimento alvariare della lunghezza della frame e del numero di programmi. Gli esperi-menti sono stati condotti utlizzando tutti i 12 programmi della suite CPU2006


Figura 8.3: Tasso di corretto riconoscimento in funzione della durata dellaframe

di Spec. Il train set e il test set sono stati creati utilizzando 10 tracce per ogniprogramma, con diversi input. Le tracce nei due insiemi sono diverse. Comesi nota nelle �gure il tasso di corretto riconoscimento non è su�cientementeelevato per giusti�care l'impiego di Kmeans come unico algoritmo di machinelearning per la pro�lazione utente.

8.6 Test del sistema realizzato Kmeans - Rete

neurale con memory reference

Come descritto in 6.1 abbiamo la necessità di determinare sperimentalmentealcuni parametri:

• dimensione della frame;

• tempo di sovrapposizione delle frame;

• coe�cienti della DCT da considerare;

• numero di blocchi in cui dividere la frame;


Figura 8.4: Tasso di corretto riconoscimento in funzione del numero diprogrammi

• numero di classi in cui clusterizzare i blocchi;

• numero di epoche di addestramento della rete neurale.

Tali parametri vanno determinati per entrambe le tipologie di dati a nostradisposizione: memory references e indicatori sull'utilizzo delle risorse.

8.6.1 Dimensioni e tempo di sovrapposizione delle frame

In �gura 8.5 si può osservare il tasso di corretto riconoscimento in funzionedella lunghezza (in secondi) della frame. Si osserva che frame troppo piccolecatturano poca informazione sull'andamento temporale e possono venir confusepiù facilmente le une con le altre, mentre frame troppo grandi portano ad unaeccessiva perdita di informazione.

Nella �gura 8.6 si piò osservare come varia il tasso di corretto riconosci-mento in funzione della percentuale di sovrapposizione. Si osserva che nonsovrapponendo le frame le une con le altre non si tiene conto dei diversi puntiin cui può iniziare l'acquisizione dei dati e conseguentemente non riconoscere


Figura 8.5: Tasso di corretto riconoscimento in funzione della durata dellaframe

correttamente il programma in esecuzione. Un caso analogo si veri�ca se tuttele frame fossero sovrapposte del tutto.

8.6.2 Coe�cienti della DCT da considerare

In �gura 8.7 è rappresentato l'andamento del tasso di corretto riconoscimentoin funzione del numero di coe�cienti della DCT considerati e dell'esclusione omeno del primo coe�ciente (la componente continua).

Si osserva che l'esclusione della componente continua signi�ca non consi-derare il valore assoluto dei memory reference, ma soltanto le informazionirelative alla loro dinamica, analogamente a quanto avviene nel campo dell'a-nalisi dei segnali. Come si vede in �gura 8.7, da prove sperimentali si ottieneun risultato migliore mantenendo la componente continua.

8.6.3 Numero di blocchi

Un blocco rappresenta l'oggetto che viene clusterizzato, sulla base di un vetto-re creato a partire dai coe�cienti selezionati della trasformata DCT applicata


Figura 8.6: Tasso di corretto riconoscimento in funzione della percentuale disovrapposizione delle frame

al blocco stesso. Successivamente alla clusterizzazione un blocco viene iden-ti�cato da un modo che caratterizza l'andamento del segnale al suo interno.Più elevato è il numero di blocchi più piccolo è l'intervallo temporale conside-rato. Si corre quindi il rischio di avere molti blocchi con lo stesso andamentotemporale che quindi saranno inseriti nello stesso cluster. In �gura 8.8 si os-serva l'andamento del tasso di riconoscimento al variare del numero di blocchiutilizzato.

8.6.4 Numero di cluster

Il numero di cluster rappresenta il numero di modi che assume il segnale. Ogniblocco è caratterizzato da uno di questi modi. Impiegare un numero elevatodi cluster signi�cherebbe discriminare eccessivamente l'andamento temporaledei memory referece e con il conseguente rischio di non riconoscere lo stessoprogramma in due di�erenti esecuzioni e con di�erenti input. Tale fenomenoè rappresentato in �gura 8.9


Figura 8.7: Tasso di corretto riconoscimento in funzione del numero deicoe�cienti della DCT, con e senza componente continua.

8.6.5 Numero di epoche di addestramento

Il numero di epoche rappresenta il numero di volte che il set di train vieneutilizzato per l'addestramento della rete neurale. Se questo numero è troppoelevato si corre il rischio di far perdere generalità alla rete neurale. Viceversaun numero troppo ridotto di epoche non permettono alla rete neurale di rico-noscere il fenomeno per il quale viene addestrata. In �gura 8.10 si osserva chequesta considerazione è supportata anche dalle prove sperimentali.

8.6.6 Selezione dei programmi per i test

In �gura 8.11 viene presentato il tasso di corretto riconoscimento in funzionedel numero dei programmi Spec utilizzati. Utilizzando tutti e 12 i programmisi ottiene un tasso di riconoscimento insu�ciente. Utilizzarne 2 soltanto èpoco signi�cativo ai �ni della pro�lazione utente. Si è scelto di utilizzarne 6.I programmi sono stati scelti in base alla matrice di confusione riportata intabella.


Figura 8.8: Tasso di corretto riconoscimento in funzione del numero diblocchi.

ast bzi gcc gob h264 hmm libq mcf omn perl sje xalaastar 12 3 0 10 7 107 0 3 0 1 13 24bzip2 0 114 2 0 1 2 0 28 0 21 4 8gcc 0 0 71 0 0 0 49 2 21 35 0 2gobmk 10 6 2 15 11 89 0 6 0 2 12 27h264ref 15 3 1 10 12 107 0 3 0 0 17 12hmmer 8 3 2 16 6 108 0 2 0 0 18 17libquantum 0 0 0 0 0 0 156 1 8 15 0 0mcf 0 0 0 0 0 0 0 160 0 19 0 1omnetpp 0 0 0 0 0 0 0 0 172 8 0 0perlbench 0 0 1 0 0 0 1 0 2 175 0 1sjeng 7 5 2 9 8 102 0 2 0 1 23 21xalancbmk 12 11 2 18 9 60 0 4 0 3 25 36

Si sono scelti i programmi bzip, gcc, sjeng, omnetpp, perlbench e libquantumin quanto vengono riconosciuti con una buona precisione dal sistema e inoltreinterferiscono meno tra di loro.


Figura 8.9: Tasso di corretto riconoscimento in funzione del numero dicluster.

8.6.7 Riepilogo

Dopo aver stimato i parametri migliori si è proceduto a testare il sistemacon essi. Dopo ulteriori prove e aggiustamenti abbiamo ottenuto il tasso diriconoscimento pari a 0.66 utilizzando i seguenti parametri:

• lunghezza frame di 48s;

• sovrapposizione del 50% delle frame;

• 16 coe�cienti DCT con la continua;

• 40 blocchi;

• 5 cluster;

• 200 epoche di addestramento.

8.6.8 Confronto rete neurale con HMM

Per confrontare il funzionamento del sistema realizzato è stato e�ettuato unesperimento impiegando come tecnica di machine learning un sistema che im-


Figura 8.10: Tasso di corretto riconoscimento in funzione del numero diepoche di addestramento.

piega modelli di Markov nascosti come modelli. Vengono fornite in input alsistema le frame non clusterizzate. Il risultato ottenuto con tale metodo è untasso di riconoscimento del 0.56. Quindi il metodo proposto è valido.

8.6.9 Impatto della frequenza di campionamento sui

memory references

È stato condotto uno studio sull'in�uenza che il tempo di campionamento deimemory references ha sull'e�cacia del riconoscimento dei programmi in esecu-zione. Per questa prova sono stati raccolti i memory references dei benchmarkSpec bzip2 e gcc. Si è provveduto a dividere le tracce nel seguente modo:

• train set: 10 tracce per ogni programma utilizzando 2 input, quindi 5tracce per programma per input;

• test set: 10 tracce per ogni programma utilizzando l'input rimasto.

Ci si è limitati a solo due programmi per motivi pratici in quanto è necessarioricreare ogni volta i modelli nel momento in cui viene fatta variare la frequenza


Figura 8.11: Tasso di corretto riconoscimento in funzione del numero diprogrammi.

di campionamento. Per questo esperimento sono stati creati e testati i modellidi rete neurale impiegando circa 32 valori diversi dell'indice di abbattimentodella frequenza, ovvero il valore n di f/n. Nella �gura 8.12 è possibile osser-vare il tasso di corretto riconoscimento delle frame dei programmi in funzionedell'indice di abbattimento della frequenza. Si noti come le frequenze da f/20a f/70 portino a tassi di corretto riconoscimento simili.

8.7 Test del sistema realizzato Kmeans - Rete

neurale con gli indicatori sull'utilizzo delle

risorse

Analoghe considerazioni sulla stima dei parametri possono essere e�ettuateanche per gli indicatori sull'utilizzo delle risorse. I parametri utilizzati sono inquesto caso:

• lunghezza frame di 48s ;


Figura 8.12: Tasso di corretta identi�cazione in funzione dell'abbattimentodella frequenza

• sovrapposizione del 50% delle frame;

• 16 coe�cienti DCT con la continua;

• 16 blocchi;

• 5 cluster;

• 500 epoche di addestramento.

Il tasso di corretto riconoscimento è stato dello 0.56. Si noti come il tas-so inferiore sia dovuto alla minor entropia informazionale portata dai datiutilizzati.

8.8 Test della fusione dati con la tecnica di

Dempster-Shafer

Avendo a disposizione due di�erenti sistemi di riconoscimento che utilizzanodati diversi, si possono fondere insieme le informazioni al �ne di migliorare


ulteriormente il tasso di successo nel riconoscimento. Come descritto in prece-denza è stato scelto il metodo di Dempster-Shafer. Fondendo insieme gli esitidel riconoscimento tramite memory references e tramite indicatori sull'utiliz-zo delle risorse otteniamo un tasso di successo pari allo 0.75 In tabella vieneriportato un esempio di come l'algoritmo migliori il riconoscimento:

Frame MR Perf DSbzip2 bzip2 sjeng bzip2bzip2 bzip2 omnetpp bzip2bzip2 perlbench perlbench perlbenchbzip2 bzip2 bzip2 bzip2bzip2 bzip2 sjeng bzip2bzip2 bzip2 sjeng bzip2bzip2 bzip2 omnetpp bzip2bzip2 sjeng bzip2 bzip2bzip2 bzip2 sjeng bzip2bzip2 bzip2 perlbench bzip2bzip2 bzip2 omnetpp bzip2

Si noti come l'algoritmo di fusione migliori il tasso di corretto riconoscimentoscegliendo correttamente la frame nei casi in cui il responso dei due metodi siadiscorde.

8.9 Esempio di funzionamento in ambiente

reale

Come prova conclusiva è stato fatto un esperimento testando i modelli realiz-zati con i 6 benchmark Spec con i programmi veri bzip2 e gcc. Utilizzandotutti e 6 i modelli abbiamo ottenuto un tasso di corretto riconoscimento dello0.26 per quanto riguarda l'analisi dei memory reference, mentre per quantoriguarda le statistiche sull'utilizzo delle risorse otteniamo valori intorno allo0.4. Fondendo insieme i dati con Dempster-Shafer questa volta, otteniamo unpeggioramento del tasso: 0.2. Questo fatto si spiega con i bassi tassi di correttoriconoscimento dei due sistemi in ingresso all'algoritmo di fusione. In un'altraprova sono state fuse le frame dei benchmark bzip2 e libquantum in un'unicaclasse, in quanto il riconoscitore dei memory reference le confonde con proba-bilità elevata. Il risultato ottenuto è un tasso dello 0.63 dopo la fusione. Nellospeci�co abbiamo ottenuto un tasso dello 0.57 per il riconoscitore dei memo-ry reference e dello 0.31 per il riconoscitore delle statistiche sull'utilizzo dellerisorse. In un'ulteriore prova sono state fuse le frame dei benchmark bzip2 e


sjeng in un'unica classe, in quanto il riconoscitore delle statistiche sull'utilizzodelle risorse le confonde con probabilità elevata. Il risultato ottenuto, questavolta, è un tasso dello 0.66 dopo la fusione. Nel dettaglio abbiamo ottenutoun tasso dello 0.30 per il riconoscitore dei memory reference e dello 0.62 per ilriconoscitore delle statistiche sull'utilizzo delle risorse. Da notare che in questiultimi casi la probabilità di corretto riconoscimento è ben superiore alla pro-babilità a priori di scegliere la categoria corretta, 0.20. Il risultato dimostrache la scelta delle 6 categorie non è soddisfacente per il tipo di addestramentoe�ettuato sul sistema realizzato. Utilizzando 5 categorie al posto di 6, in cuiuna categoria è stata realizzata fondendo le due categorie che si confondono dipiù, il tasso di riconoscimento migliora, in linea con quanto ipotizzato in fasedi ideazione del sistema. La classi�cazione in 5 categorie permette comunqueuna buona di�erenziazione dello user behavior.

Conclusioni e sviluppi futuri

Gli obiettivi inizialmente proposti sono stati raggiunti. Lo studio dei principalivirtual machine monitor presenti sul mercato al �ne di identi�carne uno adattoallo scopo della tesi ha prodotto come risultato la scelta del virtual machinemonitor Virtual Box. Il software di acqusizione dati:

• acquisisce i dati in modo corretto;

• è portabile (scritto in Java);

• è mediamente usabile (manca la GUI);

• è stabile;

• non impatta in maniera sensibile sulle performance del sistema.

I dati raccolti dall'API di Virtual Box si sono rivelati signi�cativi al �ne del-la pro�lazione utente. Per un rapido confronto, la raccolta dati tramite in-strumentazione dei programmi rallenta il sistema dalle 1000 alle 10000 volte[Cec10]. Virtual Box è un prodotto di virtualizzazione molto utilizzato inambiente home e small business, tuttavia non fa parte dei virtual machine mo-nitor utilizzati dalle grandi aziende e dalle server farm. L'analisi dei dati, larealizzazione delle varie componenti software, gli esperimenti e�ettuati hannopermesso di:

• realizzare i modelli partendo dai dati acquisiti;

• aggiustare i parametri in fase di test;

• riconoscere, con buona precisione il programma in esecuzione sulla mac-china virtuale tra i programmi Spec;

• riconoscere, in modo soddisfacente, un programma non Spec nella cate-goria corretta.

75

CONCLUSIONI E SVILUPPI FUTURI 76

Per le prove e�ettuate con le frame catturate da programmi Spec, sono stateutilizzate le categorie di programmi: bzip2, libquantum, gcc, sjeng, omnetpp,perlbench. È stato ottenendo un tasso di corretto riconoscimento dello 0.75dopo la fusione 8.8. Per i test e�ettuati con frame catturate dai program-mi non Spec (bzip2 e gcc), sono state utilizzate le categorie di programmi:bzip2+sjeng, libquantum, gcc, omnetpp, perlbench. In questo caso è statoottenuto un tasso dello 0.66 di frame classi�cate con successo nella giustacategoria. Il risultato è da ritenersi soddisfacente, non esistendo ad oggi inletteratura lavori analoghi per un confronto diretto.

Riepilogo del lavoro svolto

Il lavoro svolto in questa tesi si può quanti�care in:

• linee di codice scritte o modi�cate:

� software di acquisizione: 700 (Java);

� software per il framing: 320 (c++);

� software per divisione in blocchi e calcolo DCT: 1400 (c++);

� software per la rete neurale: 1300 (c++);

� software per la fusione Dempster-Shafer: 300 (c++);

� script per automatizzazione test: 200 (bash);

• dati raccolti: 14.2 GB (corrispondenti a 8000 minuti di esecuzioni regi-strate).

In totale per la realizzazione della tesi sono state impiegate circa 1000 ore/uo-mo. Il tempo è stato speso in gran parte per la messa a punto dei programmie per gli esperimenti e�ettuati. In �gura 1 si può osservare la distribuzione didettaglio del carico di lavoro, mentre in �gura 2 si può osservare la distribuzioneraggruppata per sviluppo software, esperimenti, altro.

Sviluppi futuri

Questa tesi può essere utilizzata come punto di partenza per ulteriori lavori diricerca. Uno su tutti è la realizzazione di modelli di workload utilizzando datiraccolti da sistemi di produzione quali Web server, mail server ecc. utilizzandoprogrammi reali. La granularità del riconoscimento negli esperimenti e�ettuatiin questa tesi è molto �ne, in quanto viene riconosciuto il singolo programma in


Figura 1: Distribuzione di dettaglio del carico di lavoro.

Figura 2: Distribuzione per tipologia del carico di lavoro.

esecuzione sulla macchina virtuale. I risultati sperimentali dicono che è possi-bile riconoscere con buona precisione �no a 6 programmi. È pertanto possibilecreare dei modelli di workload in varie situazioni. Un lavoro interessante sullamodellizzazione del workload in ambienti virtualizzati, utilizzando tecniche diregressione numerica sui sulle statistiche di utilizzo delle performance è stato


condotto qui [FA11]. Altri sviluppi e migliorie potrebbero essere:

• migliorare il tasso di corretto riconoscimento tramite una taratura più�ne del sistema;

• migliorare il tasso di corretto riconoscimento tramite una selezione piùaccurata delle classi di programmi;

• e�ettuare ulteriori test ampliando l'insieme delle tracce raccolte per pro-grammi reali;

• miglioramento dell'usabilità, magari attraverso l'implementazione di unadd-on di Virtual Box;

• e�ettuare ulteriori test impiegando altre tecniche di machine learning;

• estrazione di features da altri dati ricavabili dal virtual machine moni-tor(fault di pagina, ...);

• impiego del metodo proposto per la modellizzazione di situazioni anomalenelle macchine virtuali (deadlock, saturazione di risorse);

• estensione ad altri virtual machine monitors (VMware, Virtual PC ...).

Bibliogra�a

[AM13] Massimiliano Nolich Kenji Terabayashi and Kazunori Umeda Ales-sandro Moro, Enzo Mumolo. Improved foreground-backgroundsegmentation using dempster-shafer fusion. 8th International Sym-posium on Image and Signal Processing and Analysis, pages 73�74,2013.

[BK96] Patrick van der Smagt Ben Krose. An introduction to NeuralNetworks. The University of Amsterdam, 1996.

[Cec10] Riccardo Ceccolin. Monitoraggio di applicazioni software mediantemodelli di Markov. PhD thesis, UniversitÃ degli studi di Trieste,2010.

[Cora] Oracle Corporation. Manuale d'uso di virtual box. https://www.virtualbox.org/manual/.

[Corb] Oracle Corporation. Virtualbox main api documentation. https://www.virtualbox.org/sdkref/index.html.

[Doc] SPEC CPU2006 Documentation. The standard performanceevaluation corporation. URL:http://www.spec.org/cpu2006/

Docs/.

[eJJ] Thilo Michael e Je�rey Jedele. Dempster shafer c++ library.https://github.com/jjedele/dempster_shafer_library_cpp.

[Eva] Clark C. Evans. Yaml ain't markup language. http://www.yaml.org/.

[FA11] Micha Mo�e Fatemeh Azmandian. Workload characterization atthe virtualization layer. 19th Annual IEEE International Sym-posium on Modelling, Analysis, and Simulation of Computer andTelecommunication Systems, (19):63�72, 2011.

79

https://www.virtualbox.org/manual/

https://www.virtualbox.org/manual/

https://www.virtualbox.org/sdkref/index.html

https://www.virtualbox.org/sdkref/index.html

URL: http://www.spec.org/cpu2006/Docs/

URL: http://www.spec.org/cpu2006/Docs/

https://github.com/jjedele/dempster_shafer_library_cpp

http://www.yaml.org/

http://www.yaml.org/

Bibliogra�a 80

[FAE08] Janusz A. Starzyk Fathy A. Elmisery. Neural network based onsequence learning for speech recognition. IEEE, pages 139�142,2008.

[GJP74] R. P. Goldberg G. J. Popek. Formal requirements for virtualiza-ble third generation architectures. Communications of the ACM,(17):412�421, 1974.

[itS] itSeez. Opencv computer vision library. http://opencv.org/.

[JF73] G.D Jr. Forney. The viterbi algorithm. Proceedings of the IEEE,(61):268�278, 1973.

[JS05] Ravi Nair Jim Smith. Virtual Machines: Versatile Platforms forSystems and Processes. Morgan Kaufmann, 2005.

[LEBW70] George Soules Leonard E. Baum, Ted Petrie and Norman Weiss. Amaximization technique occurring in the statistical analysis of pro-babilistic functions of markov chains. The Annals of MathematicalStatistics, (41):164�171, 1970.

[Mac67] J. B. MacQueen. Some methods for classi�cation and analysisof multivariate observations. Berkeley, University of CaliforniaPress, (1):281�297, 1967.

[MAER09] Dr. Mohamed Abu Rizkaa Mohamed A. El-Refaey. Virtual systemsworkload characterization, an overview. 2009 18th IEEE Inter-national Workshops on Enabling Technologies: Infrastructures forCollaborative Enterprises, (18):73�77, 2009.

[Moo] Andrew Moore. K-means and hierarchical clustering - tutorialslides. http://www-2.cs.cmu.edu/~awm/tutorials/kmeans.

html.

[Nis] Ste�en Nissen. Fann fast arti�cial neural network library. http:

//leenissen.dk/fann/wp/.

[odt] opencv dev team. Opencv mat. http://docs.opencv.org/

modules/core/doc/basic_structures.html#mat.

[Par] Parlamento. Decreto legislativo 30 giugno 2003, n. 196. http:

//www.camera.it/parlam/leggi/deleghe/03196dl.htm,.

[PBL] Universitá di Pisa Prof. Beatrice Lazzerini, Dipartimento diIngegneria della Informazione. Introduzione alle reti neurali.

http://opencv.org/

http://www-2.cs.cmu.edu/~awm/tutorials/kmeans.html

http://www-2.cs.cmu.edu/~awm/tutorials/kmeans.html

http://leenissen.dk/fann/wp/

http://leenissen.dk/fann/wp/

http://docs.opencv.org/modules/core/doc/basic_structures.html#mat

http://docs.opencv.org/modules/core/doc/basic_structures.html#mat

http://www.camera.it/parlam/leggi/deleghe/03196dl.htm

http://www.camera.it/parlam/leggi/deleghe/03196dl.htm

Bibliogra�a 81

[Pel11] Enrico Pelizzon. Biometria multimodale per accesso sicuro alle in-formazioni sensibli. PhD thesis, UniversitÃ degli studi di Trieste,2011.

[Pie11] Corona Pietro. Fusione di impronta digitale e impronta vocale peril controllo accessi. PhD thesis, UniversitÃ degli studi di Trieste,2011.

[Sga11] Andrea Sgarro. Le entropie eterodosse nella gestione della cono-scenza parziale. Dispense del corso di Logica e Linguaggi, pages18�23, 2011.

[Smi] Joseph Smith. Bug segnalato sull'sdk di virtual box.http://blog.gmane.org/gmane.comp.emulators.virtualbox.

devel/page=138.

[Str99] G. Strang. The discrete cosine transform. SIAM Review, vol. 41,(1), 1999.

[VMSD12] Biju R. Mohan Vasudevan M. S. and Deepak K. Damodaran. Per-formance measuring and comparison of virtualbox and vmware.IPCSIT vol. 27 (2012), (17), 2012.

[Wik] Wikipedia. Discrete cosine transform � wikipedia, the freeencyclopedia. http://en.wikipedia.org/w/index.php?title=

Discrete_cosine_transform&oldid=431189187.

http://blog.gmane.org/gmane.comp.emulators.virtualbox.devel/page=138

http://blog.gmane.org/gmane.comp.emulators.virtualbox.devel/page=138

http://en.wikipedia.org/w/index.php?title=Discrete_cosine_transform&oldid=431189187

http://en.wikipedia.org/w/index.php?title=Discrete_cosine_transform&oldid=431189187

Profilazione utente in ambienti virtualizzati

Education

Transcript of Profilazione utente in ambienti virtualizzati