Sommario

Lezione 1 27/09/2021 (Lecture_1_IE_2020) ...................................................................................................................... 8

System evaluation steps ................................................................................................................................................. 8
Performance analysis ..................................................................................................................................................... 9
Lezione 2 30/09/2021 ....................................................................................................................................................... 10
Tecniche di valutazione delle performance ................................................................................................................. 10
Tecniche di valutazione (Lecture_2_IE) ....................................................................................................................... 15
Le decisioni vanno prese .............................................................................................................................................. 16
LEZIONE 3 01/10/2021 ..................................................................................................................................................... 18
Metriche di analisi delle performance ......................................................................................................................... 18
METRICA/INDICE DI FAIRNESS (indice di equità).......................................................................................................... 21
RESPONSE TIME (orientato all’utente) ......................................................................................................................... 21
Processing rate throughput (frequenza di elaborazione, orientato al sistema) .......................................................... 22
Metriche di Capacity .................................................................................................................................................... 23
LEZIONE 4 04/10/2021 (Lecture_3_IE_21) ...................................................................................................................... 25
Workload ...................................................................................................................................................................... 25
Test Workload Sintetici ................................................................................................................................................ 26
Algoritmo di Sieve ........................................................................................................................................................ 28
Funzione di Ackermann ................................................................................................................................................ 29
SPEC (Systems Performance Evaluation Cooperative) ................................................................................................. 30
Nbody – Homework n°1 ............................................................................................................................................... 30
LEZIONE 5 7/10/2021 (Lecture_4_IE_new) ..................................................................................................................... 34
Caratterizzazione del workload .................................................................................................................................... 34
Caratterizzazione del workload .................................................................................................................................... 36
Averaging...................................................................................................................................................................... 37
Single Parameter Histograms ....................................................................................................................................... 39
LEZIONE 6 8/10/21............................................................................................................................................................ 42
PRINCIPAL COMPONENT ANALYSIS (PCA) .................................................................................................................... 42
Trovare i fattori principali ............................................................................................................................................. 43
Normalizzazione (Z-scores) .......................................................................................................................................... 45
Matrice di Correlazione ................................................................................................................................................ 46
Loading Plot .................................................................................................................................................................. 47
Clustering ..................................................................................................................................................................... 51
CLUSTERING IN PERFORMANCE ANALYSIS ................................................................................................................... 51
LEZIONE 7 11/10/2021 – ESERCITAZIONE SUL CAPACITY TEST CON ING. LIGUORI (WebServer_1.pdf) ....................... 52
JMETER ......................................................................................................................................................................... 54
Elementi principali di un Test Plan ............................................................................................................................... 55
HTTPREF ....................................................................................................................................................................... 59
Parameters Collection – Alto livello ............................................................................................................................. 59
 ELASPSED time vs LATENCY .......................................................................................................................................... 60
Parameters Collection – Basso livello ........................................................................................................................... 61
CAPACITY TEST AND PERFORMANCE(Workload) CHARACTERIZATION – homework n°2 ............................................ 62
LEZIONE 8 14/10/21.......................................................................................................................................................... 66
Clustering ..................................................................................................................................................................... 66
Step del Clustering ....................................................................................................................................................... 68
SAMPLING .................................................................................................................................................................... 69
La selezione dei parametri ........................................................................................................................................... 69
Distance metric ............................................................................................................................................................ 69
Analisi di outlier............................................................................................................................................................ 70
Data Scaling / NORMALIZZAZIONE ............................................................................................................................... 70
TECNICHE DI CLUSTERING ............................................................................................................................................ 71
Algoritmo di agglomeramento cluster ......................................................................................................................... 73
LEZIONE 9 15/10/21.......................................................................................................................................................... 83
Modello di Markov ....................................................................................................................................................... 83
CARATTERIZZARE I DATI MISURATI (Lecture_5_IE) .................................................................................................... 85
Indici di dispersione...................................................................................................................................................... 89
Range ............................................................................................................................................................................ 90
Varianza o deviazione standard ................................................................................................................................... 90
Percentile e quantile .................................................................................................................................................... 90
Quantile-Quantile plots: plot quantile quantile (Q-Q plot). ........................................................................................ 92
LEZIONE 10 18/10/2021 ................................................................................................................................................... 96
Confidence Intervals and Sample size .......................................................................................................................... 96
The standard error ....................................................................................................................................................... 98
Teorema del limite centrale ......................................................................................................................................... 99
Intervalli di confidenza basandosi sulla media di una distribuzione normale, VARIANZA NOTA ............................... 102
Scelta del sample size (dimensione campionaria) ...................................................................................................... 105
T-distribution .............................................................................................................................................................. 108
Zero mean .................................................................................................................................................................. 111
LEZIONE 11 21/10/2021 ................................................................................................................................................. 112
Intervalli di confidenza basandosi sulla media di una distribuzione normale, VARIANZA SCONOSCIUTA ................. 112
Che cos’è la correlazione? .......................................................................................................................................... 117
Hypothesis testing ...................................................................................................................................................... 119
Errore Tipo 1 ............................................................................................................................................................... 122
Errore Tipo 2 ............................................................................................................................................................... 123
Potere della statistica ................................................................................................................................................. 126
P-Value ....................................................................................................................................................................... 127
LEZIONE 12 22/10/2021 ................................................................................................................................................. 128
Web Server Capacity Test Design of Experiment (WebServer_2) ............................................................................ 128
 Hypothesis Test in Matlab .......................................................................................................................................... 128
Z-test .......................................................................................................................................................................... 130
Paired t-test ................................................................................................................................................................ 132
Two sample t-test ....................................................................................................................................................... 132
Assunzione di varianze uguali: homoscedasticity ...................................................................................................... 134
Klmogorov-Smirnov Test ............................................................................................................................................ 137
Wilcoxon rank sumTest .............................................................................................................................................. 137
Workload Characterization ........................................................................................................................................ 137
Homework 3? Non sono sicurissimo .......................................................................................................................... 139
LEZIONE 13 25/10/2021 ................................................................................................................................................. 142
MODELLI DI REGRESSIONE (Lecture_6_IE) ................................................................................................................ 142
Regressione lineare .................................................................................................................................................... 143
Scatter plot o modellazione dell’errore ..................................................................................................................... 145
Allocazione della variazione ....................................................................................................................................... 148
Bontà di un modello regressivo .................................................................................................................................. 151
Deviazione standard (Varianza) dell’errore ................................................................................................................ 153
Intervallo di confidenza dei parametri ....................................................................................................................... 153
Visual tests for Assumptions ...................................................................................................................................... 156
Altri modelli Regressivi, Regressione multi lineare .................................................................................................... 160
LEZIONE 14 28/10/2021 ................................................................................................................................................. 164
Esempio PCA e Clustering studentə ........................................................................................................................... 170
LEZIONE 15 29/10/2021 (Lecture_7_IE_new) ............................................................................................................... 175
Experimental Design and Analysis Parte 1 ................................................................................................................. 175
TERMINOLOGIA UTILE PER LA LEZIONE ...................................................................................................................... 176
𝟐𝒌 factorial design ..................................................................................................................................................... 179
Sign Table Method ..................................................................................................................................................... 181
Allocazione della variazione ....................................................................................................................................... 182
Estensione a K-fattori ................................................................................................................................................. 183
𝟐𝒌𝒓 factorial design ................................................................................................................................................... 184
𝟐𝒌 − 𝒑 Fractional Factorial ........................................................................................................................................ 186
Algebra di Confunding ................................................................................................................................................ 188
Lezione 16 04/11/2021 (Lec_IE_DEP_1) ........................................................................................................................ 190
Dependability ............................................................................................................................................................. 192
Fault-Error-Failure chain. ........................................................................................................................................... 194
Threats propagation ................................................................................................................................................... 196
Reliability .................................................................................................................................................................... 200
Availability .................................................................................................................................................................. 202
LEZIONE 17 05/11/2021 (continua pg 46 Lecture_7_IE_new) ...................................................................................... 203
Experimental Design and Analysis Parte 2 ................................................................................................................. 203
 One factor experiments ............................................................................................................................................. 203
Effetti dei fattori ......................................................................................................................................................... 205
Stima dell’errore......................................................................................................................................................... 206
ALLOCAZIONE DI VARIAZIONE (Importanza e significatività di un fattore) ................................................................ 207
Significance of a factor ............................................................................................................................................... 208
TWO FACTOR EXPERIMENT ........................................................................................................................................ 212
Effetti dei fattori (two factors) ................................................................................................................................... 214
Stima dell’errore (Two factors) .................................................................................................................................. 215
Allocazione della variazione (Two-Factors) ................................................................................................................ 217
ESPERIMENTI CON REPLICHE (Two factors) ............................................................................................................... 219
LEZIONE 18 08/11/2021 ................................................................................................................................................. 226
Experimental Design and Analysis Parte 3 ................................................................................................................. 226
Esercizio DoE 𝟐𝟐𝟑 (Qui non ci sono slide, c’è la registrazione della lezione) .......................................................... 229
Homework 3 – Web server capacity test DoE ............................................................................................................ 236
LEZIONE 19 11/11/2021 (LEC_IE_DEP_1 slide 17) ......................................................................................................... 240
Unità non riparabile ................................................................................................................................................... 240
Repairable unit ........................................................................................................................................................... 241
Availability .................................................................................................................................................................. 242
Safety .......................................................................................................................................................................... 243
RISK ............................................................................................................................................................................. 244
Mantainability ............................................................................................................................................................ 245
SECURITY .................................................................................................................................................................... 245
MISURE DI DEPENDABILITY ........................................................................................................................................ 245
Reliability modelling techniques – Fault tolerance/avoidance (Lec_IE_DEP2_RELTEC_NEW) ................................ 247
Duplication ................................................................................................................................................................. 249
LEZIONE 20 12/11/21...................................................................................................................................................... 251
N-Modular redundancy .............................................................................................................................................. 252
TRM Triple Modular Redundancy............................................................................................................................... 252
Metodi di quantificazione della Dependability .......................................................................................................... 254
Reliability Block Diagrams .......................................................................................................................................... 255
Collegamento in serie tra componenti ....................................................................................................................... 256
Collegamento in parallelo tra componenti ................................................................................................................ 257
Upper bound theorem ............................................................................................................................................... 260
Reliability Modelling ................................................................................................................................................... 261
Lezione 21 15/11/21 ....................................................................................................................................................... 262
Model Based performance analysis (01-markov_chains_2021) .............................................................................. 262
Capacity ...................................................................................................................................................................... 265
Highest level of abstraction ........................................................................................................................................ 267
La legge di Little .......................................................................................................................................................... 268
 Modello stocastico ..................................................................................................................................................... 270
Processo stocastico .................................................................................................................................................... 271
Processi Markoviani ................................................................................................................................................... 272
Catene di Markov a Tempo discreto .......................................................................................................................... 272
Evoluzione nel tempo (Transitorio TD) ....................................................................................................................... 273
Comportamento a regime (TD) .................................................................................................................................. 273
Catene di Markov a Tempo Continuo ........................................................................................................................ 276
Comportamento transitorio (TC) ................................................................................................................................ 277
Comportamento a regime (TC)................................................................................................................................... 278
Processo di nascita e morte (particolare processo continuo) .................................................................................... 280
LEZIONE 22 18/11/2021 (02-queuing_theory_p1_2021) .............................................................................................. 281
Modelli a Coda ........................................................................................................................................................... 281
Notazione di Kendall .................................................................................................................................................. 283
Processo Markoviano ................................................................................................................................................. 284
Sistema M/M/1 .......................................................................................................................................................... 284
M/M/1 performance indicators ................................................................................................................................. 286
Waiting times (tempi d’attesa)................................................................................................................................... 287
Response time Distribution ........................................................................................................................................ 288
Sistema M/M/m ......................................................................................................................................................... 291
M/M/m performance indicators ................................................................................................................................ 293
Modello M/M/m/K a capacità finita .......................................................................................................................... 295
Sistema M/M/m/m Lossy system ............................................................................................................................... 297
LEZIONE 23 19/11/21...................................................................................................................................................... 298
N-modular Redundancy (Slide 36 Lec_IE_DEP2_RELTEC_NEW) ............................................................................... 298
LIMITI DI UN MODELLO SINGOLO .............................................................................................................................. 302
Effect of Coverage ...................................................................................................................................................... 304
Fault Trees .................................................................................................................................................................. 305
Fault trees analysis ..................................................................................................................................................... 306
Lista degli homework: ................................................................................................................................................ 311
LEZIONE 24 22/11/2021 ................................................................................................................................................. 311
Introduction to queueing theory (03-queuing_theory_p2_2021) ............................................................................. 311
Sistemi a popolazione finita (M/M/m/k/p) ................................................................................................................ 311
Proprietà Osservatore esterno ................................................................................................................................... 313
Generic Distribution Service Time (M/G/1)................................................................................................................ 319
Pollaczek-Khinchin formula (PK) ................................................................................................................................. 320
Indicatori di performance di M/G/1 ........................................................................................................................... 322
LEZIONE 25 25/11/2021 ................................................................................................................................................. 324
Queueing Networks (reti di code) (04-queuing_networks_2021) ........................................................................... 324
Reti aperte .................................................................................................................................................................. 325
 Reti chiuse .................................................................................................................................................................. 326
Topologia di rete ........................................................................................................................................................ 326
Two node tandem – rete aperta ................................................................................................................................ 326
Teorema di Burke ....................................................................................................................................................... 327
Reti di Jackson ............................................................................................................................................................ 328
Metriche di performance sulle reti di Jackson ........................................................................................................... 330
Reti chiuse .................................................................................................................................................................. 331
Gordon-Newell ........................................................................................................................................................... 334
External observer property (tecnica di Mean Value Analysis) ................................................................................... 335
Mean value analysis ................................................................................................................................................... 335
LEZIONE 26 26/11/21...................................................................................................................................................... 338
FMEA Standard (Lec_IE_DEP3_FMEA_Standards_new) ........................................................................................... 338
L’importanza del Software RAMS (Reliability Availability Mantainability Safety) ...................................................... 341
Hazard Assessment .................................................................................................................................................... 343
LEZIONE 27 29/11/21...................................................................................................................................................... 344
Da Hazard a Risk ......................................................................................................................................................... 346
FMEA .......................................................................................................................................................................... 347
Failure Modes Identification ...................................................................................................................................... 350
Analyzing Failure Modes ............................................................................................................................................ 352
Effects ......................................................................................................................................................................... 352
Probabilità di occorrenza ........................................................................................................................................... 354
Detection .................................................................................................................................................................... 354
Risk Evaluation ........................................................................................................................................................... 355
(S)FMEA ...................................................................................................................................................................... 356
Certificazione .............................................................................................................................................................. 358
LEZIONE 28 02/12/21...................................................................................................................................................... 361
Software fault tolerance (Lec_IE_DEP4_SWFT_new2020) ....................................................................................... 361
Approcci alla software fault tolerance ....................................................................................................................... 362
Misure della qualità di un software............................................................................................................................ 363
Robust Data Structures .............................................................................................................................................. 364
Tecniche di fault software tolerance: Recovery Block/ N-version Programming ....................................................... 366
LEZIONE 29 03/12/21...................................................................................................................................................... 372
Cloud Computing Systems con Pietro Liguori (Lec_IE_Cloud) .................................................................................... 372
CONCETTI BASE .......................................................................................................................................................... 374
Composizione cloud system ....................................................................................................................................... 376
Tecnologie e metodologie abilitanti ........................................................................................................................... 377
Reliability e security in cloud ...................................................................................................................................... 378
OPEN STACK ............................................................................................................................................................... 378
LEZIONE 30 6/12/21........................................................................................................................................................ 381
 Capacity Planning and management of cloud infrastractures. .................................................................................. 381
Slashdot Effect ............................................................................................................................................................ 382
Traditional Capacity Planning ..................................................................................................................................... 384
Nominal Cloud Capacity Model .................................................................................................................................. 385
Spare Capacity ............................................................................................................................................................ 386
Managing Online Capacity.......................................................................................................................................... 388
Capacity-related Service risks ..................................................................................................................................... 389
LEZIONE 31 09/12/21...................................................................................................................................................... 391
FFDA (Lec_IE_DEP5_FFDA) ........................................................................................................................................ 391
FFDA metodologia generale ....................................................................................................................................... 393
Data logging & Collection ........................................................................................................................................... 394
Data Filtering .............................................................................................................................................................. 396
Manipolazione - COALESCENCE.................................................................................................................................. 397
Data analysis - FAILURE CLASSIFICATION ................................................................................................................... 400
Distribution estimation and GOF test (Goodness of Fit) ............................................................................................ 403
LEZIONE 32 10/12/21...................................................................................................................................................... 406
Data Driven Analysis (FFDA_Training) ...................................................................................................................... 407
Tools usage and sample analysis ................................................................................................................................ 411
Determinare la finestra di coalescenza ...................................................................................................................... 411
Reliability modelling ................................................................................................................................................... 415
Homework finale ........................................................................................................................................................ 417
LEZIONE 33 10/12/21...................................................................................................................................................... 418
Introduzione alla sicurezza ......................................................................................................................................... 418
Confidentiality ............................................................................................................................................................ 419
Integrity ...................................................................................................................................................................... 419
Availability .................................................................................................................................................................. 419
Ulteriori concetti ........................................................................................................................................................ 419
Vulnerabilities, Threats and Controls ......................................................................................................................... 420
Access control ............................................................................................................................................................ 421
Security threats .......................................................................................................................................................... 422
Secure data analysis ................................................................................................................................................... 425
LEZIONE 34 16/12/21 ................................................................................................................................................. 426
Business Continuity and Disaster Recovery................................................................................................................ 426
Event Damage Classification ...................................................................................................................................... 430
Disaster Recovery Plan ............................................................................................................................................... 430
Developing recovery strategies .................................................................................................................................. 431
Backup ........................................................................................................................................................................ 432
Tecnologie di backup .................................................................................................................................................. 434
Lezione 1 27/09/2021 (Lecture_1_IE_2020)
Il corso di Impianti di elaborazione è un corso ingegneristico; infatti, ogni ramo di ingegneria ha il suo corso di
impianti, il compito di questo è insegnare come si valutano i sistemi di elaborazione (intesi come raggruppamento di
elementi anche diversi tra loro) al fine di capire come si sta utilizzando il sistema, e come si possa migliorarlo.
Ma cosa vuol dire valutare un sistema (system evaluation)? Vuol dire valutarne due aspetti:
1. Performance Analysis: analisi delle prestazioni del sistema.
2. Dependability Analysis: analisi dei requisiti non funzionali come affidabilità e sicurezza.
Per poter valutare un sistema dobbiamo prima di tutto imparare ad effettuare misure e ad analizzare i dati, questi
due aspetti sfruttano un insieme di modelli statistici, design sperimentali, misurazioni, simulazioni e teoria delle code.
Che argomenti tratteremo al corso? Tecniche assestate che sono sviluppate all’interno dell’azienda e qualche accenno
a tecniche di frontiera o innovative.
Effettuare le tecniche per la valutazione di affidabilità non implica la costruzione dei sistemi per poi testarli, ma si
progetta prima il sistema e poi lo si valuta. L’affidabilità la analizzo in fase di assegnazione della commessa e
attraverso l’uso di modelli. Quando la parte commerciale fa la proposta di una gara e si cerca di rispondere ai requisiti
della stessa cercando di fare un modello per convincere il committente a valutare il sistema.
Durante il corso verranno assegnati degli homework che verranno sviluppati e discussi all’esame. L’homework deve
essere un lavoro nostro personale e non devono essere perfetti proprio per poterne discutere all’esame.
Il libro di testo è ART of PERFORMANCE ANALYSIS. Non valuta la perfezione dell’esercizio ma la maturità dello
studente

System evaluation steps

Perché studiamo la valutazione dei sistemi? Perché contrariamente a quello che si crede, essa non è una scienza
empirica o non esatta, ma invece segue diversi aspetti di processi ingegneristici. I punti sui quali ci baseremo sono:

• Definire cosa valutare (tipicamente si può valutare anche un sottosistema, riducendo la complessità
generale).
• Raccogliere informazioni.

• Effettuare determinate misure. Nella prima parte vedremo le performance delle prestazioni e poi vedremo
anche affidabilità e sicurezza.

• Analizzare i risultati. Non è facile ma ci sono metodologie per l’analisi dei dati, gran parte di esse devono
provenire anche dall’esperienza dell’ingegnere che effettua tale analisi.
• Fornire i GIUSTI feedback (testo il tasso di fallimento o eventuali bottleneck a valle di tutto il processo)

È fondamentale, ad esempio, trovare un compromesso tra performance e reliability. Un sistema molto performante
ma poco affidabile non ha senso, così come il contrario. (Ad esempio, windows vista è poco performante ma molto
reliabile perché fu il primo a predire il fallimento dei driver prima che fallissero realmente per farne il restart).
Si sta sempre più parlando in ambito industriale di digital twin (gemello digitale) ovvero creare un gemello del sistema
reale, questo permette di effettuare in maniera più facile ed economica le diverse valutazioni o manutenzioni del
sistema. Oggi tutti i sistemi si costruiscono con modelli digitali facendo mette l’ingegneria informatica alla base di
tutto.
Le principali proprietà da valutare sono sostanzialmente due:
1. Dependability (non funzionale): Ad esempio system mean time to failure (associata alla reliability), oppure la
probabilità di fornire la risposta corretta al tempo T. Sicurezza.
La parte non funzionale risponde alla domanda: “Does it work, and for how long?”
2. Performance: Si risponde alla seguente domanda “Given that it works, how well does it work?” non si può
fare una misura di prestazione considerando che il sistema non funzioni. In questo caso si valutano:
Throughput, Probabilità che il sistema si blocchi, Tempo di Risposta.
Quando misuro le prestazioni di un sistema, assumo che sia failure free, ovvero non ci sono fallimenti.
Se devo fare misure di prestazioni il sistema DEVE funzionare. Se ho dei dati come i tempi di risposta dell’applicazione
GO IN devo togliere tutte le entry relative a degli errori.
Libri di testo:
• Art of computer systems performance analysis: R. JAIN (1991)

• Reliability and availability engineering: Bobbio/Trivedi

Performance analysis
La performance analysis occuperà 1/3 del corso e vedremo che vuol dire fare analisi delle prestazioni e che vuol dire
valutare il sistema.
Quando progetto un qualcosa non devo pensare al carico attuale ma al carico futuro. Chi fa performance analysis la fa
per due motivi:

• Capacity Management (Presente): Si prova ad assicurare il massimo della performance basandosi sulle risorse
attuali. Si effettua un tuning delle risorse correnti
• Capacity Planning (Futuro): Si prova ad assicurare la disponibilità di un quantitativo adeguato di risorse in
futuro in base ai requisiti di carico che saranno necessari. Acquisire nuove risorse
Se andremo a fare questo lavoro andremo a gestire parte di sistemi complessi (oggi tutte le aziende hanno tutte le
risorse hw in datacenter o privati o pubblici). Se devo andare a gestire le risorse di un sistema (vedi il sito INPS durante
la pandemia) devo sia analizzare per il presente sia delineare quelle che saranno le scelte future.
Durante la pandemia il prof ha gestito il carico del sistema del Santobono per dislocare i bambini su tutto il territorio
campano.
C’è differenza tra management e planning? Per quanto riguarda fasi come:
• Strumentazione dei sistemi, ovvero capire dove prendere i dati con l’inserimento di sonde.

• Monitorare l’utilizzo di un sistema (raccogliere dati, analizzarli e fornire dei sommari sui dati)
• Caratterizzare il WORKLOAD.
o Il WORKLOAD è la parte principale per valutare un sistema nella maniera corretta. Si caratterizza il
carico da sottoporre al sistema, ad esempio analizzare il sito dell’università. Dovrei raccogliere dati
per due anni e poi dare delle risposte ma non me lo posso permettere; quindi, devo prendere un
batch limitato di dati e imparare a predire e devo poter estrarre informazioni da dataset enormi.
• Predire le performance del sistema, a partire dalla caratterizzazione del workload. Ad esempio, si può
predire quanto il sistema può essere migliorato, oppure predire il tempo di risposta, etc.; Modelli predittivi e
modelli regressivi.
Quello che differenzia il management e il planning è la parte finale.

• Management
a. Input per modelli simulati o per regole di tuning, sono dettagliati e per sistemi specifici
• Planning
a. Modelli di solito meno dettagliati, grossolani purtroppo non esistono spesso molte alternative
Il fitting è una cosa e il modello predittivo ne è un’altra. Il modello predittivo NON FA fitting.
Volendo riassumere il corso, o meglio una parte di esso, vedremo:

• Come specificare tutti i requisiti di performance

• Come scegliere delle alternative di design.
• Cercare di capire se c’è il valore ottimo di qualche parametro per comparare due o più sistemi

• Determinare il valore ottimale di un parametro (system tuning)

• Trovare le performance che mi portano a dei bottleneck
• Caratterizzare il carico del sistema
Passiamo ora ad alcune definizioni banali:
1. Sistema: accozzaglia di hardware, software e firmware che effettuano una certa elaborazione.
a. Se faccio un sistema per il controllo del traffico aereo, e faccio il push di un piano di volo esso è una
struct in IDL e sostanzialmente questa struttura viene riempita. L’ingegneria del sw testa la funzione
e mi dà misure legate alla parte applicativa. Ma quel programmino compilato è circa un giga. Tutta la
parte midware, controllo, guardie etc etc. non la vede la IS ma la vedo se guarderemo il sistema.
2. Metriche: Criteri per valutare le prestazioni di un sistema (tempo di risposta, numero di richieste per secondo,
carico di lavoro)
3. Workload: richieste fatte dagli utenti del sistema

Lezione 2 30/09/2021
Iniziamo con una serie di ESEMPI per il corso di impianti.
ESEMPIO 1: voglio comparare le prestazioni di sistemi differenti. Ad esempio:
• Compara due disk driver

• Compara due sistemi transazionali

• Compara due algoritmi di trasmissione di pacchetti.
La scelta delle metriche dipende anche dai sistemi da comparare; infatti, se devo comparare dei dischi comparo le
velocità di lettura e scrittura, ma queste metriche mica le posso usare per un sistema transazionale? No, in quel caso
uso il numero di transizioni per secondo. Nel terzo caso vado a vedere i pacchetti persi, per dirne una.
TUTTO DIPENDE DAL SISTEMA QUINDI INGEGNERIA DEL SISTEMA
Si parla di ingegneria del sistema perché come prima cosa da fare studiamo il sistema, capiamo come è stato
progettato e sviluppato ed infine dalla conoscenza del sistema vado a valutare le sue prestazioni.

Tecniche di valutazione delle performance

Per effettuare una valutazione si sceglie:
1. Tecnica di valutazione, abbiamo tre famiglie
 a. Misura diretta, misuro il sistema e raccolgo dati con grandezze realistiche, si applica spesso a sistemi
reali. Sono una tecnica molto accurata (il livello però dipende anche dalla bravura di chi le fa), ma
hanno alcuni problemi: sono costosi, consumano tempo, e sono complessi da ottenere in quanto sono
difficili da generalizzare a causa dei sistemi diversi ed eterogenei.
b. Tecniche simulative, non ho il sistema e allora uso un modello simulativo che astrae la parte di
interesse del sistema reale dal punto di vista del funzionamento e cerco di misurare, attraverso le
metriche, i parametri del sistema. È caratterizzata da un livello di dettaglio arbitrario ed ha costi,
efficienza e accuratezza medi.
c. Modelli analitici (Teoria delle code): descrivo il sistema attraverso un modello analitico, da usare
quando non abbiamo conoscenza alcuna del sistema. I modelli analitici sono i più semplici e i più
astratti, servono per fornire un lower bound di sistema fornendoci le misure nominali. La tecnica però
è la più veloce ed economica.
2. Metriche: i criteri usati per valutare le performance (es: tempo di risposta, transazioni per secondo)
3. Workload: tutto ciò che impongo al sistema (numero richieste, query, carico del sistema, etc.)
Vediamo se è veramente così facile analizzare le prestazioni del sistema.
ESEMPIO 1: ho due link A e B e voglio misurare il numero di pacchetti persi in relazione alla grandezza del file.

Quale link è il migliore? Siamo portati a fare una media dei due link e vediamo che Il link B, in media, perde meno di A e
quindi è giusto dire che B è migliore.
Ma io non sto considerando il WORKLOAD. Se io non so come è la distribuzione
delle dimensioni dei file nel canale non so dire quale è migliore. Se ad esempio io
trasferisco un sacco di 1300 e una sola volta 50 per forza è meglio B ma se mando
1000 volte 1K e una volta 1200K diventa A il migliore.

Quello che è importante dire è che se non conosco il workload non so dire quale
sistema è meglio di un altro. L’altro esempio di cui vale la pena prendere coscienza
riguarda il misurare le prestazioni del sistema, ma non in senso assoluto, ma ricercare anche quali parametri impattano
di più sullo stesso.
ESEMPIO 2: Ho un sistema basato su JAVA con 3 tipologie di garbage collector, 3 tipi di workload e 3 tipi di CPU.

Voglio capire l’impatto dei vari parametri sulle mie prestazioni questo serve per effettuare il design by experiments
ovvero serve quando sto progettando e voglio caprie dove devo migliorare il mio sistema. Quando ho più parametri su
cui riflettere non vado a testare randomicamente e senza un criterio, ma progetto gli esperimenti, quindi faccio design
of experiments: creo un determinato numero di esperimenti che vanno a capire l’impatto sulle prestazioni.
Ulteriore esempio su cui ci soffermiamo è l’aereo in cui devo misurare gli esperimenti simulati. Progetto gli esperimenti
sul simulatore per trovare subito l’impatto dei parametri. Facciamo questo schema per capire che molte volte il design
of experiments non lo dobbiamo pensare con tecniche di misura dirette, nonostante noi lo facciamo, ma non dobbiamo
dimenticare che la progettazione degli esprimenti è molto importante anche quando la progettazione non la tengo e
quindi ci basiamo su modelli simulativi e comportamentali.
Quando uso i digital twin devo simulare ingressi al sistema, il quale ha dei parametri e in questo caso vediamo le ali,
devo poi capire quali sono le parti che sono più sollecitate dell’aereo al fine di vedere qual è l’impatto dei vari parametri
sull’aereo. Progettiamo degli esprimenti per prendere delle soluzioni, date delle scelte progettuali prima che il sistema
sia fatto. Oggi, in questo modo, si accorcia il time to market.
Esempio 5
Supponiamo che misuro il tempo medio di risposta di un DB ed esso è di tre secondi. Durante un minuto di osservazione,
la macchina è in idle per dieci secondi. Determinare i seguenti parametri:

Questo tipo di problemi viene spessissimo risolto attraverso il modello analitico, questo vuol dire avere un modello del
sistema con soluzione in forma chiusa ovvero modelli di code, che sono una astrazione della realtà molto potenti.
Altra cosa che dobbiamo vedere è l’arte della performance evaluation. Dovremo fare spesso dei benchmark per dire
che il nostro prodotto è meglio di altri.
Esempio. Vediamo un insieme di dati di due sistemi A e B, il throughtputs lo misuro in transazioni per secondo come
segue:

Effettuo la media e mostro se è meglio B o A quando poi in realtà sono equivalenti.

Andando a normalizzare rispetto a B ottengo che A è il migliore. L’operazione di normalizzazione consiste

semplicemente nel dividere il valore dei workload rispetto al sistema di riferimento, in questo caso abbiamo che il
Workload1 verrà diviso di 10 e il valore del Workload2 di 20 infine calcolo nuovamente la media dei valori.
Quindi giocando con i numeri abbiamo ottenuto che B è meglio di A, ma se facessi la normalizzazione rispetto ad A
otterrei il contrario; quindi, dico che:
• Sono uguali

• A è meglio di B

• B è meglio di A
Nel libro c’è un capitolo che parla del gioco del benchmark e vuol dire molto poco se non è collegato al tipo di workload
che riesco a fare nel sistema. Quando facciamo il benchmark vedremo che ci sono dei kernel benchmark che riguardano
delle operazioni chiave e critiche del mio sistema.
Al di là dei numeretti nel corso impareremo ad avere a che fare con sistemi più complessi. Vediamo come esempio un
mail server JAVA dove i client potevano collegarsi con un protocollo POP3/SMTP e si andavano a fare misure su questo
server.

Che significa misurare un sistema complesso? Significa avere misure del genere:

Se siamo fortunati so che un esperimento è sopra ad un altro esperimento (in A abbiamo che il rosso è sopra al blu) e
se siamo fortunati vedo il grafico e lo dico immediatamente. Questo ovviamente non capita sempre le cose possono
diventare più complesse.
Se ho un throughput SMTP molto oscillante con grossa varietà dei dati ho una fatta in sovrapposizione, ovvero la zona
dove l’EXP32 e l’EXP17 coincidono fortemente in zona 2500-6000. Anche se compresse con questo grafico me la cavo e
dico che nell’exp 32 si elaborano più mail dell’exp 2 e 7.
Possono ancora più complicarsi, infatti se vediamo il tempo del Garbage collection abbiamo questo grafico

La cosa migliore da fare, in questi casi, è suddividere il grafico in epoche e studiare i comportamenti zona per zona.
Costruisco modelli statistici e non puntuali questo perché mi aiutato ad effettuare l’analisi dei dati per capire i
comportamenti di un esperimento.
Vediamo un ulteriore esempio, ho due workload che voglio inviare al mio sistema il primo invia 1000 mail il secondo
900. Quale va meglio?

Per guardare i dati sperimentali dobbiamo prima di tutto chiederci come da questa serie temporale possiamo eliminare
tutta la parte casuale e tenermi quella fenomenologica. Dal punto di vista statistico, queste due serie sono identiche.
Nel nostro caso esistono diversi elementi non deterministici che possono causare tali eventi, quali lo scheduling,
l’interrupt non bounded, etc.

Tecniche di valutazione (Lecture_2_IE)

Spesso, nella valutazione delle prestazioni, si possono commettere una serie di errori. Ci sono tre problematiche
principali nella valutazione delle prestazioni: l’obiettivo, il workload e la non conoscenza di tecniche statistiche
fondamentali. Molte volte, può accadere di non avere un obiettivo ben preciso nella valutazione delle prestazioni;
inoltre, talvolta, anche se si prefiggono degli obiettivi, non si tiene conto di un parametro fondamentale nella
valutazione delle prestazioni, ossia il workload a cui il sistema è sottoposto.
Per questo motivo, quando si esegue un’analisi delle prestazioni è importante seguire un approccio sistematico. Sono
dieci i punti fondamentali:
1. Capire gli obiettivi e definire il sistema
2. Elencare i servizi forniti e i risultati ottenuti dal sistema
3. Selezionare le metriche di valutazione delle performance
4. Elencare i parametri che influenzano le performance
5. Selezionare i fattori da studiare, ovvero quei parametri che variano durante la valutazione delle performance
del sistema
6. Selezionare le tecniche di valutazione
7. Selezionare i workload
8. Effettuare il design of experiments
9. Analizzare ed interpretare i dati
10. Presentare i risultati
Bonus: ripetere tutto.
Ritorniamo alla spiegazione delle varie tecniche di valutazione, vediamo: Modelli analitici, simulativi e misure
sperimentali.
Molto spesso esistono degli errori comuni fatti durante la valutazione dei sistemi e sono quelli mostrati nell’immagine
qui sotto. Ad esempio, la categoria del “No Goals” vuol dire che spesso si valutano i sistemi, senza avere un obiettivo
specifico senza capire cosa si vuole ottenere.
Lo schema che si vede subito dopo invece mostra gli errori più comuni effettuati.

Le decisioni vanno prese

Vediamo adesso in che modo scegliere una tecnica di valutazione tra le seguenti:
1. Tecniche di valutazione
a. Analytic modelling (teoria delle code)
b. Simulazioni
c. Misure sperimentali
2. Metriche di performance
3. Richiesta di prestazioni
Gli esperimenti sul campo non sempre sono buoni, ma sicuramente sono i più affascinanti ma non è sempre vero che ci
sia bisogno di sperimentare a causa dell’invasività. Come facciamo a capire, data una delle tre tecniche, se i risultati
sono esatti? Useremo la cross validation, che vedremo più avanti nel corso.
I modelli analitici sono importantissimi in altri domini, e anche nel nostro nonostante qualche detrattore. Nel dominio
edile il sistema viene prima progettato, fatto un modello, sul modello messo un carico/workload che bisogna imporre,
si ottengono i risultati dalle prove e su quel modello si prendono decisioni progettuali. I risultati di questo modello mi
possono già guidare in progettazione. Tratteremo nel caso delle prestazioni con la teoria delle code. Ci sono sempre i
modelli analitici non dimentichiamo che siamo ingegneri e prima di costruire il sistema devo fare un modello, validarlo
e poi scrivo eventuali rapporti.
Anche i modelli simulativi combinano modelli matematici e concetti logici che ne descrivono il comportamento. Ad
esempio, le previsioni atmosferiche sono migliorate rispetto a 30 anni fa proprio grazie a modelli simulativi più precisi.
Le misurazioni sono fatte su sistemi reali ed esistenti sono costose in termini di tempo e soldi ma se fatte bene possono
essere accurate. Abbiamo anche la difficoltà nel dettagliare per bene i risultati, ma ovviamente sono accurati poiché
abbiamo il sistema realizzato.

Le tecniche hanno dei criteri per poter essere applicati, modelli analitici e simulativi li posso applicare ad ogni step del
processo produttivo addirittura nella pratica quelli analitici li uso prima ancora. Il tempo richiesto dai modelli analitici è
poco mentre per la simulazione dipende; per le misure dirette non so dire i tempi. In tutto questo vien da sé che le
misure dirette non sono applicabili senza modello reale, o almeno un prototipo
Che strumenti servono? Un analista per fare modelli, nella simulazione ci vuole un linguaggio e chi fa misure dirette
deve saper fare strumentazione.
Per l’accuracy dipende poiché ogni risultato può essere sbagliato o forviante. I costi aumentano in maniera crescenti.
Le misure dirette non le devo mai privilegiare anche perché sono costose.
Prima ci siamo fatti la domanda, data una tecnica la uso, come so che i risultati sono veritieri? È impossibile! Per avere
almeno la correttezza dell’uso della tecnica uso la cross validation. Ma che vuol dire?
Uso il modello simulativo, non mi fido dei suoi risultati fino a quando non uso quello analitico che me lo valida, poi
quello a misure dirette. Una volta che li ho usati confronto i risultati dei tre!
Si hanno tre regole di cross-validation:
1. Non affidarti ai risultati di una simulazione senza che essi siano validati anche da modelli analitici o misurazioni;
2. Non affidarti ai risultati di un modello analitico senza che essi siano validati anche dalla simulazione o dalle
misurazioni;
3. Non affidarti ai risultati di una misurazione senza che essi siano stati validati anche dalla simulazione o dai modello
analitici.
Quando faccio una misura diretta mi conviene sempre fare un piccolo modellino, per capire se le misure appartengono
al sistema o sono false.
Su modelli analitici e simulativi o faccio la cross validation pura, cercare di vedere se le misure sono dello stesso ordine
di grandezza dell’output dei modelli, o provo modelli analitici e simulativi con parametri misurati direttamente sul
campo. In genere convince molto i clienti.

LEZIONE 3 01/10/2021
A fine lezione2 abbiamo introdotto la Cross Validation ovvero, non dobbiamo fidarci di un solo modello o misura ma
effettuare i controlli in maniera incrociata; ciò nonostante, questa regola non è la panacea a tutti i problemi del corso
d’impianti. Sta a noi capire se le misure ottenute sono valide o meno.
In questo esame noi non sviluppiamo software ma sarà lui a fornirci cosa valutare e dovremo “solo” effettuare
valutazioni e misure. Anche per la parte sperimentale ci fornirà tutto lui.
Con la lezione di oggi finiamo l’impostazione dell’analisi delle prestazioni.

Metriche di analisi delle performance

Vediamo ora quali sono le metriche di performance o di valutazione. Quando parliamo di performance, parliamo
sicuramente di:
• Tempo di risposta o responsività, orientata all’utente

• Throughput o produttività, orientata al sistema

• Utilizzo delle risorse (analisi del costo) del sistema, orientata al sistema.
Queste tre metriche sono quelle più utilizzate nel campo e le abbiamo viste anche in altri corsi come BD dove parlavamo
di transizione per secondo. Abbiamo anche visto a SO per lo scheduling un analisi dei costi, ricordiamo che non esiste lo
scheduling perfetto e quindi o si fa felice l’utente, nei tempi di risposta, o chi ha comprato il sistema aumentando la
produttività.
Produttività e tempo di risposta sono correlate negativamente. Se aumenta una diminuisce l’altra.
Vedremo anche valutazioni di requisiti di proprietà non funzionali, se pensiamo ad un sistema avionico, di cui vedremo
esempi pratici, vedremo come si valuta l’affidabilità di un sistema.
Altre metriche importanti sono le metriche di dependability (metriche di affidabilità) come Availability
(Disponibilità),Reliability, Performability ossia una metrica composta che ci permette di capire, in caso di fallimento,
come il sistema riesce a fornire un servizio. Un ulteriore metrica che si utilizzerà si basa sulla valutazione dei
costi/prestazioni.
Vi sono poi delle metriche che valutano il compromesso tra costi e prestazioni. Però perché nell’immagine di sopra non
vi è definito niente a destra di cost/performance? Perché sono a sensibilità del sistemista.
Come seleziono le metriche di prestazioni? La figura è importante è va capita per bene. Occorre sempre ricordare
che, quando si analizzano le prestazioni, si assume che il sistema sia correttamente funzionante e privo di
guasti/malfunzionamenti.

Supponiamo che vi sia una richiesta di un determinato servizio al sistema, la risposta del sistema può essere fornita
in DONE o non fornita.
Se sono in Done e la risposta è corretta allora posso iniziare a parlare di performance, quindi essa è relativa SOLO a
sistemi che danno una risposta corretta.
Con analisi di dominio il tutto diviene un po’ più semplice, perché il sistema funziona e deve effettuare delle misure
quali:
• Analizzo il tempo di risposta

• Il throughtput
• L’utilization.
A prescindere dalla modalità con cui rilevo e prendo le misure sono comunque caratteristici del mio sistema.
Nell’altro caso in cui sono sempre in Done ma la risposta non è corretta ho un altro dominio completamente diverso,
significa che ci sono stati degli errori. La probabilità che il mio pc si rompa non la conosco ed è un evento probabilistico.
L’evento failure o erratico è un evento che non posso prevedere ma che posso studiare solo in base probabilistica. Se
faccio un test e dico: “Faccio un test per 1h e il sistema su 1000 richieste ne sbaglia 200 ottengo che il tasso è del 20%.”
Questo non deve succedere. Se faccio un test e in 1000 ne sbaglio 200 vuol dire che qualcosa non va. Se devo fare test
di performance devo togliere quel 20% e poi fare analisi prestazionali sull’80% rimanente.
I TEST DI PERFORMANCE SI FANNO NELL’ASSUNZIONE CHE IL SISTEMA FUNZIONI, I TEST DI SICUREZZA AFFIDABILITÀ
E TUTTO QUELLO NON FUNZIONALE SONO ESENTI DI QUEST’ASSUNZIONE.
La security non cambia molto dall’affidabilità, tant’è che a livello alto entrambe convergono nel concetto di safety. Quali
sono le metriche che studieremo? Le metriche sono probabilistiche e dobbiamo imparare come tirare fuori delle
valutazioni anche su base probabilistica. Ad esempio, uno standard richiede che un treno non debba fallire con valore
pari a 10−8 e se succede il treno si deve fermare, come assicuro tale risultato? Non sperimento per 1000000 di anni ma
dovremmo avere un modello predittivo che è diverso da uno di fitting.
Dato un sistema a seconda di quello che voglio studiare, se definisco metriche diverse andiamo a finire su metriche e
processi completamente diversi.
CASO DI STUDIO 2 congestion control algorithms
Dato un Sistema, a seconda di quello che voglio studiare posso definire metriche e tecniche diverse. Ad esempio, ho un
servizio che invia pacchetti da una specifica fonte ad una specifica destinazione, in maniera ordinata. I possibili outcome
sono:
1. Alcuni pacchetti sono consegnati in ordine alla destinazione corretta
2. Alcuni pacchetti sono consegnati ad una destinazione guasta
3. Alcuni pacchetti sono consegnati più volte (con dei duplicati)
4. Alcuni pacchetti sono droppati per strada (pacchetti persi).
C’è un contesto in cui performance, affidabilità e sicurezza si confondono e questi sono i sistemi large scale (in inglese,
non scale che vi fanno salire i piani, animali). In sistemi come Netflix/Dazn/etc non c’è un vero studio dell’infrastruttura,
pensano al fallimento come un overhead e l’unico modo che ho per rilevarle è evitare l’overhead stesso.
Per questi tipi di sistema se vado a fare metriche di performance assumo che tutti i pacchetti vengano inviati in ordine
e mi vado a definire i vari tempi di risposta di ricezione di un pacchetto come mostrati nell’immagine.

Se rileviamo questa ipotesi di funzionamento possiamo prendere altre metriche. Se rimuoviamo l’assunzione che il
sistema funzioni interviene la parola probabilità.

Avrò la probabilità di out of order, loss packets, duplicate packets, disconnect.

Vedremo con il teorema del limite centrale, per i dati aggregati, che se il campione è abbastanza grande possiamo dire
qualcosa di veritiero e di preciso.
Prima di finire con le performance vediamo qualche indice più particolare e usato in alcuni contesti.
METRICA/INDICE DI FAIRNESS (indice di equità)
Cosa succede quando più utenti richiedono l’uso di una risorsa e il throughput totale del sistema viene diviso dal sistema
con gli utenti che pagano una quota diversa?
Supponiamo che 𝑥𝑖 sia la frazione del throughput dato all’utente i, 𝑛 è il numero di utenti nel sistema:
(∑𝑛𝑖=1 𝑥𝑖 )2
𝑓(𝑥1 , 𝑥2 , … , 𝑥𝑛 ) =
𝑛 ∑𝑛𝑖=1 𝑥𝑖2
Tale valore è sempre tra 0 ed 1, se il throughput è distribuito uniformemente(tutti usano quello che pagano) è pari ad
1 e quindi è fair, se k utente degli 𝑛 totali ricevono 𝑥 frazione e 𝑛 − 𝑘 utenti ricevono zero throughput allora l’indice di
𝑘
fairness è pari a .
𝑛

Lo scopo di questo indice è chiedersi: quello che stanno pagando i vari utenti è equo con quello che stanno utilizzando?
Tale indice è super utilizzato quando si gestisce il cloud computing, si fornisce rete mobile o internet, etc.
ES:

Supponiamo che tre utenti VC1, VC2, VC3 stiano usando la banda di connessione, il primo 50 Mbps il secondo 30 ed il
terzo 50. Supponiamo che gli utenti paghino per 50, 10, 10. Il sistema sta distribuendo il throughput in maniera fair?
La risposta è in percentuale, non binaria ed in ogni caso sì abbastanza fair, circa 81% vediamolo attraverso i calcoli.

Il throughput normalizzato è il rapporto di quello che ho fratto il massimo, questa è la più semplice e ce ne sono di
diverse.

• Throughtput misurato: (50, 30, 50)

• Throughtput fornito in maniera fair: (50, 10, 10)

Il prof lo apprezza all’esame anche se non è fondamentale. In genere da 75/70 in poi già è fair. Spesso le compagnie
lasciano una poco di unfair. Questo capita anche con infrastrutture non proprietarie.

RESPONSE TIME (orientato all’utente)

Il response time non è facile da calcolare, ad esempio come misuro il response time di un web server? Do uno start
quando ho il pacchetto e allo stop misuro il tempo? Lo posso fare attraverso un ping oppure attraverso la classe Chrono
di C++ ? Mi serve un client che si collega al server per poter effettuare queste misurazioni. Il tempo di risposta dipende
sempre dal client, non me lo dà il server (se vado al bar e chiedo un caffè il tempo di risposta me lo dà il cliente non il
barista).
Questi tempi, queste piccole aliquote possono influire sulla nostra misura. Quando faccio una misura di response time
non faccio una sola richiesta ma un bel campione.
Quindi formalizzando abbiamo che è un parametro definito come: l’intervallo di tempo che intercorre tra la richiesta
dell’utente e la risposta del sistema. Risponde alla domanda “quanto velocemente il sistema produce i risultati”. Nella
valutazione del tempo di risposta si DEVE EVITARE ciò che è casuale (tempo di login, tempo di pensamento dell’utente,
etc.…). È un parametro critico per : Interactive systems, Real-time system , Parallel computing.
Le misure del response time sono:
• Response time: intervallo richiesta-risposta
o Misurato dalla fine della richiesta
o Può risultare ambiguo
• Reaction time: fine della richiesta per far partire l’elaborazione

• Turnaround time: inizio di una richiesta di fine response

Ciò che importa del response time è che in un qualsiasi sistema esso aumenta con il crescere del carico. (crescere degli
utenti).

Generalmente, il response time (asse y) cresce all’aumentare del workload (asse x). Tale andamento generalmente
cresce con una “pendenza” che dipende da un fattore di stretch: più è alto il fattore di stretch, più il sistema si comporta
male (cresce troppo il response time all’aumentare del carico), viceversa più è basso e meglio il sistema funziona (ed è
abbastanza scalabile).
Come misuro questo fenomeno del response time? Con lo stretch factor. Ma perché questo fattore è importante? Lo è
perché mi permette di predire quando il sistema non sarà più usabile.

Processing rate throughput (frequenza di elaborazione, orientato al sistema)

Con questa valutazione misuriamo il lavoro per unità di tempo. Importante per :
• Dimensionamento di sistemi multiutente.
• Multimedia.
• Comparazione di configurazioni alternative.
Esempi di throughput:

• Transizioni bancarie per ora

• File transfer bandwitdth
• Aircraft control updates per second
• Visitatori di un parco per giornata
Abbiamo detto che le metriche di performance che ci interessano di più sono il throughput e il response time.
Il throughput, al crescere del carico, ha un andamento crescente, se faccio l’esempio del bar ho che il bar è vuoto ed il
numero di caffè inizia a crescere. Stiamo osservando quello che c’è prima della prima linea tratteggiata. In questo
stesso intervallo il response time si mantiene abbastanza stabile. Dopo di che il sistema comincia a saturarsi, il sistema
continua a funzionare ma il throughput cresce poco mentre il response time cresce velocemente. In questo intervallo
il response time ha uno stretch factor più alto. La zona finale è dove il sistema sta morendo perché elabora molte
richieste e ne perde altrettanti fino a quando non si ferma e si spegne.
L’altro parametro che si vede è il Power e ha l’espressione indicata sulla slide, guardando le curve abbiamo che con
Power vedo la fascia dove il sistema funziona bene, primo segmento, poi c’è un knee della curva dove il sistema va in
sovraccarico e poi alla fine va in morte con un throughput elevatissimo e un response time che lo affonda. Sarà difficile
trovare questo punto di suicidio del sistema perché ci sono degli algoritmi di controllo delle congestioni che effettuano
il dropping delle richieste.

Metriche di Capacity

IL SISTEMA NON VA MAI FATTO LAVORARE VICINO ALLA SATURAZIONE, È UNA PAZZIA.
Non è facile osservarle perché ci possono essere degli input rumorosi, per questo guardo un'altra grandezza che è il
POWER. Con la potenza subito riconosco il massimo e quindi il picco. A sinistra del picco la potenza cresce, a destra del
picco la potenza decresce fino alla morte del sistema intorno allo 0.
Dobbiamo far lavorare il nostro sistema sulla knee capacity che corrisponde al picco del power. Quello che
dall’immagine risulta tratteggiata è la nominal capacity, tutti i valori nominali servono come bound per il mio sistema.
Si chiama knee capacity perché è il ginocchio della curva del throughput e della response. La usable capacity è un punto
massimo dopo il quale il sistema muore. I sistemi di overload detection vanno a vedere proprio dove sta questa usable
capacity.
Che succede con i nostri esercizi? Se trovo Knee a 290 e Usable a 300 forse forse sto sbagliando qualcosa. In questi casi
vado a vedere la potenza! Cerchiamo di scegliere punti dove i carichi sono lontani sennò non ho margine di elasticità.
Quando prendiamo questi punti abbiamo che praticamente non devono uscire linee precise, è normale che ci siano
delle ondulazioni. Spesso far saturare il sistema è difficile e non c’è una distanza percentuale fissa tra le due capacity, la
distanza ci deve sempre essere, se non ci fosse non si potrebbe mettere in esercizio il sistema. Quanta distanza dipende
da come è configurato il sistema stesso.
Se usable capacity va sopra nominal capacity è sbagliato! Però più è vicina più sono bravo. Più complico il modello
analitico più sono propenso a sbagliare. Il modello deve essere semplice ma funzionale. Devo fidarmi del mio modello.
Quindi ricapitolando le metriche di performance comuni abbiamo:

• Nominal Capacity: Throughput massimo raggiungibile sotto condizioni di lavoro ideali. Esso è un limite teorico,
dunque se si vuole ottenere un throughput superiore è impossibile e inoltre il tempo di risposta è massimo
quando il throughput è troppo alto (Si calcolerà con un modello analitico e la teoria delle code).
• Usable capacity: Massimo throughput ottenibile senza eccedere un pre-specificato tempo limite di risposta.

• Knee capacity: Knee = è il punto in cui vorremmo far lavorare maggiormente il sistema, poiché il tempo di
risposta è minimo e il throughput è massimo
Alcuni sistemi misurano anche l’efficienza, anche se si usa per lo più per fare lo speedup dei processori. Nel campo delle
performance l’efficienza è data dal rapporto tra usable capacity e nominal capacity.

Vediamo alcune cose sulla resource utilization, molte volte le nostre analisi di prestazioni non sono solo mirate a vedere
le metriche precedenti ma hanno il compito di trovare dei colli di bottiglia, ovvero risorse critiche che se saturate
mandano in morte il sistema.
Come si potrebbero individuare? Per fare ciò si usano dei sistemi di monitoring, ad esempio system monitor, che fanno
resource utilization; cioè scaricano la percentuale dell’utilizzo di risorse del sistema. Un bottle neck è un insieme di
risorse che ha un utilizzo maggiore di risorse rispetto alle altre. Se trovo una risorsa più usata delle altre essa è un collo
di bottiglia. In questo caso abbiamo che il Network sembri essere una bottle neck.
OSS (Considerazione importante per gli esercizi): Nel corso di un capacity test, individuare la usable capacity non è
banale. Occorre, infatti, saturare il sistema (“bombardare il sistema fino quasi a farlo crashare”). Se, a partire dalle
misurazioni sul sistema, otteniamo un andamento lineare throughput-carico, allora è molto probabile che il sistema non
è stato saturato.

LEZIONE 4 04/10/2021 (Lecture_3_IE_21)

Oggi parleremo di benchmark, ovvero un tipo di workload, anche chiamato test-workload il quale viene utilizzato per
comparare più sistemi. Com’è giusto che sia spieghiamo per bene cos’è un workload

Workload
Abbiamo detto che non esiste un’analisi di prestazioni, di qualunque sistema, senza tener conto di cos’è un workload;
anche quando si fa un analisi medica.

Il workload rappresenta tutti gli input sottomessi ad un sistema in un determinato arco temporale. Dato un sistema,
che espone una certa interfaccia, il workload rappresenta l’insieme di tutte le richieste provenienti da un insieme di
utenti, siano essi fisici o reali o altri sottosistemi del sistema complesso.
Quando vogliamo fare uno studio di performance analysis dobbiamo misurare alcune metriche di un certo sistema
quando un certo workload è presente, non possiamo prescindere dal capire quale sarà il workload da applicare al
sistema. Dobbiamo definire un test-workload ovvero, quello che useremo per fare analisi di performance.
Il test-workload può essere di due tipologie:
1. Sintetico: uno semplice, poco corposo ed è usato per emulare le operazioni principali che ci interessa applicare
al sistema quando vogliamo misurare le prestazioni
2. Reale: per avere condizioni di reale utilizzo, è un bel problema da fare perché il dataset di input è enorme e
dobbiamo applicare tecniche di riduzione.

Per oggi ci focalizzeremo sui workload sintetici.

Test Workload Sintetici

Vediamo un esempio, se io lavorassi per Sky o Vodafone e dovessi scegliere le architetture per il nuovo router o del box
da vendere, faccio un analisi prestazionale attraverso un workload simile alle condizioni di lavoro alle quali i sistemi che
ho già lavorino, voglio dunque provare come rispondono questi nuovi.

I workload sintetici sono una rappresentazione sintetica dei workload di test reali che vogliamo
sottoporre al sistema. In genere, rispetto ai workload reali, sono piccoli, facili da usare, non toccano dati
sensibili, risultano essere rappresentativi delle proprietà reali.

Diversi sono i workload sintetici utilizzati per lo studio delle performance:

• Addition Instruction: il più vecchio dei workload sintetici, quando furono introdotti i primi calcolatori
potevano essere eseguite solo poche operazioni al secondo e quella più frequentemente utilizzata
 era l’istruzione di ADD. Con buona approssimazione, il calcolatore che eseguiva questa operazione
più velocemente era considerato il più performante.
• Istruction Mixes: è una generalizzazione dell’addition, dove non do più per assunto che l’ADD sia la
più usata, ma attraverso l’elaborazione dei dati posso considerare l’occorrenza delle istruzioni del
processore. Questo tipo di workload è formato da istruzioni + frequenza d’uso normalizzato.

In questo caso abbiamo che “load and store” è la più eseguita e via dicendo il resto, usata tutt’oggi
nonostante l’età, cerca di caratterizzare il workload reale generando un workload sintetico che
riporta la stessa percentuale di occorrenza delle istruzioni.
Tuttavia, tale approccio, presenta diversi limiti tecnologici e teorici:
o Relativamente ai limiti tecnologici, è molto complicato applicare quest’approccio sui
processori moderni, in quanto entrano in gioco problemi di concorrenza delle cache,
interferenza con altri device etc. È pertanto un approccio più facilmente utilizzabile nel
mondo embedeed, quindi processori più semplificati e specific purpose.
o Come limite teorico, questo approccio sottintende la “legge dei grandi numeri” (o Teorema
di Bernoulli). Attenzione non giocate troppo con la frequenza delle attività perché noi
considerando la legge detta prima abbiamo che: “Se il numero di eventi tende all’infinito
la frequenza relativa tende alla probabilità dell’occorrenza dell’elemento”.
Supponiamo di metterci su un grafico, sull’ascisse abbiamo il numero di prove e sulle
ordinate un contatore. Ogni volta che lancio la moneta, se esce testa salgo se esce croce
scendo; nel finito troverò una curva che è avrà un andamento simile

Si dimostra che per un evento, a cardinalità due (testa/croce), la probabilità per la quale nel
finito troviamo che la distribuzione delle frequenze corrisponda alla probabilità è pari ad 1.
Questo vale ancora a quattro, a sei non è più certo che troviamo l’associazione frequenza-
probabilità ma circa 34%.
In questo contesto le metriche di performance sono:
▪ MIPS: Milion of istruction per second
▪ MFLOPS: Millions of floating-point operations per second
 • Kernels: Per non incorrere nei problemi mostrati sopra si è passata a questa modalità, Kernel
ricordiamolo vuol dire nucleo e in questo caso la funzione più frequente. Questo vuol dire che se ho
molte operazioni su interi, userò un kernel che fa molte operazioni su interi ma non uso uno random
ma uno specifico quali: Sieve, Puzzle, Tree Searching, Ackerman’s Function, Matrix Inversion, and
Sorting.
Lo svantaggio principale è che i kernel non fanno uso, di solito, di dispositivi di IO e quindi l’analisi
delle performance non riflette le prestazioni dell’intero sistema.
• Synthetic Programs:
• Application Benchmarks: Utilizzando la parola benchmark, ripetiamolo, vogliamo indicare l’uso di un
tipo di workload che però è usato per comparare più sistemi, ed il processo di comparazione per la
misurazione è chiamato benchmarking. Quindi è un workload standardizzato, ovvero è riconosciuto
attraverso un agreement tra i vari competitor tecnologici.
Affinché due sistemi possano essere comparati ci devono essere delle proprietà da verificare:
o Rappresentativo, ovvero deve rappresentare il workload
o Portabilità, attraverso i vari sistemi
o Ripetibile
o Scalabile
o Non intrusivo
o Facile da usare
o Facile da capire

Algoritmo di Sieve
Vediamo ora alcuni benchmark partendo proprio da Sieve, il quale basa sul criterio di Eratostene per i numeri primi. Lo
scopo dell’algoritmo è trovare e stampare tutti i numeri primi al disotto di un numero n.
Questo benchmark come funziona?
1. Scrive tutti i numeri da 1 ad N
𝑥
2. Cicla da K = 2 a √𝑁 e calcola
𝑘

a. Se il resto è 0 elimina x.
b. Se il resto è diverso da 0 allora tiene x.
Cosa vado a stressare nel mio processore? Le operazioni di compare e di branch su numeri interi, quindi operazioni
sullo stack del processore. Si è visto che oggi con ogni core che ha una cache di 1° lv, tutto il gioco delle performance
dei processori dipende dalla gestione delle cache. Il Sieve è troppo dipendente dal compilatore e quindi non stressa il
processore e quindi il prof ha abbandonato questo benchmark e si è aperto a nuove esperienze.

Funzione di Ackermann
È una funzione ricorsiva a due parametri, qual è il suo obiettivo? Valutare l’efficienza della chiamata a funzione; ma
perché devo valutare la chiamata a funzione? Perché così misuro le prestazioni del processore nella gestione dello
stack di sistema, cioè quello stack relativo al meccanismo di chiamate a funzione (Importante per il passaggio di
parametri, per gestire le eccezioni e il resume dei programmi, etc). I parametri d’ingresso del sistema rappresentano la
grandezza del sistema e tale funzione non fa altro che esplodere un albero di 𝑚 − 1 rami in chiamate a funzione.

Esistono infine anche altri benchmark, moltissimi sono a pagamento e pochi sono free. Fino all’anno scorso abbiamo
usato il benchmark Linpack, esso è stato progettato da Jack Dongarra e serve per sistemi densi, quindi molti
coefficienti diversi da zero, di equazioni lineari. Questo benchmark era carino perché andava a stimolare molto il
sistema di floating point del processore. La dimensione del problema era il numero di equazioni.
Esiste un link da dove posso scaricarlo sulla slide, date le dimensioni del problema l’algoritmo genera un sistema di n-
equazioni e fornisce la soluzione.

Il problema è che quando si restituisce la n°esima soluzione avevamo che la generazione dell’equazioni non era
deterministica ma era rappresentativa e quindi i punti di gestibilità e controllabilità non erano applicabili, in più è
molto sensibile al numero di core del sistema. Questa che vediamo è la tabella di benchmark di Linpack per diversi
sistemi.

SPEC (Systems Performance Evaluation Cooperative)

è una suite benchmark per diversi sottocomponenti del sistema fornisce dei workload rappresentativi e da una capacità
di tuning molto elevata.

Nbody – Homework n°1

Questo benchmark simula l’evoluzione di N corpi in un sistema gravitazionale. Ad esempio, l’immagine della galassia
mostrata di seguito la possiamo ottenere in simulazione attraverso 1700 corpi circa.

Con questa simulazione gestisco i corpi nello spazio e nello spazio la forza gravitazionale è la preponderante . L’iterazione
tra i corpi avviene secondo un sistema di equazioni a derivate parziali con cui analizzo il movimento dei corpi celesti.
La simulazione dà il numero di corpi, genera le matrici di movimento e poi va in un tool grafico che me lo fa vedere. Per
l’esame il tool grafico non mi interessa e non usiamo la funzione di stampa delle matrici, ma mi interessa la parte
dell’algoritmo riguardante il tempo di calcolo delle matrici.
Si usa Nbody perché è uno dei benchmark più usati oggi perché guarda allo stack, al numero dei core e alle operazioni
floating point. Anche se non è standardizzato si usa.
L’obiettivo nostro è comparare due sistemi con stesso sistema operativo ma processori differenti. Se impariamo a
gestire l’impatto che ha il cambio di un sistema operativo nelle nostre operazioni posso fare dei benchmark ancora più
accurati.
Aumentando la dimensione N, quindi il numero di corpi aumenta la complessità dell’algoritmo che è 𝑂(𝑁 2 )
Per curiosità posso cercare algoritmi ottimizzati, lui ce lo dà in C++ ma sta anche in python, intel compilato etc però è
tutto a curiosità personale. Il nostro scopo non è l’algoritmo ma fare dei test e fare delle metriche.
Il file che ci darà è il makefile e dobbiamo tenere traccia del compilatore usato, in ogni esercizio noi non dobbiamo fare
una trattazione enorme con teoria etc ma dobbiamo solo spiegare cosa abbiamo applicato e quali sono le nostre
considerazioni. Gli devo dare prima tutte le caratteristiche del test (il processore con numero di generazione e sigla),
sul compilatore non si aspetta grandi cose, non usiamo ottimizzazioni (non dobbiamo fare i furbi) per apprezzare
differenze. Anche se non ci sono differenze per lui è apprezzabile. Apprezza tutto!

Vediamo adesso il codice.

C’è un main, che in genere si prende un parametro di ingresso rappresentante il numero di corpi che devono interagire.
Chiama la funzione e si prende lo start e stop con la Chrono.
Auto deduce il tipo di una variabile dichiarata dall'espressione di inizializzazione durante il run time. Chiamo la funzione
e stampo il tempo. Attenzione, la stringa in COUT, poiché ci dà il sorgente, posso toglierla per portarla in altri ambienti.
Se levo il numero da una parte lo devo togliere anche dall’altra.
La classe nbody.CPP ha un costruttore e un distruttore.
Questa funzione di timeIntegration() il prof non la chiama, ma se vogliamo darla ad un tool grafico mi stampa tutte le
matrici di movimento, quindi posizione/forza/velocità.
Il prof si è accorto poi che questo algoritmo lui lo usava quando faceva PROGRAMMAZIONE 2 con la lezione multithread
dove faceva un programmino di una palla che rimbalzava in un quadrato.
Poi abbiamo tutto l’algoritmo che calcola la forza gravitazionale etc etc. in totale sono 150 linee di codice e ci ha dato
anche lo script launch_nbody.sh. L’SH vuole due parametri il numero di chiamata e il numero di bodies.

Una volta scaricato il “nbody.zip” fornito dal prof da riga di comando, se avete un compilatore c++, fare make all. Una
volta fatto questo si genera il file nbodySIM e per lanciarlo basta chiamarlo ed aggiungere il numero di corpi da
simulare (dimensione del problema).
Lo script si chiama con: bash ./launch_nbody.sh , facendo così ci spiega cosa vuole e per lanciarlo ripeto il comando con
l’aggiunta dei flag -r e -n

Su teams troviamo uno ZIP con tutti il materiale del benchmark.

LEZIONE 5 7/10/2021 (Lecture_4_IE_new)

Caratterizzazione del workload
La volta scorsa dicemmo che dobbiamo realizzare un workload di test per poter effettuare la performance analysis e
che può essere o sintetico o reale. Nel caso in cui il workload è sintetico abbiamo visto i benchmark e le tecniche di
costruzione.
Si evidenzia come i workload sintetici presentino forti limiti in termini di rappresentatività del workload reale: un
workload sintetico potrebbe non funzionare in casi più complessi, in quanto non ci consente di esplorare
accuratamente ogni dettaglio di un workload reale, dove tali dettagli potrebbero essere decisivi per la
caratterizzazione del workload stesso. Inoltre, tipicamente dal workload passato possiamo predire dettagli sul “Che
succede con i workload reali”, ovvero dei workload che hanno delle proprietà simili a quelli reali?

I workload reali possono essere applicati poche volte a causa dei dataset, normalmente possiamo farlo quando i dataset
sono abbastanza piccoli da poterli replicare. Purtroppo, per fare qualcosa del genere abbiamo degli effort non banali. A
questo punto, come otteniamo workload realistici? Studiando un workload reale e cercando di costruire un modello che
integri tutte le proprietà alle quali noi siamo interessati ovvero quelle conosciute come le proprietà statiche o
dinamiche.
In generale, quando misuriamo le prestazioni, possiamo misurare le prestazioni del sistema nel suo complesso, oppure
di una parte di esso (componente/sottosistema). Come terminologia, allora indicheremo con:
• SUT = System Under Test, ed è il sistema su cui imponiamo un workload in una campagna di performance
analysis
• CUS = Component Under Study, ossia il componente che si sta studiando/misurando e può coincidere con
tutto il sistema.

Ci occupiamo del problema di come costruire workload realistici con caratteristiche “statistiche” simili a quelle dei
workload reali. Perché mettiamo statistiche tra parentesi? Lo vediamo più avanti.
Partiamo con la parte di workload e di performance analysis. Capire qual è un workload e come selezionarlo può essere
anche articolato infatti, se voglio capire e valutare come si comporta il sistema di I/O di un web server che workload
devo usare?
Il mio sistema non è una black box ma un sistema di elaborazione con più componenti e sottocomponenti, devo quindi
capire come analizzare anche queste sottocomponenti. Procediamo per ordine, utilizzeremo questa terminologia:
• User = entità (anche software) che effettua la richiesta del servizio.

• Workload components: chi genera le richieste al sistema

o Applications
o Sites
o User Sessions

• Workload parameters (Workload features): Misure di quantità, richieste di servizio, risorse richieste. Per
esempio, i tipi di transazione, dimensione dei pacchetti etc.
I workload components dovrebbero essere messi a livello di sistema (SUT Interface), non è che se voglio misurare il
disco in un sistema web vado direttamente a stressare il disco.
Un workload è sempre a livello di sistema! Quindi devo generare, a partire da un workload di sistema, un eventuale
workload per un determinato componente. Un esempio didattico carino è capire come valutare un web server.
Esempio web server. Se vogliamo dividere tutti i layer che generano richieste ho:

Tipicamente, un sistema di questo tipo consiste in varie componenti: un client, un canale (la rete), un server, ed
eventualmente file system e disco. Quando analizziamo un certo componente/sottosistema, occorre valutare quattro
aspetti:
- Servizi: i servizi forniti sono quelli di visita di una pagina, di seguire un hyperlink, di
mostrare le informazioni di una pagina.
- Fattori: i fattori che influenzano le prestazioni di un web client possono essere la
dimensione della pagina, il numero di link, etc.
- Metrica: La metrica per valutare le prestazioni del client (anche detta variabile di risposta)
è il tempo di risposta.
- Workload: Le componenti del workload, invece in questo caso, possono essere una lista di pagine da visitare o
una lista di link da seguire.
Mettiamo caso, noto che per avere prestazioni migliori devo cambiare il disco, ok sono 200€…moltiplicalo per mille
sistemi e vediamo se ancora li possiamo comprare. Se ho una server farm, che devo fare? Devo cambiare dischi oppure
no?
Vediamo un esempio più realistico per capire un attimo come effettivamente posso prendere le misure per poi
effettuare le giuste valutazioni. Se prendiamo la tangenziale e voglio capire l’impatto delle persone che vengono da Nola
che devo fare? Devo prendere tutte le macchine e chiedere da dove vengono, quante persone sono e l’orario. Così
studio il workload di alto livello e determino il traffico sulla tangenziale. Che relazione c’è con il mio web server? Se io
ho un workload di alto livello di richieste http esso impatta anche nei livelli successivi; devo capire quindi la relazione
tra il workload di alto livello con quello che misuro ad un livello successivo.
Ogni livello ha la sua stazione del workload, ha dei fattori che possono influire e ha delle metriche e dei fattori. A seconda
del livello ho servizi diversi.
Domanda esame: Molte volte ci si chiede: perché si fa una caratterizzazione del system load? È importante notare come
il system load (carico del sistema) sia anch’esso un fattore che può influire sulle prestazioni del web server, nonostante
sia un fattore difficilmente controllabile. (Ad esempio, se consideriamo il carico complessivo di un nostro PC, non
riusciamo a controllarlo) Tuttavia, anche se non controllabile, a noi interessa considerare il system load per capire come
variano le prestazioni in presenza di un carico basso, medio o alto.
Nelle slide 8 – 11 ci sono i vari tipi di analisi in base a quale parte del sistema facciamo riferimento.
Molte volte quello che lui vede all’esame è che ci scordiamo questa parte perché ci concentriamo sulla statistica. Questa
parte è importante perché faremo degli esercizi dove ci sono parametri del workload che non sono controllabili.
Quando misuro il workload sul disk rate non è che voglio replicarlo, perché non so neanche come farlo, ma mi servono
per capire se saturo o no il disco etc etc.

Caratterizzazione del workload

La caratterizzazione del workload è l’insieme delle analisi che si effettuano al fine di sintetizzare un workload che
abbia le stesse caratteristiche di un workload reale. A che mi serve caratterizzare un workload? Devo caratterizzare un
workload per realizzarne uno sintetico e che sia riproducibile con caratteristiche simili al reale. Vi è la necessita di
utilizzare modelli statistici perché devono catturare il comportamento statico e dinamico del workload reale e dovrà
essere semplice da riprodurre, accurato e ripetibile.
È un modello statistico perché deve racchiudere tutte le proprietà, anche dinamiche del nostro modello.
Perché ho il workload sintetico? Perché deve essere:

• Riproducibile

• Ripetibile

• Accurato
Vedremo delle tecniche di Data Mining che consentiranno di ridurre il dataset con cui si opera. Il nostro obiettivo non
è trovare l’ottimo e di avere algoritmi di ottimo non me ne fotte proprio. Quando sto in azienda e mi danno un
problema e un budget non mi posso mettere a fare lo splendido, ma devo dire qual è il massimo dell’accuratezza che
posso avere nel tempo prefissato.
All’esame spesso gli portano della roba per massimizzare il cluster etc etc ma non se ne fotte. A lui interessa sapere che
se ho 10 voglio questa accuratezza, se ho 20 ho quest’altra etc.
Diventiamo bravi quando abbiamo controllo sull’errore e sappiamo quindi come approssimare. Ci servono tecniche per
valutare, e per valutare effort e per allocare budget.
Esempio. Supponiamo di avere 20 milioni di tracce di funzionamento di un sistema; inoltre, supponiamo
che ogni esperimento, che effettuiamo per valutare le prestazioni su ogni traccia, duri 1 giorno intero, bloccando
anche le funzionalità del sistema. È assolutamente impensabile effettuare 20 milioni di esperimenti. Se, invece,
troviamo un modo per sintetizzare tali 20 milioni di tracce in 1 sola (che sia
rappresentativa), allora ha molto più senso.
Quando definiamo un modello, la cosa fondamentale è capire anche quanto si sbaglia usando quel particolare
modello, ossia calcolare l’errore commesso.
INIZIAMO LA PARTE UN POCO PIU’ STATISTICA
I vari modelli che vedremo sono i seguenti:
Averaging
Ovviamente il primo modello quale può essere? La media o indici di tendenza centrale e sono tutti indici che cercano
di riassumere un dataset.
La media è un modello? Si, rappresento un insieme di numeri con un valore. Qual è il problema? Dipende da quanto
sbaglio e dunque dall’errore.
Voglio un modello statistico che si, deve essere bello ma devo tenere conto dell’errore e quindi dobbiamo sempre
cercare quanto è differente il modello dai dati che abbiamo definito. Come misuro questo errore?
Mettiamoci nel caso in cui uso la media (poi vediamo con la mediana etc).
𝑛
1
media 𝑥̅ = ∑ 𝑥𝑖
𝑛
𝑖=1

Se ho la media esprimo il mio errore come somma di deviazioni (si definisce deviazione lo scarto del valore sottratto
dalla media). Per cui l’errore totale è la sommatoria delle mediazioni.
Vediamo un esempio, ho {1,2,3,3,4} 𝑥̅ = 2.6, mi va bene? Devo vedere l’errore prima e nel caso di media posso
esprimerlo come somma di deviazioni e quindi l’errore totale = ∑(𝒙𝒊 − 𝒙̅) = 𝟎. NO, la somma delle deviazioni NON è
una rappresentazione dell’errore appropriata perché è sempre pari a zero.
È questa la differenza tra fitting e modello. Il fitting cerca i punti a distanza media nulla, mentre il modello non lo
cerca. Quindi se ho dei punti sparsi e cerco il fitting, non ho un modello previsionale, questo perché cerca di rendere 0
la somma delle deviazioni.
Una cosa è l’errore del modello statistico, una cosa è l’errore lineare di un modello di fitting.
Il Fitting descrive bene l’andamento ma non dirà nulla su quello che succederà dopo e quindi come misuro questo
errore?
CON LA DEVIANZA o Sum of Squadre errors (SS)! La devianza è la somma degli errori quadratici, ma che è?
̅)𝟐
𝑺𝑺 = ∑(𝒙 − 𝒙
Questo è un buon modello d’errore perché ci dice molto sulla variabilità dei dati, più i dati sono variabili più si discostano
dalla loro media. Ovviamente è palese che dipenda dall’ammontare dei dati che abbiamo raccolto, per superare questo
problema possiamo calcolare la media dell’SS sul numero di osservazioni. Ciononostante, siamo interessati nell’usare
l’errore dell’esempio per stimare l’errore nella popolazione e così possiamo dividere l’SS per il numero i gradi di libertà
(𝒏 − 𝟏)
Ma questa somma è problematica perché? Perché soffre del problema dell’overfitting! La media dell’errore quadratico
cresce al numero di punti e più crescono i punti più cresce l’errore. Diciamo questo perché ci sono modelli come il
clustering dove posso dire solo qualcosa sulla devianza ma non altre cose.
Alcuni metodi di identificazione statistica sono basati su devianza e devo stare attento perché più punti ho peggio è.
Quindi in teoria cerco di normalizzare la devianza. A TS ho imparato a normalizzare per il numero di campioni N e l’ho
chiamata varianza. Ma a noi non interessa la statistica descrittiva, non mi interessa della popolazione. Io parto dal
campione per dire qualcosa della popolazione quindi uso grandezze campionarie.
Le grandezze campionarie devono essere normalizzate in base al numero di gradi di libertà, cioè il numero di grandezze
dipendenti. Vediamo un esempio:
ESEMPIO: Se siamo cinque persone e se devo fare una squadra di calcetto e decido i ruoli, arrivo al quinto membro che
non ho possibilità di scelta, allora il mio campione ha N-1 gradi di libertà e chiameremo questa grandezza Varianza
campionaria.

Misura accurata dell’errore, dell’approssimare il nostro campione con la media e fornisce indicazioni di quanto gli
elementi nel dataset si discostino dalla media. La radice quadrata è la deviazione standard campionaria

La parola campionaria non la userà più, poiché tutto è sempre campionaria, la

statistica descrittiva per noi non esiste.
Si usa abbastanza il coefficiente di variazione COV (rapporto tra deviazione standard e media) che mi fa capire quanto
è buona l’approssimazione della media sul mio dataset. Mi fa capire quanto la media si discosta dai punti.
Coefficiente 0 vuol dire che è costante, più alto è il coefficiente più è alta la varianza. HIGH COV ci permette di capire
che la media non va bene per approssimare il dataset. (Si discostano molto dalla media). LOW COV ci permette di capire
che la media va bene per approssimare il dataset. (I valori del dataset si discostano poco dalla media)
La deviazione non è misura dell’errore. La devianza è ancora una misura dell’errore che posso normalizzare. Se voglio
però capire quanto la media si discosta dai campioni prendo il COV.
CASE STUDY: PROGRAM USAGE IN EDUCATIONAL ENVIROMENT
C’è un trace di esecuzione di un server, ho i coefficienti di variazione (essendo così alti capisco che la media non
rappresenta bene il campione) e vedo i valori medi.

È chiaro che se qualcuno ci dice: Hai questo dataset, noi gli possiamo solo dire: Senti io con questo ci faccio poco, l’unica
cosa che ti posso dire è che la media di utilizzo della CPU è 2,19 ma che posso tranquillamente sbagliare di 40 secondi
la misura.
Viceversa, nell’immagine successiva noi possiamo notare come un coefficiente di variazione al disotto di 5 sia
ragionevole, e quindi le medie rappresentano bene il campione.

Single Parameter Histograms

Che succede se i coefficienti di variazione sono molto alti, come lo capisco? Uso la tecnica molto semplice di
generalizzazione attraverso la costruzione di un istogramma. Quindi, se il coefficiente di variazione (COV) è elevato,
per caratterizzare un workload in maniera più precisa rispetto alla media (errore più basso) si utilizzerà un istogramma
frequentistico a singolo parametro. Esso costruisce una CDF empirica dei nostri dati, la quale ci indica l’occorrenza
media dei valori nel dataset (quali sono i valori più frequenti e quindi più probabili del nostro dataset).

Se non ho la media posso dire che i valori più probabili del dataset possono passare da 1000 punti a solo 8, cercando di
prendere i valori più probabili e lo faccio con gli istogrammi frequentistici. Per farlo usiamo il tool JMP

Dalla tabella che vogliamo vedere, Il numero di thread? Faccio: Seleziono la colonna, analizza, distribuzione, threads,
bottone “Y, Colonne”, ok e vedo l’istogramma per thread.
Mi fa vedere quali sono i valori più frequenti, mi dà il valore medio (rappresentato dalla sbarra verticale prima del rombo
sulla parte alta dell’immagine), la mediana, il valore percentile e i valori più probabili. Usa questo tool anche perché mi
fa vedere visivamente i valori più probabili già nella tabella.
Ha cambiato file, e ha preso un file del sw cineca. (software per la contabilità a valle della riforma Gelmini che centralizza
la contabilità dell’ateneo invece che averla per dipartimento).
Tornando a JMP ci dice i dati più frequenti (posso anche restringere il bucket) e dunque i dati più probabili. Se li seleziono
ho un’estrazione del dataset con i dati più probabili.
Poi mi fa vedere anche gli outlayer. Gli outlayer sono punti che vanno fuori dal 75%, non devo eliminarli ma devo capire
(almeno in questo corso) se sono comunque punti utili per tracciare delle metriche o degli eventi.
L’istogramma frequentistico ci viene molto in aiuto e visto questo uno potrebbe dire: Bene, scelgo quelli più probabili
costruisco il dataset e ho finito. Purtroppo, non è così perché l’istogramma non tiene conto delle CORRELAZIONI TRA I
PARAMETRI. Non so se due punti sono correlati tra loro.
Vediamo questo problema, supponiamo di avere due fattori: tempo di CPU e Tempo di I/O. Realizzo i due istogrammi.

Se prendo l’istogramma per i tempi di CPU e quello per i tempi del DISCO abbiamo detto che prendo i punti più frequenti
di CPU e IO DISK, faccio tutti i miei esperimenti e me la cavo. Il problema è che se ci sono correlazioni alcune cose non
hanno senso. CPU TIME E DISCO sono inversamente proporzionali. Allora se non sto attento vado in loop e non capisco
che sta succedendo.
Quando sono poche la variabili in gioco, posso usare degli istogrammi multi-parametrici che mi aiutano a capire se
queste grandezze sono molto correlate oppure no. Faremo dei test visivi, quindi valutazioni ad occhio, e ciò che faremo
deve essere robusto al test visivo. I test parametrici che faremo sono robusti ai test visivi. Perché i test parametrici?
Perché dal test visivo io devo già sapere come sta andando.
Ovviamente dalla prossima lezione i problemi si complicheranno e dovrò capire come ridurre il dataset che è fatto di
dimensioni e punti. Devo fare una riduzione dimensionale e una riduzione puntuale.

LEZIONE 6 8/10/21
Abbiamo visto le caratteristiche di un workload e abbiamo visto le caratteristiche statiche e dinamiche, in particolare
entrando nel problema abbiamo parlato della media; e come possa essere un modello statistico del mio workload.
Quando però approssimiamo un insieme di punti in uno solo dobbiamo sempre controllare l’errore o, meglio la varianza
per capire quanto sbaglio nel rappresentare un insieme di punti con un solo punto.
Questo lo possiamo capire da un istogramma a singolo parametro che mi dice la frequenza di occorrenza di un range di
valori nel nostro campione. Posso rappresentare il nostro campione con i punti più probabili e sebbene abbiamo detto
che è poco usato per la presenza di correlazioni, anche qui l’errore che commetto nello stimare il mio dataset con pochi
punti è sempre dato dalla somma dei suoi quadrati normalizzata per il numero di campioni.
Quindi quello che vogliamo fare è rappresentare il nostro dataset con un numero minore di punti che in qualche modo
riescano a portarsi quasi tutta la varianza del nostro valore iniziale. Questo è il nostro obiettivo
Più la varianza è alta più è alto l’errore. Quando ho fatto un buon modello? Quando ho ridotto il numero di punti
portando quasi tutta la varianza dentro il modello, quello che mi interessa, soprattutto nella performance analysis, è
avere modelli del dataset che contengono la maggioranza della varianza del mio dataset iniziale.
Supponiamo di misurare dei tempi di risposta in un web server e che lo facciamo per due anni. Per ridurre da 70k a 4k i
dati ottenuti che criterio utilizziamo? Cerco una riduzione del mio dataset che massimizza la varianza che si porta dentro.
Qual è il miglior criterio per fare ciò? Scegliere i punti in modo tale da massimizzare la varianza in modo da portarla tutta
dentro. Esercizi che faremo (già da lunedì) con dataset da 30000 lo rappresentiamo con 6 punti portando quasi il 90%
della varianza.
Se le cose sono semplici posso usare gli istogrammi a un parametro o più parametri. A più parametri devo stare attento
perché ci sono sempre delle correlazioni tra i dati ed è difficile trovare relazioni non lineari, a meno che non studio il
consumo energetico e a meno che il consumo energetico porti a prestazioni non lineari. Tipicamente le relazioni sono
lineari e quindi ci sono molte correlazioni.

PRINCIPAL COMPONENT ANALYSIS (PCA)

È la tecnica più utilizzata per classificare le componenti di un workload. L’idea di base è quella di usare una somma
pesata dei parametri per classificare i componenti. La PCA è una tecnica di riduzione della dimensionalità del problema.
In particolare, date le variabili del workload, l’idea di base è di individuare nuove componenti indipendenti tra loro
(quindi incorrelate) attraverso una trasformazione di stato e ordinandole da quella che esprime più variabilità, a quella
che esprime meno variabilità.
Perché ci serve questa trasformazione? Perché riusciamo a capire quali e quante sono le componenti con la quale
ridurre la dimensionalità del problema tenendo traccia della varianza persa.
Tipicamente il numero di componenti principali è minore o uguale alla dimensionalità del problema ma in alcuni casi:

• A parità di varianza, se il numero di componenti è inferiore al numero delle variabili allora c’erano delle variabili
costanti e quindi hanno variabilità nulla.

• Se il numero di componenti è pari al numero di variabili allora i dati variano su ogni dimensione.
Immaginiamo di avere un certo numero di parametri del workload 𝑥𝑖𝑗 dove 𝑖𝑡ℎ è la dimensione per il 𝑗𝑡ℎ componente
(quindi sui dati abbiamo riga e colonna) e 𝑤𝑖𝑗 è il peso.

fattore principale = 𝑦𝑗 = ∑ 𝑤𝑖𝑗 ∗ 𝑥𝑖𝑗

𝑖=1𝑛

Pensiamo ad una matrice dove le colonne sono le dimensioni e tutti i dati che prendo sono le righe, l’idea è costruire
delle combinazioni lineari degli 𝑥𝑖 .
Questa tecnica non fa altro che una trasformazione dello spazio di stato. Prende i parametri del workload e li riporta
in uno stato in cui la matrice che genera tale stato è una matrice di correlazione. I nuovi componenti sono incorrelati e
li posso ordinare secondo un criterio di varia; quindi, il primo avrà una varianza maggiore dei successivi e così via.
Come discrimino i parametri del workload? La trasformazione di stato tra 𝑥 e 𝑦 mi deve portare a dei fattori che sono:

• Linearmente indipendenti.

• I nuovi punti 𝑦1 , 𝑦2 , … , 𝑦𝑛 devono essere ordinati secondo la varianza spiegata.

Allora: le 𝑦 sono combinazioni lineari di 𝑥 e sono tra di loro linearmente indipendenti formando uno spazio ortogonale
(prodotto interno è zero) e questa tecnica, scegliendo opportunamente la matrice delle equazioni caratteristiche,
ordinando le soluzioni fa sì che le 𝑦 che vengono fuori siano ordinate secondo la varianza spiegata.
Se ho una varianza iniziale da dei punti dello spazio anche se cambio lo spazio la variabilità non cambia. Se sommo tutta
la variabilità del dataset iniziale ho che nel nuovo dataset trasformato, poiché Y sono incorrelati, la varianza è allocata
sui vari 𝑦1 , 𝑦2 , … , 𝑦𝑛 in maniera decrescente.
Quindi riduco e controllo l’errore, ma perché? Andremo nei dettagli della tecnica. Con la PCA si PUÒ ridurre ma in realtà
TRASFORMA lo spazio di stato.

Trovare i fattori principali

Come si trovano i fattori principali? Abbiamo detto che la PCA è una trasformazione di stato per prima cosa troviamo la
matrice di correlazione (matrice di covarianza), per fare la trasformazione di stato devo trovare gli autovalori della
matrice e li ordino in ordine decrescente per varianza ed infine trovo gli autovettori corrispondenti.
Vediamo un esempio:
Supponiamo di avere pacchetti inviati 𝑥𝑠 e ricevuti 𝑥𝑟 . Ho 18 osservazioni totali in cui invio il pacchetto e vedo se lo
ricevo. Nella prima sessione invio 7718 e ne ricevo 7258 e così via. Ad esempio, alla ottava ho 6527 inviati e 4850 ricevuti.
Come si prosegue quando dobbiamo fare comparazioni statistiche? Si usa normalizzare il dataset, tipicamente si usa la
normalizzazione a media nulla e a varianza unitaria.
La PCA non si fa sul campione così com’è ma per poter operare devo sempre procedere ad una normalizzazione. Ci
sono vari tipi di normalizzazione e ne vedremo diversi ma quando voglio, in qualche modo, fare comparazioni a livello
statistico devo fare una normalizzazione che si chiama Z-Score ovvero riduco le mie serie temporali in serie con
media nulla e varianza unitaria.

Se ci dimentichiamo di farlo sbagliamo. I tool in genere normalizzano in automatico e non devo farlo a mano.
Dopo di che da questo vengono calcolati i fattori principali, che in questo caso sono due:
 • 𝑥′𝑠
• 𝑥′𝑟
Il mio dataset è di 2 dimensioni per 18 osservazioni e quindi 36 punti. La mia trasformazione finale qual è? 2 Dimensioni
(pacchetti inviati e ricevuti) linearmente indipendenti 𝑦1 e 𝑦2 con 18 punti.
La tecnica in sé NON RIDUCE ma TRASFORMA, sono sempre a media nulla ma non a varianza unitaria e non sono più
normalizzati. Abbiamo dunque un nuovo dataset sul quale ragionare.
1. Calcoliamo la media e la deviazione standard delle variabili:
𝑛
1 96336
𝑥̅𝑠 = ∑ 𝑥𝑠𝑖 = = 5352
𝑛 18
𝑖=1
𝑛
1 88009
𝑥̅𝑟 = ∑ 𝑥𝑟𝑖 = = 4889.4
𝑛 18
𝑖=1
𝑛 𝑛
1 1 (567119488 − 18 ∗ 53532 )
𝑠𝑥2𝑠 = ∑(𝑥𝑠𝑖 − 𝑥̅𝑠 )2 = [∑(𝑥𝑠𝑖 )2 − 𝑛 ∗ 𝑥̅𝑠2 ] = = 1741.02
𝑛−1 𝑛−1 17
𝑖=1 𝑖=1

(462661024 − 18 ∗ 4889.42 )
𝑠𝑥2𝑟 = = 1379.52
17

Normalizzazione (Z-scores)
La matrice di correlazione la costruisco partendo dalla costruzione delle correlazioni della variabile uno con la due, la
uno con sé stessa e due con uno (ottenendo una matrice diagonale). Poi normalizza i dati e per le analisi statistiche ho
detto che uso lo Z-score. Questa normalizzazione trasforma una serie temporale in una serie a media nulla e varianza
unitaria e serve per capire se ogni valore è sopra o sotto la media per questo è chiamato Z-SCORE. I valori segnati
nell’immagine mi mostrano il valore rispetto alla media

Lo Z-score mi dà come prima informazione visiva quanto un campione si scosta dalla media ed in più posso subito, anche
visivamente, confrontare la nostra serie con una distribuzione normale.
Col teorema del limite centrale si dimostra che la varianza campionaria è una normale. La Z-score mi dice subito se può
essere una normale oppure no. Se plotto e faccio la normale è ancora più evidente.
2. Come faccio la Z score? Ogni 𝑥′𝑠 è dato da 𝑥𝑠 meno la sua media, diviso la deviazione standard
𝑥𝑠 − 𝑥̅𝑠 𝑥𝑠 − 5352
𝑥′𝑠 = =
𝑠𝑥𝑠 1741
𝑥𝑟 − 𝑥̅𝑟 𝑥𝑟 − 4889
𝑥′𝑟 = =
𝑠𝑥𝑟 1380

Per costruzione ottengo una serie temporale 𝑥 ′ a media nulla e varianza unitaria. Ha dei problemi questa
distribuzione? Per analisi statistica va benissimo ma non è robusta in outlayer; infatti, se ho valori superiori alla
media non li taglia e li tiene dentro e può essere sconvenitene se sto facendo analisi di dati e sono fuori soglia perché
ci sono errori o affetti di rumore. In alcune applicazioni come multimediali o nel sequenziamento dei genomi, un
outlayer può essere un errore nelle nostre applicazioni, noi di solito dobbiamo capire che è un outlayer perché può
essere un qualcosa di importante. Nell’esempio mostrato forse l’osservazione numero 18 che presenta 2020 dati
inviati e ricevuto 2946, quindi c’è qualcosa che non va.
Vedremo poi altre forme di normalizzazione poiché siamo noi che dobbiamo decidere, in analisi dei dati, come devo
normalizzare. Questo perché siamo noi a sapere da dove derivano questi dati, è come a data mining quando vediamo
che la prima fase è estrarre le feature dai dati. Devo prendere i dati da sorgenti diverse e li devo filtrare perché devo
eliminare quello che non serve e devo poi ridurre tutto ad uno stesso formato. Questo lo vedremo anche in questo corso
perché vediamo anche analisi di dati di fallimento.
Per ogni sorgente posso anche applicare normalizzazioni diverse, dipende ovviamente dai dati e dalla sorgente stessa,
è impossibile dare una regola che vale per tutto.
Se devo fare STATISTICA uso la Z-score.

Matrice di Correlazione
1. Relativamente alla creazione si prepara la matrice di correlazione e si risolve l’equazione caratteristica,
troviamo autovalori e facciamo la trasformazione di stato. Quindi calcoliamo la correlazione tra le variabili:
1 𝑛
∑𝑖=1(𝑥𝑠𝑖 − 𝑥̅𝑠 )(𝑥𝑟𝑖 − 𝑥̅𝑟 )
𝑅𝑥𝑠,𝑥𝑟 = 𝑛 = 0.916
𝑠𝑥𝑠 𝑠𝑥𝑟

2. Preparare la matrice di correlazione vuol dire scrivere:

1.000 0.916
𝐶= [ ]
0.916 1.000
3. Calcolare gli autovalori della corrispondente matrice attraverso l’equazione caratteristica:

|𝜆𝐼 − 𝐶| = [𝜆 − 1.000 −0.916

]=0
−0.916 𝜆 − 1.000
(𝜆 − 1)2 − 0.9162 = 0
Abbiamo dunque che gli autovalori sono 1.916 e 0.084.
L’equazione caratteristica non ha solo N soluzioni, ma uso quelle che minimizzano la varianza così che possa poi
ordinare i fattori della varianza spiegata.
4. Calcolare gli autovettori della matrice di correlazione. Gli autovettori 𝑞1 corrispondono all’autovalore 𝜆1 =
1.916 e sono definiti dalla seguente relazione:
𝐶 ∗ 𝑞1 = 𝜆1 ∗ 𝑞1
1.000 0.916 𝑞11 𝑞11
[ ] × [𝑞 ] = 1.916 [𝑞 ]
0.916 1.000 21 21

5. Restringiamo la lunghezza degli autovettori a 1, i due autovettori diventano:

 1 1

𝒒𝟏 = √2 𝒒𝟐 = √2
1 1
−
[√2] [ √2]
6. I fattori principali si ottengono moltiplicando gli autovettori per i vettori normalizzati:
1 1 𝑥𝑠 − 5352
𝑦1
[𝑦 ] = √1
2 √2 [ 1741 ]
2 1 𝑥 − 4889𝑟
−
[√2 √2] 1380
“i calcoli non mi interessano, mi interessa la tecnica” (e io ci credo)
Il risultato finale è che i 18 punti sono mostrati nello spazio di stato.
La figura qui di sotto mette in relazione su un grafico il fattore 1 con il fattore 2 (i punti indicano i valori come variano).
Cosa si osserva? I punti si muovono quasi tutti sulla stessa linea (quella orizzontale) e ciò significa che varia poco la
componente principale 2, e varia molto la componente principale 1 (alta variabilità ).

Di cosa mi accorgo? Che i punti variano poco rispetto alle Y e variano molto lungo le X. Quindi dipendono dal primo
32.565
fattore 𝑦1 poiché corrispondono a = 95,7% della varianza; mentre il secondo 𝑦2 corrisponde al 4,3% della
32.565+1.435
varianza. Quindi abbiamo ridotto lo spazio dei dati.

Loading Plot
Non tutti i tool danno in uscita il loading plot ed esso mi dice qual è la proiezione di un certo autovettore sul nuovo
spazio fatta dalle due componenti. Packet send e recived variano poco sull’asse del secondo componente e hanno quasi
la stessa proiezione sul primo componente. Più vicine sono le frecce più sono correlate le grandezze.
Cosa concludiamo applicando questa tecnica? Se il primo componente spiega il 95.7 e il secondo spiega poco, posso
ridurre allora il dataset a solo 18 componenti invece di 36 perché scarto tutta la seconda componente che ha una
varianza veramente bassa.

In questo caso didattico il gioco è già finito. Di questa componente principale posso caratterizzare e dividere in 3 fasce
con WORKLOAD ALTO/MEDIO/BASSO.
Come lo faccio? In questo modo, torno alla tabella con tutti i valori, prendo solo il primo fattore 𝑦1 e questo è ora il mio
dataset. Ho il mio dataset e posso a mente capire che valori molto vicini tra loro possono essere relativi ad una fascia di
workload alto, ad esempio i primi quattro valori. Quelli con lo 0.xxx sono workload medio e quelli sotto la media sono
un workload basso.
Quale è il workload caratterizzato? Posso scegliere un punto, dalle tre fasce di workload, e ho i corrispettivi valori nella
prima colonna con le variabili 𝑥𝑠 e 𝑥𝑟 e riduco da 36 a 18 e poi da 18 a 3 punti (nello specifico il 2/8/17) e mi porto
dentro la mia varianza del 95.7.
Ha aperto JMP con il problema CPU-JMP dell’ateneo dell’altra volta
Tengo 6 dimensioni e 147 righe pari a 882 punti
La prima colonna è un time stamp le altre sono nodi di elaborazione. Applichiamo la PCA.
Ho 6 componenti principali e posso scegliere se farlo sulle correlazioni o sulla covarianza. È difficile trovare casi in cui va
bene l’uno o l’altro, va quasi sempre bene con le correlazioni. È possibile sia mostrare gli autovettori e posso anche
stampare gli autovalori.

Ci tiene agli autovettori e autovalori, sugli autovalori mi dice le 6 dimensioni e mi dice per ognuno di quei valori quanta
varianza spiega attraverso la percentuale cumulativa. Le cose nei nostri esercizi non sono così belle e ho le ultime
componenti che hanno una varianza non apprezzabili e quindi c’è forte correlazione tra i parametri. Ricordiamo che
una colonna costante ha varianza zero.
Le linee più grigie o scure sono per il contributo diverso delle dimensioni degli autovettori.
Sul loading plot vedo un anomalia sulla UgovOne poiché è lontana dalle altre. Le altre più o meno sono lì anche se non
è il massimo. Come riduco questo dataset? Devo scegliere una componente principale.
A sinistra, vedendo i punti sparsi in basso, mi fanno pensare che ci potrebbero essere degli outlayer; se escludo degli
outlayer aumento di molto la varianza spiegata.
Prendere o no gli outlayer, e capire che sono dipende tutto da quanto mi pagano.
Scegliamo quanti componenti principali usare, c’è chi dice prendi il 95% chi dice prendi 86% chi prendi altro. La risposta
giusta non c’è ma è un trade off devo vedere la sensitività delle componenti principali ai cluster.
Supponiamo di voler prendere 1 con il 75% e me la trovo poi nel tabellone sopra e riduco da 6 DIMENSIONI a 1
DIMENSIONE e quindi ho un dataset con solo 147 punti. Ce lo studiamo e vediamo la distribuzione, sempre stesso
attraverso JMP.
Passando nuovamente ad un numero minore di punti, nel caso 6 punti. E questo visto è un caso reale dove manteniamo
ancora una varianza del 75%.
Che succede se decido di prendere 3 componenti e quindi il 91.761%?
Ora ho la metà del workload ma come faccio a prenderlo? Come procedo? Faccio clustering, cerco di raggruppare punti
simili in maniera tale da ridurre queste colonne ed avere pochi punti. Ma anche con il clustering perdo varianza, lo
facciamo non per Image Recognition ma per capire quanti oggetti sono simili e quanta varianza perdo quando gli
oggetti sono simili. Non ci sono algoritmi di ottimo, siamo in un problema dove devo guardare al budget.
Abbiamo visto che la PCA è una tecnica di riduzione della dimensionalità del problema. Ad esempio, in figura abbiamo
punti su tre dimensioni (ma possiamo avere in generale, nei casi più complessi, anche punti su n dimensioni) e attraverso
la PCA (che consiste in una trasformazione di stato) otteniamo un numero di componenti principali ≤ della
dimensionalità. Con la PCA si riduce, quindi, il dataset di partenza e si conserva, allo stesso tempo la maggior parte della
varianza (o variabilità) dei dati. In figura abbiamo ridotto una dimensione. Tuttavia, c’è ancora un problema
fondamentale: abbiamo comunque, nello spazio, tutti i data-points di partenza, che non vengono ridotti, occorrono
dunque tecniche di compressione.
Clustering
Il clustering indica degli algoritmi che tentano di accorpare oggetti simili, ovvero in base ad una funzione di
similarità/dissimilarità cerca di accorpare gli oggetti.

Con il clustering devo definire una funzione di similarità che può essere di vario tipo. Se voglio accorpare punti vicini tra
di loro accorpo punti che hanno una varianza minima e quindi devo capire quale tecnica di cluster usa la varianza
minima. Purtroppo, la varianza non è una distanza perché non verifica la disuguaglianza triangolare.
Tutto dipende anche dallo spazio in cui rappresento i punti, per questo si usa PCA e poi il Clustering. Devo studiare
queste tecniche e lo faremo nella PERFORMANCE ANALYSIS. Noi vedremo una declinazione delle tecniche di clustering
in questo specifico contesto.

CLUSTERING IN PERFORMANCE ANALYSIS

Poiché un workload consiste in un grande numero di componenti, è utile classificare gli stessi attraverso un piccolo
numero di classi (cluster). Un singolo membro di ogni cluster può essere selezionato per rappresentare la classe e
divenire l’oggetto di studio per i suoi effetti sulle performance. Che vuol dire fare clustering di performance analysis?

Supponiamo di graficare 30 JOB in un sistema come quelli visti prima e voglio caprie quali sono i JOB più rappresentativi
in termini di Uso di CPU e di DISCO. In questa immagine abbiamo che appena solo 5 JOB possono essere usati per
rappresentare l’uso medio delle risorse chiesto da ogni cluster.
Posso clusterizzare i miei dati e se clusterizzo devo fare delle considerazioni. Ci sono dei punti strani in alto a dx, sono
degli outlayer? Si ho degli outlayer perché sono indici di alto stress di sistema. Che faccio li levo o no? NO, LI DEVO
ESAMINARE. L’outlayer in alto a dx può essere indicativo di un punto di lavoro del sistema.
LEZIONE 7 11/10/2021 – ESERCITAZIONE SUL CAPACITY
TEST CON ING. LIGUORI (WebServer_1.pdf)
Questa lezione e il set up saranno fondamentali anche per tutte le successive esercitazioni e per l’esame. L’obiettivo di
oggi è quello di essere in grado di mettere il client in condizione di fare una serie di richieste verso un server al fine di
stressarlo e capire le condizioni limite del server.
Gli strumenti necessari sono:
• Apache web server, tipico web server contenente le risorse di cui abbiamo bisogno
• Generatore di carico dal lato client:
o Usiamo Apache JMeter
o Httperf
• Macchina Linux, sia fisica che virtualizzata

• Collezione di dati basso livello.

• Non siamo per forza di cose legati ad utilizzarli o ad usare le sue configurazioni, posso anche usare un server
che ho a casa o altro.

Useremo una VM con Apache e la nostra macchina come Client.

Uso un ambiente virtuale, e proprio perché si utilizza tale condizione, mi devo ricordare di sistemare delle cose nelle
impostazioni della rete della macchina per far sì che essa sia raggiungibile dal mio host (cioè da quello che è il client).
Devo aggiungere un adattatore di rete nella macchina virtuale per mettere in comunicazione l’host con la macchina
virtuale che ho creato.
Se ho una macchina virtuale aggiungo un network adapter e devo poi ricordare di controllare gli IP per vedere che
effettivamente esisto sulla rete, normalmente su linux usiamo il comando “ifconfig”.

Questo indirizzo qua mi servirà, poi lo posso rendere statico ma ogni SO ha le sue modalità. Posso usare qualsiasi SO
come sistema Server, non per forza ubuntu.
Fatto questo, devo salvare l’IP perché quando uso il LOAD GENERATOR (Apache JMeter) ci serve questo IP per
raggiungere il server. In questa guida con Apache web server, devo installarlo con un $ 𝑠𝑢𝑑𝑜 𝑎𝑝𝑡 −
𝑔𝑒𝑡 𝑖𝑛𝑠𝑡𝑎𝑙𝑙 𝑎𝑝𝑎𝑐ℎ𝑒2 su un debian based, se uso un altro SO devo vedere un attimo.
I comandi principali di questo web server sono:
• $ service apache2 start

• $ service apache2 stop

Un test che posso fare è andare sulla macchina host, inserire l’indirizzo IP sul browser e vedere se mi esce il localhost di
apache2.
Il path di default di apache, sul server, è: /var/www/html/index.html che è il luogo in cui inserisco le risorse che voglio
richiedere dal load generator.

JMETER
È il nostro Load Generator e con questa applicazione andiamo a richiedere le risorse che abbiamo inserito in questa
directory. Quando vado a scaricare questo JMeter devo scegliere la versione binaria.

Se mi trovo nella mia home directory, apache JMeter richiede l’installazione di Java8. Bisogna installare anche la
Java Runtime Environment. Una volta che tutto è pronto è possibile lanciare JMeter sia tramite jmeter.sh, tramite
linea di comando, sia tramite jmeter.bat
Ora inizia la parte un poco più interessante in cui vado a configurare il mio piano di test, che fa riferimento al client.
Apache JMeter è completo e ha una serie di features però noi vediamo solo quelle che ci servono per le esercitazioni.

Elementi principali di un Test Plan

• La prima feature utile è il threadGroup, per thread intendiamo gli utenti virtuali che effettuano richieste alle
risorse del server. Setto quindi il numero di utenti virtuali che fanno le richieste, il Ramp Up period e il
numero di volte in cui vogliamo eseguire il test (Loop Count).
Il ramp up period è il tempo di attivazione dell’ultimo thread, ad esempio supponiamo di avere 10 thread e un Ramp
Up period di 10 secondi questo vuol dire che ogni secondo un thread viene attivato fino a quando non arriviamo a 10
thread attivati.
L’ultima feature è il numero di volte da eseguire il test, in realtà è più il numero di volte che ogni utente deve essere
attivato. Se metto 5 e ho 10 utenti in realtà farà 50 richieste.

Questa è la schermata per il thread group in cui posso settare il tutto. In thread properties, all’opzione Loop Count,
posso mettere la spunta su forever in modo da lavorare fino ad un segnale di stop.
Scheduler invece ci permette di configurare il nostro test in modo da dare una finestra temporale del test, in secondi.
 • Abbiamo poi il Sampler (campionatori), se prendo il thread group di prima faccio: Tasto destro su Test Plan,
aggiungo i thread group, su questo thread aggiungo i campionatori http Request.

Nelle richieste http andremo a specificare una serie di informazioni e la più importante è il nome del server o l’IP del
server, ovviamente non dovrò far altro che mettere l’indirizzo IP del server per fare le richieste.

Il path mi identifica invece il nome della risorsa. Se la risorsa è nel path di default (quella cerchiata nelle slide
precedenti), devo mettere solo il nome della risorsa. Se il path cambia devo mettere ovviamente tutto il path e non
più solo il nome della richiesta. Poi va messo porta 80 e method GET, queste sono le informazioni che devo inserire. Ad
ogni risorsa corrisponde una http request.
Supponiamo di avere dieci risorse sul nostro server. Cosa succede? Per evitare di mettere ogni volta informazioni sul
server posso usare un CONFIG element, da aggiungere come abbiamo fatto per la http request, e c’è la voce http request
default. Questa pagina che fa? Mi fa specificare l’indirizzo del server dove accedere, aggiungo il protocollo di default, il
numero di porto 80 e il path lo lascio vuoto. Il path lo vado a specificare nell’http request.
Posso creare http request e usare i campionatori senza config element. Se uso un CONFIG ELEMENT nell’http request
non devo specificare l’IP del server.
Quindi con il Config element, se il client va sempre allo stesso server, mi tolgo la scocciatura di specificare l’IP con il
sampler.

• Controllers (controllori)
Andiamo a vedere ciò che serve per rendere il nostro test più vicino al caso d’uso reale. Useremo i logic controller e in
particolare il random controller, che ci permette di aggiungere variabilità nelle nostre richieste.

Supponiamo che abbia 10 utenti e 5 http request diverse, se non uso un random controller ogni volta che un tread viene
attivato richiede le risorse in maniera predicibile. Ad esempio, con 5 request statiche e fisse ho un comportamento che
non è di un utente. Come server non so a priori che risorse mi chiederà un utente. Usando un random controller posso
creare un caso di test più realistico. Perché? Perché con il random controller, ogni volta che vengo attivato, ho le mie
request, faccio solo una richiesta delle cinque fatte in precedenza ma in maniera non ordinata, ed essendo l’ordine e il
tipo di richieste randomico ho che il comportamento è non predicibile.
Se uso un random order controller, invece di un random controller, avrei che quando sono attivato faccio tutte le
richieste ma in ordine non prefissato. Questo perché, ripetiamo, nel random controller io faccio una sola operazione
ogni volta che viene attivato, mentre l’order le fa tutte.

• Timer
È l’altro elemento fondamentale ed è importantissimo per la prima esercitazione, si trova nella categoria dei timer e
sta nella Constant Throughput Timer (CTT) e mi dà il numero di richieste al secondo o al minuto che ogni singolo thread,
o tutti i thread, può fare. Quello che ottengo è quindi il rate delle richieste
Se metto questo valore basso, sto dicendo che devo fare poche richieste. Se è alto posso fare richieste molto più veloci.
Spesso capita che non si noti la differenza tra 100.000 e 1 milione di richieste al secondo, potremmo ipotizzare che il
problema sia il server, ma è molto probabile che sia il client a non essere in grado di soddisfare la richiesta.

Abbiamo la possibilità di specificare il numero di richieste che devono fare o il singolo thread o tutti, per farlo vediamo
questa finestra aperta. Se vogliamo visualizzare per il singolo thread mettiamo “this thread only”.

• Listners
Sono coloro che ci consentono di ottenere l’output dei test, ci sono tantissimi listner che possiamo utilizzare e li vediamo
come abbiamo fatto finora con gli altri. Tra le informazioni più importanti ho i tempi di risposta, ad esempio i tempi di
risposta medi, il throughput, il numero di errori (sono tutte metriche che esplicheremo anche più avanti).
Si aggiungono sempre con il tasto destro.
Supponiamo il caso dell’esempio sopra attraverso il summary Report.

Ho un aggregato di tutte le richieste di tipo A e mi dà il numero di campioni, la media per eseguire la richiesta, il tempo
minimo e massimo. La deviazione standard, la percentuale di errore, il numero di richieste servite al secondo per questo
tipo di richiesta il KB/Sec e la media dei bytes.
Per ogni richiesta ho le informazioni per singola pagina e alla fine tutto il server che è la TOTAL che mi serve più delle
altre

HTTPREF
È un altro tool da riga di comando, usiamolo se vogliamo ma lui si focalizzerà su JMETER. Sulle slide dell’esercitazione
c’è un esempio

Parameters Collection – Alto livello

Per capire che succede in queste esercitazioni devo collezionare dei parametri, ho due tipi di parametri:

• Parametri di alto livello

• Parametri di basso livello
I parametri di alto livello sono tutti i parametri che collezioniamo lato client. Quale modo ho io client per valutare le
prestazioni? Come so se il server mi serve bene?
Prendo i miei listner e li setto su dei parametri del server come il tempo di risposta; oppure faccio 100 richieste, 80 le fa
e 20 no, il throughput (numero di richieste al secondo). Tutti questi parametri li posso mettere lato client. Come posso
collezionare tutti i parametri di alto livello?

Tutti i listner che abbiamo consumano memoria. Se vogliamo automatizzare il test e vogliamo far sì che il mio client
faccia solo richieste, non vogliamo che la mia memoria sia consumata e per collezionare i parametri uso il simple data
writer. È un tipo di listner che una volta aggiunto mi fa specificare il NOME DEL FILE (consiglia il formato CSV) e mi
permette di configurare cosa voglio salvare per ogni singola richiesta fatta dal client.
Prima ho visto un altro listner che era il summary report che però non mi fa vedere ogni singola richiesta, ma fornisce
un aggregato del tipo di richiesta. Il simple data writer mi fornisce un CSV non sommario ma con ogni singola richiesta
e quindi tornerà molto utile per la workload characterization.
Queste sono singole informazioni di alto livello che possiamo selezionare con il configure e sono di default:

ELASPSED time vs LATENCY

Il tempo di risposta lo definiamo come il tempo di ricezione di una risposta a seguito di una richiesta, ma
quest’intervallo varia sempre in base a ciò che deve arrivare. Mentre latency è visto come: client che manda la
richiesta, questa arriva al server e appena la sta per servire stacco il conteggio del tempo.
Elapsed ovviamente contiene la Latency

Da oggi quando dice tempo di risposta si riferisce ad elapsed, perché mi interessa sapere anche se il server è in
grado di processare la richiesta in tempi ragionevoli.
In base a questa definizione vediamo ora come cambia anche la concezione di pagine SMALL; MEDIUM E LARGE.
Sull’asse delle X ho i time stamp nel quale viene richiesta la pagina e sulle Y ho i tempi di risposta. Vedo le small in
basso le medium al centro e le large in alto questo perché quando richiedo una risorsa di grosse dimensioni ho che Il
tempo di risposta, con elapsed, è correlato alla dimensione.
La linea nera è la media.
Con la latency questo fenomeno non avviene perché io mi fermo quando ricevo la richiesta non vedo se la porto a
termine.
L’ultima cosa prima dei parametri di basso livello è che prima ho detto che il throughput non è collezionabile con il
data writer, ma a me serve per fare capacity test perché ci servono due informazioni:
• Tempi di risposta

• Throughtput
Per calcolare la latency media vado su excel, prendo la colonna latency e tiro fuori la media ma non ho informazioni
sul throughput.
Come calcolo il throughput su un file excel (simple data writer) se non c’è?
1. Ordino tutte le richieste per timestamp dal più piccolo al più grande
2. Faccio la differenza tra l’ultima richiesta e la prima e ho così il tempo per cui ho eseguito il test
3. Passo questo tempo da millisecondi a secondi
4. Il throughput sono il numero di richieste effettuate al secondo.
Se faccio 99 richieste/tempo di test == throughput al secondo!
Non esiste un altro listner che ci da queste informazioni? Il summary report mi dà una informazione aggregata di tutto
ciò che sta accadendo, ma il capacity test non è così facile da fare. Le informazioni sul carico così dettagliate il
summary report non me le dà, so solo quante richieste al secondo riesco a servire. Se ad esempio ho posto mille
richieste al secondo e il throughput è di 500 richieste al secondo, possiamo pensare che 500 so servite e 500 no, in
realtà non so quante ne sto facendo perché non ho l’informazione! Potrebbe essere il server saturato o il client etc.
IL THROUGHPUT VA CALCOLATO SULLE RICHIESTE CORRETTE! SE VIENE RESTITUITO UN ERRORE (CODICE 200/2XX DI
http) NON MI INTERESSA. SE MI INIZIA A DARE ERRORE E NON RESTITUISCE LE RICHIESTE CORRETTAMENTE CI
FERMIAMO
Finora abbiamo visto i parametri alto livello lato client, lato server invece?

Parameters Collection – Basso livello

Con quelli di alto livello ho visto che succede lato client, ma non so mai che sta passando il server, o almeno legalmente
non può. Allora devo mettere un monitoraggio lato server e per collezionare i parametri di basso livello mi serve
qualcosa che monitora il server.
Un esempio è VMstat (virtual memory statistics) che mi dà info sulla memoria, processi Io, pagine swapped, etc.…
Apro il terminale sul server faccio vmstat e mi esce la prima riga, ovviamente non me ne serve solo una ma uno per
ogni test. Per richiedere tutti i test uso -n che richiede due parametri:
1. Tempo di campionamento
2. Totale di righe da mostrare
Questa informazione serve per le varie esercitazioni non per la prima di capacity test. Di seguito tutte le possibili
informazioni collezionabili con vmstat

CAPACITY TEST AND PERFORMANCE(Workload) CHARACTERIZATION – homework n°2

Fare il capacity test significa caratterizzare le performance del sistema nel caso limite. Sapere qual è il limite del mio
test mi fa capire dove mi posso spingere, ad esempio se studio gli acquisti degli utenti posso fare un tuning del sistema
nei periodi di acquisti maggiore. Sapere quante richieste riesco a gestire è quello che serve nel capacity test. Quando
parlo di performance a cosa facciamo riferimento? Ai tempi di risposta al throughput etc.
Il tempo di risposta è il tempo che intercorre tra l’invio di una richiesta e il tempo per rispondere. Se includo il servire
la richiesta parlo di elapsed, se solo l’accettazione della richiesta è latency. In genere il tempo di risposta è elapsed. I
tempi di risposta crescono con il carico del sistema, se faccio 10 richieste al secondo o 10000 di richieste al secondo
non può mai essere che con 10000 ho tempi minori di 10. Se succede sto sbagliando a fare qualcosa.
Throughput voglio capire questo server che limite ha e cosa riesce a gestire. Lo capisco con questa misura, ma devono
essere richieste servite correttamente, se inizio ad avere richieste servite con errore allora devo fermarmi perché già
sono andato oltre i limiti del server.
Il throughput cresce linearmente con il carico, quando sono poche.
C’è una crescita lineare con il carico e poi inizia a non crescere più linearmente e si assesta perché se il limite del
server è fare 500 richieste al secondo, pure se gliene imposto 1000 lui sempre 500 ne fa.
Può anche succedere che il throughput caschi e capita quando sto buttando giù il server. Se il client riesce a fare
1000 richieste al secondo ma il throughput è 500 il server è caduto molto probabilmente.

Il capacity test è una cosa lunga da fare, ma facile. Devo raccogliere il response time e il throguhput. Con JMETER che
componente uso, come gli impongo il carico? Il CTT che mi fa imporre il carico al sistema, un errore comune è che il
carico non è il throughput.
Il carico è una cosa e il throughput è un'altra. Il carico imposto al sistema sono le richieste che il client fa al secondo o
al minuto, il carico è del client, il throughput sono le richieste che il server riesce a gestire.
Il tempo di risposta cresce con il carico.
Il throughput cresce con il carico e a un certo punto si stabilizza e poi può anche cadere se il server cade.
Tutto quello che è stato detto prima, come problematiche si ritrova nel grafico.
Dobbiamo applicare un carico che varia per graficare le due curve, ma perché devo graficare proprio questi due test?
Perché il capacity test si chiama così perché devo misurare la capacità.
• La capacità nominale è il max throughput ottenibile dal sistema in condizioni ideali; ideale vuol dire che lo
calcolo con modelli matematici o analitici ma non posso mai averlo nella realtà.
Quando all’esame dice perché non ci sta la capacità nominale? Perché non la posso mai portare. La posso vedere solo
con modelli analitici.

• La Usable capacity è il max throughput che riesco ad ottenere in prefissati tempi di risposta. Se mi prefisso
che il sistema ha massimo cinque minuti per servire una richiesta e mi calcolo il max throughput, esso è il mio
usable capacity. Perché il punto di Usable non è un punto di ottimo? Perché è un caso limite e quindi non ha
senso metterlo in esercizio in una situazione simile.
• La Knee capacity è il punto prima del quale il throughput cresce linearmente, e dopo il quale può crescere o
no ma in maniera non lineare.
Trovare il punto di knee capacity non è facile! Allora in nostro aiuto viene la potenza. Nella performance analysis la
potenza è il rapporto tra throughput e tempo di risposta.

Dove trovo il punto di knee? Al picco della potenza (graficamente)

Ricordiamo che l’elaborato va portato all’esame e consiste nel creare il server (o usarne uno già in uso), fare richieste
con il mio client e ho bisogno di un load generator. Come load generator usiamo apache JMeter o un altro a piacere e
dobbiamo costruire questi tre grafici.
Per effettuare il capacity test dobbiamo scegliere una configurazione di test plan, devo far cambiare il carico e vedere
come varia il tutto. Tutti i risultati, con il simple data writer, li metto su un CSV e ora da un carico X1 e un carico X2
non deve variare nulla se non il carico stesso!
Per ogni carico imposto, nel CTT, non devo prendere una sola misurazione, perché? Perché quando faccio il design of
experiment, l’errore è una componente fondamentale. Ogni volta che faccio una misurazione commetto un errore, ma
se faccio solo una misurazione l’errore, per valore di carico, non lo trovo! Trovo l’errore solo facendo ripetizioni per
ogni valore di carico. Per ognuno dei valori di carico è opportuno fare un numero di ripetizioni (numero minimo 3).
Come faccio a caratterizzare questa misurazione? Ho fatto tre misurazioni ma io ho bisogno di un solo punto. Due
sono le scelte:
• Media dei valori

• Ogni volta vado a vedere la deviazione standard, se è troppo elevata capisco che c’è un outlayer e mi prendo
la mediana.
Ma come definisco che la deviazione standard è troppo elevata? Lo faccio attraverso il coefficiente di COV
𝑑𝑒𝑣𝑖𝑎𝑧𝑖𝑜𝑛𝑒 𝑠𝑡𝑎𝑛𝑑𝑎𝑟𝑑
(coefficient of Variation). Se la ≥ 0.5 bisogna buttare la media e quindi l’errore è altissimo, o
𝑚𝑒𝑑𝑖𝑎
prendiamo la mediana o facciamo più ripetizioni. Quindi faccio:
1) Più valori di carico applicati ai sistemi
2) Per ogni carico replico più volte
3) Non troppi utenti (tra 30 e 100 utenti)
4) La configurazione deve essere costante per ogni carico!

Nel produrre il grafico abbiamo che sull’asse delle X va il carico mentre su quello delle Y la media o la mediata del
throughput e response time.
Il capacity test si può raggiungere con differenti tipi di richieste, è normale che se richiedo pagine grandi il server
risponde in un modo e il limite del server sarà un limite molto inferiore rispetto a farlo con pagine più piccole. Il limite
di questo server sta a 0 se richiedo pagine di 1Gb alla volta. Se chiedo pagine di 1Kb lui me le dà subito, quindi Il limite
di un server può dipendere da diversi fattori. Posso usare diversi tipi di pagine. Piccole, medie e grandi oppure miste
con un random controller.
Mi dà il numero minimo di ripetizioni, mi dà il tempo da settare per la misura. Devo avere uno stato del server che mi
dia un’indicazione corretta, perciò, uso un tempo prefissato per il mio esperimento.
È inutile fare misurazioni troppo fitte, se scelgo X1 con 30 richieste al secondo dopo non vado a 40 ma vado un poco
più in là sennò non me ne esco. A me interessa trovare knee e usable, sta a me capire come settare questo
campionamento. Se sto a 1000 richieste al secondo e il server sta schiattann è inutile che vado a 1500.
“Sorpresa” Negli anni precedenti chiedeva 4 capacity test (piccole, medie, grandi, random pages). Quest’anno
facciamo solo pagine miste. Questo che significa? Che il capacity test deve essere fatto perfetto per l’esame. Ordine
dei MB come richieste grandi. Usa random controller e fare richieste miste. Questo rappresenta uno scenario quasi
simile a quello reale.
Un capacity test, carico che varia, random controller e CTT.

LEZIONE 8 14/10/21
Nella scorsa lezione (la 6) abbiamo introdotto le tecniche di clustering e la caratterizzazione del clustering. I problemi
di riduzione della dimensione dei dataset vengono da tecniche di statistica inferenziali o da tecniche di machine
learning. Ma esistono anche altre tecniche che possono andare bene.
Esistono degli studi che dimostrano, che al di là del problema della performance analysis in un dominio specifico, che
effettuare una rotazione dello spazio della feature permette di far funzionare meglio gli algoritmi di clustering.
Tornando al nostro problema sappiamo se la PCA ci serve? Si, applica una riduzione alle dimensioni del problema e la
cosa per la quale è utile è che al di là della tecnica in sé, possiamo decidere di quanto ridurre e quando riduciamo
sappiamo quanta varianza perdiamo. Questo perché la tecnica ci dice la varianza spiegata per ogni componente.
Una volta che ho ridotto lo spazio abbiamo i punti e voglio ora ridurre i punti stessi. Anche qui vediamo le tecniche, le
spieghiamo e le contestualizziamo al nostro problema e alla fine dobbiamo applicare una riduzione e sapere quanta
varianza perdiamo.

Clustering
Con clustering indico l’atto di accorpare oggetti aventi caratteristiche simili. Come capisco che sono simili? In base a
una funzione di similarità o dissimilarità, a seconda del tipo di problema. Se ho questi punti una funzione può essere la
distanza euclidea, ma posso anche avere altro. Una situazione ideale per un raggruppamento sarebbe la seguente:
Mentre spesso capiterà una situazione come la seguente dove il raggruppamento risulterà più difficile:

Ma a cosa serve il clustering nell’ambito della performance analysis? Mettiamo che vogliamo in qualche modo
caratterizzare un workload, Il clustering mi serve ad accorpare i punti del workload simili tra di loro al fine di ridurre il
workload in punti significativi.
Se prendo la figura con 30 punti di workload reale con I/O e CPU usage di una macchina vedo che formo 5 cluster e ho
degli outlayer. Gli outlayer sono quei punti fuori media che nel caso di clustering si presentano anche con bassa
intensità e vanno presi quelli con un carico apprezzabile (alto a destra in un grafico). Quando faccio clustering non
devo mai trascurare l’analisi di questi punti.

Dobbiamo operare da ingegneri e analizzare tutti i punti per capire se sono significativi o no per il mio sistema.
Step del Clustering

Tipicamente gli step sono quelli mostrati in figura, l’ipotesi in partenza è quella di lavorare con dei workload reali
anche se il clustering soffre di overfitting. Per fare il clustering dobbiamo :
1. Selezionare un campione, attraverso varie tecniche (Spesso la PCA);
2. Selezioniamo un parametro di interesse (o quelli con più impatto sulla performance o più sulla varianza);
3. Selezioniamo una misura della distanza (noi useremo una distanza simile alla varianza).
Per quanto riguarda la selezione della distanza, noi scegliamo una distanza che è molto più simile alla varianza. Non ci
accontentiamo della distanza euclidea anche se sul libro c’è un esempio con un osservazione che per il prof però
risulta un errore grossolano. La distanza euclidea non è una deviazione standard (però il prof non l’accetta).
4. Va sempre fatta un analisi degli outliers, perché possono essere delle anomalie;
5. Devo capire come scalare l’osservazione (normalizzare) questo perché avere i punti così come sono può non
andare bene, devo fare normalizzazione. Che tipi di normalizzazione? Una delle più usate è la Z-score, ma
posso usare anche altre normalizzazioni, questi passi li devo valutare io. Devo capire bene il sistema e i dati e
capire se una tecnica va bene oppure no.
6. Ci sono degli algoritmi agglomerativi o gerarchici per fare clustering, ma come calcolo la distanza tra due
cluster? Distanza dei centroidi è un metodo, massima distanza, ALTRI METODI. A seconda del metodo scelto
cambia un poco tutto.
Che distanza chiede lui a noi? Lo scarto di varianza tra i due cluster!
Per noi la distanza è qualcosa che esprima la varianza tra due elementi e due cluster! Anche il metodo normale di
clustering, dopo che ho preso i risultati devo prendere il tutto e tornare a capire se la discriminazione che ho beccato è
buona o no.
ULTIMO PUNTO CHE VUOLE SEMPRE: clusterizziamo il workload finale? Quando faccio il clustering non si chiude con le
palle! Ma voglio vedere di nuovo il workload caratterizzato.
Vediamo ora nel dettaglio le varie fasi:
SAMPLING
Non abbiamo molto il problema del sampling perché applichiamo la PCA. Se la mia matrice di workload si riduce di
colonne ma ho ancora migliaia di righe non ho risolto nulla e quindi è meglio estrarre un campione. Posso risolvere in
due modi:
• Random selection, quella che lui usa.
• Righe che sono espressioni del carico alto del sistema, (se è facile riconoscerlo devo fare uno script). Non
posso farlo a mano quando sono centinaia di migliaia di righe. Devo trovare la procedura che seleziona le
righe di massimo carico.

Quando applichi una distribuzione uniforme con la stessa probabilità riesci ad ottenere più o meno la stessa
varianza.
Random sampling (gli piace) però per lui è difficile far vedere come prendo e genero i numeri casuali in un calcolatore.
È difficile fare una distribuzione random sul calcolatore partendo dal seed.

La selezione dei parametri

Qui entra in gioco la PCA, come criterio per la selezione dei parametri del workload. Potremmo adottare in linea
teorica l’impatto sulla performance (Difficile da attuare perché richiede pochi elementi) ma nella pratica si ragiona con
la varianza (ed è per questo motivo che entra in gioco la PCA, parametri incorrelati e quelli che portano la maggior
parte della varianza). Parametri che non hanno impatto sulle performance di sistema dovrebbero essere omessi ed il
principale componente per l’analisi è l’individuare i parametri con la più alta varianza.
Domanda che potrebbe fare:
Se facciamo clustering su dati relativi alle performance del nostro sistema non effettuando PCA, andiamo a
selezionare dei parametri che ci permettano di ottenere un workload sintetico (da un workload reale) che catturi la
maggior parte della variabilità dei dati reali iniziali (i dati con massima varianza). Ciò è tranquillamente possibile ma ci
chiediamo: Conviene?
Applicare direttamente il clustering senza PCA non conviene; il problema è che senza PCA, non riusciamo ad
incorrelare le componenti: potremmo ottenere colonne con alta variabilità ma correlate tra loro. (Se prendiamo le
variabili altamente correlate è come se prendessimo la stessa cosa) [Se prendi mela gialla e mela rossa sempre una
mela è]. Da qui discende subito qual è l’obiettivo e l’utilità̀ della PCA (come già̀ visto):
1. Incorrela i dati
2. Li ordina in base alla varianza
Questo è il motivo per cui si fa prima la PCA e poi il clustering

Distance metric
Vediamo varie distanze quella che ci interessa è la SQUARED EUCLIDEAN DISTANCE ed è definita dall’immagine
successiva
Non è una metrica! Perché non vale la disuguaglianza triangolare ma ci va bene perché è simile ad una devianza, devo
solo normalizzarla e pesarla per il numero di cluster.
La CHI-SQUARE è sempre quadratica, ma sono tanti punti molto vicini tra di loro. La chi-square scala i punti quadratici
e quindi le differenze piccole le va al quadrato e li fa clusterizzare meglio perché elevo al quadrato le differenze e
capisco meglio chi è lontano e chi vicino.
La Distanza di Hamming non l’ha spiegata

Analisi di outlier
Ne abbiamo già parlato, ma è importante capire se ci sono nei valori del nostro workload che sono outliers.
Influiscono sulla normalizzazione e possono essere esclusi solo se non consumano una porzione significante delle
risorse

Data Scaling / NORMALIZZAZIONE

Poiché l’intervallo di valori dei data-point può variare notevolmente, potrebbe essere necessario scalare i valori dei
parametri in modo che i loro valori relativi e gli intervalli siano all’incirca uguali. E questo è un componente importante
di un algoritmo di clustering ed è detta la distanza misurata tra due data point. È importante perché se guardo le
figure sulle slide vedo come posso normalizzare in modi completamente opposti in base a come faccio lo scaling degli
assi! La normalizzazione impatta sui risultati del cluster.
Se i componenti del vettore dell’istanza dei dati sono tutti espressi secondo la stessa unità di misura fisica allora è
possibile usare la distanza Euclidea. Tuttavia, come detto precedentemente
Che normalizzazioni si usano? Dal punto di vista statistico va bene Z-score, gli altri sono mostrati nell’immagine

• normalizzazione pesata: si aggiunge un peso alle misure (per dare ad es. importanza ad un parametro)
• range normalization: si normalizza rispetto (ad un range) al minimo (quello che hai al numeratore, tutto
diviso la distanza tra massimo e minimo)
• percentile normalization: è come se ordinassi i dati dal più piccolo al più grande (Il denominatore mi
mantiene i dati tra il 2.5 e il 97.5 percentile)

TECNICHE DI CLUSTERING
Partiamo mostrando tutte le possibili varianze delle tecniche di clustering:
Tutte quelle non gerarchiche non ce ne importa proprio. Le gerarchiche possono essere divisive o agglomerative,
delle divisive pure non ce ne importa proprio.
Le tecniche gerarchiche agglomerative variano in base a come calcolo la matrice di distanza dei punti e ho i tre metodi
mostrati. Perché ci interessa così tanto la gerarchica? Perché nel nostro campo non esiste l’ottimo è sempre un trade
off tra i costi e precisione.
I risultati del clustering gerarchico è spesso mostrato come un albero binario o dendogramma. Ma cosa vuol dire?
Man mano che accorpo i punti della matrice delle distanze in un cluster procedo facendo lo stesso anche con gli altri
cluster, alla fine la distanza se messa in un albero mi permette di realizzare il dendogramma
Esempio, le immagini partono dalla prima in alto a sinistra e scorrono verso destra.
Partendo con 6 punti e calcolo la distanza minima tra p1 e p2, a questa distanza minima ho accorpato p1, p2. Vado
avanti calcolo le distanza minime anche tra p5 e p6, li accorpo e ho le distanze del secondo cluster. Andando avanti
arrivo a costruire un albero. Perché è importante questo albero? Ad ogni distanza mi dice il cluster che ho.
Ritorniamo al nostro problema e vediamo l’effort. Che è l’effort? È quanto mi costa fare qualcosa e devo sempre
controllare la precisione e l’errore! Ed ecco perché devo avere in output un dendogramma perché mi fa capire
quanti cluster ho e quanta varianza perdo.
VUOLE SEMPRE DENDOGRAMMA ALL’ESAME NESSUN TRICK O POLVERE NEGLI OCCHI.
Come faccio a realizzarlo? Quale algoritmo uso?

Algoritmo di agglomeramento cluster

Quindi per prima cosa calcolo la matrice delle distanze, in base alla distanza scelta e si clusterizzano i due punti più
vicini. Fatto ciò, si rifà la matrice che però ha punti e cluster ora. Prendo sempre i minimi più vicini e continuo a
costruire.
Perché si costruisce il dendogramma? Perché tengo traccia di tutte queste distanze. Uno dei problemi è che
sostanzialmente ad un certo punto devo sapere come si calcolano le distanze tra i cluster, a prescindere dal metodo.
Sia essa euclidea che euclidea al quadrato devo tenere presente cosa uso per calcolare la distanza tra i cluster e devo
usare un criterio per calcolare queste distanze tra i cluster. Partiamo dall’esempio:

Supponiamo che prendo le distanze medie e come metrica ho la distanza euclidea, in questo modo accorpo A, B, D poi
c’è C ed E. Poi stesso metodo ma con distanza diversa ho i cluster diversi.
Per calcolare la distanza allora usiamo:
• Il metodo single linkage clustering che calcola la distanza tra due cluster come il minimo tra la distanza tra
due punti interni.

• Complete linkage clustering la distanza fra due cluster viene espressa come la massima distanza.
 • Average linkage clustering la distanza tra due cluster è la media tra tutte le possibili distanze.

• Metodo del centroide calcolo il punto medio di ogni cluster e calcolo la distanza tra questi due punti.

Che ci interessa a noi? La varianza. Non riesco a calcolare la varianza, ma la devianza sì e si chiama metodo di WARD.
Si prende la devianza in un cluster, si prende la devianza in un altro cluster e la differenza tra le due è la distanza.

• Ward è un buon metodo perché accorpo oggetti la cui differenza in devianza è minima. Qual è la distanza
di Ward? È una normalizzazione del numero della densità dei cluster, perché altrimenti i cluster più popolosi
avrebbero una devianza maggiore di quelli meno popolosi.

La distanza di Ward è una distanza pesata sui cluster, in questa formula P e Q, quindi normalizzo sulla loro densità. A
meno di una costante questa distanza è la squared euclidean distance. La useremo sempre per cercare di
massimizzare la varianza INTERcluser e minimizzare la varianza INTRAcluster.
Perché è così importante? Poiché più all’interno di un cluster accorpo punti simili tra loro, varianza INTRAcluster, più i
cluster saranno differenti tra loro, varianza INTERcluster, più minimizzo la varianza totale persa e preservo la
variabilità.
Esempio con i puntini di esecuzione di un algoritmo di clustering gerarchico agglomerativo: Costruiamo quindi anche il
relativo dendogramma. Man mano fondiamo cluster più vicini.
• Stato iniziale: SI parte da dei punti del dataset, si costruisce una matrice delle distanza

• Stato intermedio: Si accorpano i punti più vicini e supponendo che sia x la distanza considerata, si descrive il
livello del dendogramma
 • Calcolo le distanza tra i due cluster aggiornando la matrice di prossimità. Una volta terminata tale operazione
scelgo i cluster da accorpare attraverso il valore di distanza minima e si aggiorna il dendogramma. Così via fino
a che non rimane un solo cluster.
Attenzione, a seconda di come calcoliamo le distanze abbiamo che il risultato dipende moltissimo dal metodo.
Infatti, se vedo l’esempio tra i diversi tipi di metodi osservo come la sequenza di cluster che prendo è differente (minuto
1:00:00 della lezione)

Da adesso invece che parlare di varianza, consideriamo la devianza. La DEVIANZA TOTALE = devianza intracluster +
devianza intercluster.
Facciamo un esempio pratico su come calcolo la devianza intracluster.
Supponiamo che siano dati k cluster e supponiamo di rappresentare 𝑋𝑖 un vettore di dimensione n (ossia un punto del
dataset). Allora, la devianza totale intracluster sarà data dalla somma delle devianze intracluster di ogni cluster: [Vedi
che la devianza è sommata per tutti i cluster (la sommatoria più esterna)]
Essa è la devianza spiegata nel cluster e quindi la somma degli elementi del cluster 𝑛𝑘 di 𝑋𝑖 − 𝑋̅𝑘 , dove 𝑋̅𝑘 è il valore
medio.
Se minimizzo la prima sommatoria interna ho ridotto portandomi quasi sempre tutta la varianza. La devianza
intragruppo la perdo perché avendo accorpato non noto più le differenze. Se minimizzo la devianza nei gruppi
massimizzo la varianza tra i gruppi. Il rapporto tra due devianze è uguale al rapporto delle varianze.
Come visibile dal grafico sopra, la devianza intracluster decresce all’aumentare del numero di cluster, questo perché
avrò meno elementi per ognuno di essi.
Intragruppo e intergruppo sono inversamente proporzionali perché la loro somma è costante. Quando applico
l’algoritmo tende a clusterizzare punti la cui devianza intragruppo è minima perché prende il minimo delle distanze.
Come si calcola la devianza INTERcluster? La devianza totale intercluster è data dalla somma degli scarti quadratici di
ogni cluster pesati per la densità del cluster stesso:
Come si può osservare dal grafico sopra, la devianza intercluster cresce all’aumentare del numero di cluster poiché
metto sempre meno elementi in ogni cluster, ottenendo così sempre più elementi differenti tra loro.
Prendiamo un esempio elementare con cinque punti in un asse bidimensionale. Supponiamo di avere i seguenti punti
su di un pianto, vogliamo effettuare un clustering con il metodo di Ward. Andiamo quindi, ad ogni passo, a raggruppare
i punti vicini in cluster.

Il punto medio di tutti è 𝑋̅ che vale {3, 4}. Allora che cosa faccio per clusterizzare? Supponiamo che faccia tre cluster.
Il primo ha come centroide C = {1,6}, Il secondo ha AB = {2, 5 ; 4,5}, etc.
Come calcola la devianza intracluster? Come somma delle devianze di ogni cluster, quindi della intracluster dei tre
cluster. Per la intercluster stessa cosa.

Quindi abbiamo detto che la devianza totale è la devianza di tutti i punti che è uguale a venti.
Per costruzione la devianza totale = devianza totInterCluster + devianza totINTRAcluster.
Ho 5 punti, questi li accorpo in 3 punti e perdo il 10% della varianza.

Qual è la devianza persa? Tra PCA e CLUSTERING?

Se io prendo N componenti principali che portano dentro il 95% della varianza e nel clustering intra è 10 e inter è 90%
quanto perdo? Posso dire che perdo il 14,5% di varianza di cui il 5% su PCA e il 10% sul clustering. Devo controllare
queste cose. Più alzo il numero di cluster più è alta la varianza che porto dentro.
Vediamo un esercizio che porteremo anche all’esame (1:14:00 della registrazione)
Prende il file “PCA_cluster_2017”, sono 324 righe x 27 colonne. Sono misure di un progetto per capire se c’è una
degradazione delle risorse. Di questo dobbiamo caratterizzare un workload e dobbiamo dire qual è la varianza persa,
prima di tutto guardiamo i dati e filtriamo i dati. Se troviamo outlayer o valori costanti li togliamo. Possiamo trovare
anche la matrice di correlazione fra le colonne ed eliminare quelle colonne che hanno correlazione 1 e quindi non
contribuiscono alla varianze.
Una domanda d’esame potrebbe essere perché gli ultimi autovalori non spiegano varianza? Da cercare la risposta.
Chiede anche un analisi di sensitività. Che cambia scegliendo più componenti principali a parità di cluster? Come varia
la varianza persa al variare di componenti principali e del numero di cluster?
Devo trovare il trade off tra il numero di componenti principali e il numero di cluster
Questo workload o con JMP oppure con MATLAB.
Dopo di che cercare un modo per calcolare la devianza persa tra PCA e Clustering. (direttamente all’esame)
Per matlab dà lo script per il calcolo della devianza persa. Con JMP uso delle formule come EXCEL.

LEZIONE 9 15/10/21
La scorsa lezione abbiamo chiuso con i clustering PCA e ora chiudiamo la parte di caratterizzazione del workload
vedendo un altro modo per caratterizzare il workload.
Un altro modo è quello di costruire un modello, posso caratterizzare un dataset o in maniera statistica o con un modello.
Uno dei modelli più usati sono i modelli di Markov.

Modello di Markov
Cos’è un modello di Markov? È un modello a stati in cui il sistema si può trovare in un certo numero di stati e la
probabilità che un sistema si trovi in un certo stato dipende da quello precedente. Ho degli stati e delle transizioni,
che esprimono la possibilità di passare da uno stato X a uno stato Y ed è necessario quando occorre modellare una
richiesta che al tempo t dipenda dalla richiesta al tempo t - 1. Esiste tutta una famiglia di modelli markoviani, quando
non conosco lo stato di un sistema, e possiamo applicare solo ingressi e uscite, si parla di catene di Markov nascoste.
Non tratteremo le catene di markov nascoste né i modelli di bayes (reti di bayes).
Ci occuperemo di catene molto semplici, e come ogni grafo che si rispetti avremo:

• Nodi: funzionalità del sistema

• Archi: probabilità che un nodo passi ad un altro nodo.

Nel caso in esempio ho 3 stati:

• Operazioni su CPU

• Operazioni su disco

• Operazioni al terminale

Le tre transizioni sono caratterizzate da una probabilità. Se sto facendo operazioni di CPU il 30% delle volte che faccio
una transizione sul disco oppure al 60% torno ad operare su CPU e al 10% vado ad operare sul terminale.
Quindi ho una distribuzione probabilistica sulle transizioni. Descrivo quindi la catena di Markov con una matrice di
transizione che mi dice: dato uno stato con che probabilità prendo una transizione verso un altro stato.
ESEMPIO DI VITA DI COTRONEO
C’era una banca che aveva richiesto uno studio di assessment a valle di una transizione verso nuovi sistemi. C’erano
attriti perché la società che aveva fatto la transizione aveva promesso un aumento di performance, ma il gruppo IT della
banca ha itt no nun è ver e abbiamo arrefuso 2mln. Questa storia magicamente ci porta a Napoli e al gruppo del prof.
Che era successo? Che il workload era caratterizzato non con i cluster ma con dei classificatori fatti in loco. La procedura
era pure fatta bene, ma non era fatto bene il metodo. Quel workload in quel modo così distribuito era molto eterogeneo
e comprendeva molti tipi di utenti tutti insieme.
Come operazioni posso avere:

• Login

• Visualizza estratto conto

• Bonifico

• Pagamento

• UN'ALTRA ventina di funzionalità

Prendiamo un nonnetto, questo che fa? Fa il login, visualizza il conto e poi fa il logout. Ovviamente c’è tutta una classe
di utenti che sostanzialmente si aspetta da una banca online una risposta molto veloce sul visualizza conto corrente e
la banca ha delle cache apposite su distribuzione nazionale ed europea.
Quindi sui server ho i cache per questa gente che entra e visualizza i conti tutti i giorni (questi server so ovviamente
abbastanza sicuri ed è tosto entrare). Poi ci sono utenti business come delle piccole, medie, grandi imprese, chi paga gli
stipendi di una impresa media non si collega e vede quanto ha in banca pure perché è inutile; si visualizza il cash flow
ogni tot settimane o mesi. Quello che in genere fa un utente di impresa dopo il login è “paga stipendi” (70%) o “fai
servizi” (30%) dopo di che fa bonifici o “visualizza conto” e poi esce.
Quindi che stiamo dicendo? Che esistono delle classi di utente ed ogni classe di utente ha il suo modello di workload.
Quello che a noi interessa è la costruzione di un modello per generare un workload, attenzione non stiamo nella
modellazione analitica e quindi un modello generale; ma ne vogliamo inferiare un modello dei dati.
Quali possono essere i warning su questo tipo di modellazione? Le transizioni (le %) li dobbiamo derivati dai dati, ma
non è detto che il valore sia pari alla probabilità c’è sempre della tolleranza. Quindi la distribuzione delle frequenze
non è detto che coincida con la distribuzione delle probabilità.
Supponiamo nel nostro esempio quattro classi diverse e ognuna di esse ha diversi modelli di workload. Ora non posso
fare come nella lez8 dove ho fatto PCA e CLUSTER. Devo generare dei modelli in base alla tipologia di utente. Generate
le matrici di transizione per i vari tipi di utente trovo che per alcuni utenti andava bene e per altri no.
Non ci interessa disegnare il modello ma ci interessa la MATRICE. Come genero questo workload? Una matrice può
generare N workload o addirittura infiniti Workload perché la matrice ci dice solo la probabilità. Per generare il
workload devo capire come funziona il mio sistema.
Prendiamo un esempio che sta anche nelle slide.
Un modello di trasmissione di pacchetti, piccoli e grandi, nello specifico quattro piccoli seguiti da uno grande, in media.
La matrice di transizione è quella mostrata.

Data la matrice di transizione, questa matrice può generare una serie di workload. Posso generare poi un’altra matrice
,come mostrato di seguito, derivandola dalla prima ma attenzione sono probabilità ancora una volta ed è un modello
probabilistico infierito dai dati. Ma nella generazione delle matrici dobbiamo sempre essere cauti perché generiamo
noi il workload che vada bene per il nostro sistema.

Domanda studente: Abbiamo detto che abbiamo diversi profili di utente ed ognuno sottopone richieste differenti e
costruiamo workload differenti per ogni utenti. Noi stiamo creando diversi workload e quindi facciamo diverse
valutazioni quanti ne sono di workload, quale dobbiamo usare? Dipende da chi lo richiede è giusto avere un set di
workload da fornire dei dati per capire cosa fare in base alle richieste.

CARATTERIZZARE I DATI MISURATI (Lecture_5_IE)

Cominciamo dalla base della statistica inferenziale.
La statistica inferenziale è il procedimento attraverso il quale si estraggono dei parametri sulla popolazione a partire
dalle statistiche campionarie.
Il nostro problema è un problema di statistica inferenziale, perché? Quando misuro un sistema, ad esempio il response
time, ciò che stiamo facendo è estrarre un campione da una popolazione (insieme di tutti i possibili response time).
Questo campione (mostrato nell’esempio) non è il comportamento reale, si porta un errore che è proprio del processo
di estrazione.
Prima di tutto cerchiamo di comprendere come caratterizzare un dataset (campione), ossia descrivere il dataset con
un modello statistico.
Abbiamo visto la media e abbiamo visto che può essere un buon modello se esso non è molto variabile. In quali casi la
media non può essere utilizzata? L’abbiamo detto, quando la distribuzione è molto variabile ed inoltre, altra
caratteristica del valore medio è che non è necessariamente un valore del campione.
Esempio: Consideriamo un sistema A con un tempo di risposta misurato lungo cinque giorni ed otteniamo i valori nella
tabella.

La media è ottenuta nella maniera classica e con la formula mostrata di seguito.

Se misuro l’età media della seconda fila in aula, l’età media non sarà un valore di uno di loro.
Esistono poi altri indici di tendenza centrale, ci riferiamo a quegli indici che sono campionari ossia calcolati su un
campione di n osservazioni. Una di esse è la mediana e l’altra è la moda campionaria; quindi, ricapitolando gli indici di
tendenza centrale sono:

• La media campionaria

• La mediana, con la mediana ordiniamo il campione in maniera crescente e prendiamo come osservazione il
valore centrale. Se i numeri sono pari vengono presi i due valori centrali e fatta la media.

• La moda campionaria è ottenuta graficando un istogramma e specificando il punto medio, dove l’istogramma
ha il picco. Per variabili categoriche, la moda è data dalla categoria più presente
Alcune considerazioni: la media è maggiormente affetta dagli outliers rispetto alla mediana e la moda, media e
mediana esistono sempre e sono uniche, la moda potrebbe non esistere.
Quando usare un indice di tendenza centrale piuttosto che un altro? Uno degli errori che avevamo trovato era che tutti
i tempi erano tempi medi e quindi non è l’indice di dipendenza giusto; ma lo vedremo meglio dopo.
Dall’immagine, quando la PDF è simmetrica rispetto al suo valore più probabile i tre indici coincidono ed è questo tale
valore. Il problema è quando le distribuzioni non sono simmetriche (hanno una skewness-asimmetria) e presentano una
coda, ovvero nella parte con i segni rossi in basso a sinistra.
Se c’è una simmetria e voglio dare un indice di tendenza centrale devo dare la mediana. Oppure uso la moda, ma la
moda è il punto più probabile.
In alto a destra ho una distribuzione bimodale, media e mediana non esprimono un indice di tendenza che può
rappresentare i dati ed è quando ho più punti probabili, la caratterizzazione va studiata con i punti modali.
Altri esempi di come si usano gli indici di tendenza:

Quando caratterizzate il load e avete un indice dell’utilizzo delle risorse e vogliamo capire il collo di bottiglia usiamo la
moda.
Come capisco se c’è simmetria o no? Ci sono dei calcoli che mi dico sostanzialmente la simmetria della curva. Un
calcolo semplice della skewness è il rapporto tra MAX e MIN se il rapporto è grande allora c’è asimmetria della
curva, altrimenti ci sono delle formule più precise quale quella di Pearson.
∑(𝑥 − 𝑥̅ )3
𝜎3
Ovvero la media di x meno x segnato al cubo diviso la deviazione standard al cubo.
La mediana è il punto medio cioè è il valore mediano.
Si ordinano le osservazioni e vedo il valore centrale, se non c’è il valore mediano si usa il valore medio tra due punti.
Tra media e mediana abbiamo valori differenti; la media è un indice che si calcola e non appartiene alle osservazioni.
Come si vede se un indice di tendenza è un buon modello statistico del nostro workload? Si vede dalla variabilità.

Per esempio, a sinistra del grafico ho una bassa variabilità perché l’istogramma è tutto concentrato su pochi valori,
varianza bassa e la media può essere un buon modello. Se i valori sono tanto distanti è indice di elevata variabilità
allora la media è una scelta sbagliata e conviene scegliere dei valori modali.
Questa immagine è molto utile per capire quando usare cosa. Usare i valori
modali è utile per i valori categorici, non numerici.

Indici di dispersione
Quanto è buono un modello ce lo dice l’indice di dispersione. Cioè minore è la dispersione meglio il modello è,
esistono altri indici di dispersione oltre quelli visti adesso questi sono:
 • Range: differenza tra il minimo ed il massimo

• Varianza o deviazione standard

• Decimo e novantesimo percentile

• Range interquartile

• Deviazione del valore assoluto, poco usata

Range
Per analizzare la variabilità dei dati, una prima misura potrebbe essere il Range, cioè la differenza tra valore massimo e
valore minimo dei valori osservati.

Il range lo usiamo poco perché è sensibile alla numerosità delle osservazioni, non è robusto agli outliers e allora
quando uso il range allora? Quando sono sicuro che i valori dei miei dati sono limitati! Sono quindi dati bounded. I
numeri della tombola sono bounded.

Varianza o deviazione standard

La varianza campionaria è definita come segue
𝑛
2
1
𝑠 = ∑(𝑥𝑖 − 𝑥̅ )2
𝑛−1
𝑖=1

La deviazione standard è definita come la radice quadrata della varianza. Si osserva che in alcuni casi è preferibile
parlare di deviazione standard, invece che varianza, per conservare il significato “fisico” della variabilità effettiva dei
dati.
Ha già per noi un buon significato e sappiamo quanto è importante, man mano che ci addentriamo nel mondo della
regressione lo sarà sempre di più. La divisione per 𝑛 − 1 è perché solo questi sono indipendenti, la somma di tutte le
n differenze deve essere zero.
In altri casi, posso usare i PERCENTILE.

Percentile e quantile
Cos’è il percentile? Ho un campione e per dire che è L’N-esimo percentile vuol dire misurare la posizione di un singolo
insieme di dati basata sulla percentuale di dati al disotto di quel singolo insieme.
L’alfa quantile o il percentile è l’elemento di posizione (𝑛 − 1) ∗ 𝛼 + 1 intero più vicino.
Vediamo l’esempio nella slide, consideriamo un dataset con n = 11 elementi, avremo che:
 • 0.1 − 𝑞𝑢𝑎𝑛𝑡𝑖𝑙𝑒 (o analogamente il 10-percentile) è l’elemento di posizione: [(11 − 1) ∗ 0.1 + 1] = 2. Nel
nostro caso l’elemento è 2.7, ciò vuol dire che ‘2.7’ è maggiore o uguale al 10% dei valori del nostro dataset
(in questo caso 2.7 è maggiore o uguale a un solo elemento ‘1.9’).
• 0.5 − 𝑞𝑢𝑎𝑛𝑡𝑖𝑙𝑒 (o analogamente il 50-percentile o mediana) è l’elemento di posizione: [(11 − 1) ∗ 051 +
1] = 6. Nel nostro caso l’elemento è 2.9.

Il cinquantesimo percentile è la mediana. Un indice di dispersione importante, che viene graficato è il SIQR = SEMI
INTER QUARTILE RANGE che suddivide il dataset ordinato in quattro parti al 25%, 50%, 75%

Il Range semi-inter quantile (SIQR) è usato quando nel dataset vi sono molti outliers, in modo da eliminare gli outlier e
comprendere bene qual è il range di variabilità del dataset. Non è molto usato per le analisi di prestazioni dei sistemi
in cui gli outliers possono essere significativi.
Gli outliers non sono il demonio ma sono elementi che, anche grandi aziende che fanno assessment fanno dei cicli for
fino a che la deviazione standard fosse inferiore di un valore di riferimento. Poi si prendeva il max e il minimo dal
campione. Facendo così diciamo che praticamente il sistema va bene e basta, ovviamente significa aver buttato tutto
quello visto finora del corso
ESEMPIO

Abbiamo un sistema di cui abbiamo calcolato il range, max e minimo e ho i boxplot. Il range interquartile è 0.65 che
indica una variabilità non eccessiva dei miei dati.
Some remarks: considerazioni sugli outlier che ha sorvolato ma lascio la slide

Quantile-Quantile plots: plot quantile quantile (Q-Q plot).

Che cos’è? È un semplice metodo grafico che ci permette di determinare se due data-set provengono da due
popolazioni con la stessa distribuzione.
Supponiamo di avere una serie di osservazioni 𝒚𝒊 di cui una distribuzione con anche dei quantili 𝒒𝒊 . Supponiamo che
𝒙𝒊 è una distribuzione teorica di cui abbiamo anche in questo caso i quantili; o me li danno o ho una tabella che mi
dice quanto sono i quantili. Che cosa è un QQ plot? Nell’asse delle Y ho i quantili della nostra osservazione. Allora ho
che è un semplice metodo grafico dove sulle Y i quantili osservati e la X i quantili teorici, così posso capire quanto è
lontana la nostra osservazione dall’osservazione teorica.
Ce lo fa vedere perché statisticamente all’esame lo dimentichiamo.
Esempio
Vogliamo testare se un campione y proviene da una distribuzione normale, sull’asse delle X si mettono i valori dei
quantili della distribuzione teorica, sull’asse delle Y si mettono i valori dei quantili della distribuzione realmente
osservata.
Più questi punti formano una linea retta, più la distribuzione osservata si avvicina a una distribuzione normale (quella
tratteggiata, che sono i punti ideali).
Questi dati sono normali? (immagine da slide p.26) se è una linea retta precisa è una normale. Sto estraendo dei
campioni e ho visto che ci sono dei fenomeni che presentano delle casualità che a noi non interessano. Entro un certo
range visivo se i punti sono vicini ad una retta possiamo ritenerli come normale.

Questa per noi è molto vicina alla normale (p.27).

Come si esaminano i dati? Sempre all’esame perdiamo l’abitudine del test visivo. Apre JMP e ci fa vedere come
dobbiamo esaminare i dati. Tempo registrazione 1:01:48
I valori sono abbastanza simmetrici, infatti, il range tre-quartile è basso e simmetrico, posso dire che è normale? Si
devo vedere quelli che si discostano, ad esempio 2,7.
Data la nostra distribuzione con i 32 punti posso vedere e dire che tutti questi punti (quelli che seleziona) che sono
quasi la maggior parte del campione rientrano in un normale e guarda caso i valori più probabili sono distribuiti come
una normale.
Questa parte è importante e non dobbiamo mai perderla di vista.
Interpretazione del Q-Q Plot: In figura sono mostrati alcuni esempi che ci consentono di comprendere che tipo di
distribuzione si tratta.
a) La distribuzione osservata è una normale.
b) Se abbiamo tratti verticali è indice di coda lunga della distribuzione
c) Se abbiamo tratti orizzontali è indice di una coda corta della distribuzione
d) Se abbiamo dei tratti verticali e orizzontali, è indice di asimmetria della distribuzione.
Finiamo la lezione perché sennò andiamo nella CONFIDENCE INTERVALS AND SAMPLE SIZE.

LEZIONE 10 18/10/2021
Confidence Intervals and Sample size
Iniziamo oggi la statistica inferenziale essendo quella che ci serve per poter fare valutazioni di sistemi. Tutto quello che
spiegheremo si fonda su un teorema molto importante che è il teorema del limite centrale. Teorema che
affronteremo in maniera molto più simile ai problemi con i quali avremo a che fare, e non vedremo la dimostrazione
poiché ci interessa capire a cosa serve.
Il nostro problema qual è, statisticamente parlando? Abbiamo una popolazione, che però non è sempre conosciuta
infatti basta pensare ai dati dei vaccini all’inizio, dalla quale estraiamo un campione (Sample) che può essere costituito
da più osservazioni.
Nota: Per noi un campione è costituto da N osservazioni. Ma non disdegneremo il caso limite nel quale un campione è
costituito da una singola osservazione.
Sul campione posso considerare delle statistiche, questo vuol dire che se sul campione calcolo media e varianza
conosco i parametri statistici del campione.
Mi chiedo se dall’osservazione statistica di un campione posso trarre osservazioni statistiche sulla popolazione.
Cerchiamo di descrivere in maniera dettagliata cos’è un campione e cos’è una popolazione:

• Considereremo la popolazione come tutti i possibili valori di un certo fenomeno e supponiamo che questa
popolazione sia descritta una media 𝝁 (mu) e una deviazione standard 𝝈 (sigma) o una varianza 𝝈𝟐 .

• Un campione è un insieme di osservazioni dove conosciamo delle statistiche campionarie, ad esempio la

media 𝑥̅ e la deviazione standard 𝑠, che è la radice della varianza campionata. Quindi dal campione sappiamo
le statistiche, mentre la statistica della popolazione non la conosco. Ogni volta che estraggo un campione le
sue statistiche non coincidono mai con quelle di uno stesso altro campione, perché? Perché un poco c’è
casualità e un poco sono diversi tra di loro.
Se voglio capire quanto 𝑥̅ si discosta da 𝜇 come posso fare? Inizio capendo quale misura usare, ovvero l’errore
standard.
La statistica inferenziale ha quindi come obiettivo quello di cercare di estrarre dei parametri sulla popolazione a
partire dalle statistiche campionarie. Ora il nostro obiettivo sarà quello di capire l’errore che commettiamo
approssimando i parametri della popolazione con la statistica campionaria. Tale errore prende il nome di standard
error.
The standard error
L’errore standard ci dice quanto le statistiche di un certo campione si avvicinano a quelle della popolazione. Se ho
un errore standard piccolo allora il campione è vicino alla popolazione, viceversa se è grade il mio campione si
allontana dalla popolazione.
Facciamo un esempio, ho una popolazione che ha media 𝜇 = 3 e supponiamo di estrarre da essa un insieme di
campioni N. La prima estrazione è il primo campione (𝑥̅ = 3) poi faccio un’altra estrazione, un’altra ancora fino ad
ottenerne nove e vedo che ogni estrazione è fatta da 4 osservazioni. Faccio sostanzialmente 9 estrazioni con 4
osservazioni ciascuna, quindi ho 9 campioni e ognuno di essi ha la sua media 𝑥̅ , parliamo quindi di variazione di
campioni.

Se ho una popolazione che ha una sua statistica, e quindi una sua distribuzione, ogni volta che estraggo un campione
se ogni campione è descritto da una V.A (variabili aleatorie) anche le loro medie sono V.A.
La distribuzione delle sample mean (delle medie campionarie) è una variabile aleatoria. Perché lo sottolinea? Perché
devo capire che non c’è nessun processo deterministico dietro. Qua si tratta di capire quanto un’estrazione è vicino
alla media
La distribuzione delle medie è una variabile aleatoria, se vado a plottare queste variabili aleatorie, attraverso un
istogramma, che ottengo? Una distribuzione delle medie campionarie tale che abbia un valore più probabile, ovvero
quello centrale. Questo valore più probabile, guarda caso, è proprio il valore della media delle popolazione, come mai
questa cosa? Basti pensare alla Galton board ovvero all’esperimento della tavola con le palline in alto che scendono
verso dei canali e quello che avremo sarà sempre una gaussiana.
Ogni estrazione ha una sua media campionaria, se ad esempio io avessi un campione e mi calcolo la media e sono nel
punto a dx del picco con media pari a due mentre quella del campione è tre; come posso calcolare l’errore che
commetto approssimando la media del campione alla media della popolazione? La deviazione standard di questa
distribuzione che mi dice? La variabilità dei dati e mi dà un’indicazione su quanto mi discosto dal valore più
probabile. Quindi se io ho una deviazione standard pari a 0.1 vuol dire l’errore massimo che commetto è 0.1 e quindi
la deviazione standard delle medie campionarie mi dà un’indicazione su quanto la media del mio campione è lontano
dalla media della popolazione.
Se scopro che la distribuzione delle medie campionarie è fatta in questo modo e che il valore più probabile è proprio il
valore della media della popolazione, quanto si discosta dalla media? Come lo quantifico? Con la deviazione standard
Che cosa posso fare? Posso capire che l’accuratezza del mio campione è dovuta anche dalla standard deviation delle
medie campionarie, ricordiamo che non possiamo fare troppe misure ed è qui che interviene il teorema del limite
centrale.
Se voglio provare un’aspirina la do a tutta la popolazione e se su 2mld all’80% passa il mal di testa allora è buona, il
problema è che non posso farlo, ed è qui che interviene il teorema del limite centrale.

Teorema del limite centrale

Si assume che i campioni siano fatti da dei random samples (sequenze indipendenti e identicamente distribuite IID),
per noi è fondamentale che i campioni siano random samples. Se i campioni sono in numero abbastanza grande (30 è
il numero magggico), possiamo dire che la distribuzione delle medie campionarie ha una forma di una normale con:

• media 𝜇
𝜎
• deviazione standard , n numero di campioni tendente all’infinito.
√𝑛

Al crescere del numero di campioni io riduco lo standard error. Quando i campioni sono minori di 30 posso dire che la
distribuzione della media campionaria non è una normale (La distribuzione normale è per definizione la
distribuzione gaussiana) ma è una T-STUDENT/DISTRIBUTION.
Ovviamente che ci aspettiamo dal teorema del limite centrale? Non una normale perfetta, come posso vedere anche
dagli esempi.

La maggior parte di noi prende un certo numero di campioni e fa il test di normalità, ma a noi più che la normalità
interessa il fatto di star facendo esperimenti in maniera indipendente.
Vediamo qualche simulazione su MATLAB per capire di che stiamo parlando.
Fa vedere per sommi casi lo script sennò ci offende. Suppone di avere 30 osservazioni per 10 campioni e vediamo la
distribuzione. Con 10 campioni non assomiglia manco un poco ad una normale e anche sul q-qplot ho punti fuori dalla
retta.

Se prendo ora più campioni (invertendo 30 con 10) ho una coda ripida.
Continuiamo a non avere una distribuzione normale, infatti nella figura due ci sono le code all’inizio e alla fine.
Non vediamo le simulazioni per giocare, ma perché il test di normalità lo facciamo prima di tutto visivo e non con
metodi non parametrici (infatti non conviene quasi mai farlo con metodi parametrici), la normalità è per N che tende
ad infinito. Però siamo sicuri che se N è grande e i test in indipendenza allora possiamo essere tranquilli, ovviamente
se aumento i campioni ottengo una normale.

In molti casi il numero di osservazioni è estremamente limitato. Quando usare il q-qplot? Quando non siamo sicuri
delle condizioni di indipendenza, infatti nell’homework vuole la dimostrazione di questa proprietà. Fare un ciclo for
è inutile perché dopo un esperimento bisogna de allocare tutto e rilanciarlo.
NON BISOGNA CONTROLLARE SE I DATI SONO NORMALI, BISOGNA CONTROLLARE SOLTANTO QUANDO I DATI NON LI
ABBIAMO NOI E CI VENGONO DATI, PER CAPIRE SE LE MISURE SONO INDIPENDENTI O MENO.
Intervalli di confidenza basandosi sulla media di una distribuzione normale, VARIANZA
NOTA
Voglio capire, dati N campioni e la loro media campionaria, quanto questa media sia distante da quella della
popolazione. Ad esempio, prendo un web server e dico che il tempo di servizio è 5ms e voglio vedere con quale
confidenza dico che è 5%., quindi qual è l’errore che commetto dicendo che quel web server ha quel tempo di
servizio? Cerchiamo di metterci in condizioni “semplici”, lasciando stare il teorema del limite centrale.
Il caso semplice è che noi assumiamo una popolazione normale in cui conosciamo la media e la deviazione standard.
Ho una popolazione normale con media e varianza noti, si dimostra che se la popolazione è normale 𝑋1 , 𝑋2 , … 𝑋𝑛 sono
random sample, quindi campioni indipendenti e IID di quella popolazione, anche 𝑋1 , 𝑋2 , … 𝑋𝑛 sono normali con media
𝝁 e una varianza 𝝈𝟐 .

Essendo 𝑋1 , 𝑋2 , … 𝑋𝑛 dei random sample e quindi V.A. qualsiasi statistica sulle V.A è anch’essa una V.A; quindi, anche
𝜎2
la media 𝑥̅ è una V.A. E si dimostra che la media campionaria è una V.A con media 𝜇 e varianza . Quindi al crescere
𝑛
dei campioni la media tende a 𝝁 con errore zero; quindi, con infiniti campioni la media campionaria coincide con
quella della popolazione.
Che semplificazioni sto introducendo? Che conosco 𝜎 (che è la deviazione standard della popolazione). Da questa
media campionaria, che è una normale, posso ottenere una distribuzione normale con media nulla e varianza unitaria
̅ −𝝁
𝑿
che si chiama deviazione normale standard 𝒁 = . (è 𝑥̅ anche se non si vede)
𝜎/√𝑛

Una Z è una distribuzione normale con media nulla e varianza unitaria.

Che cos’è un intervallo di confidenza? Una stima in cui cerco di capire in quale intervallo, della mia distribuzione
campionaria, è compresa la media della popolazione 𝜇.
In maniera più rigorosa un intervallo di confidenza è una stima di 𝜇 in un intervallo fatto da 𝑙 ≤ 𝜇 ≤ 𝑢, dove gli
estremi sono calcolati dai dati campionati. Poiché diversi campioni producono diversi valori di estremi essi sono
variabili aleatore L e U.
Proviamo con un esempio, se io sto provando in campo medico un’aspirina e la provo sul campione, ovviamente la
media campionaria risulta essere qual è la percentuale di persone che hanno avuto un effetto benefico. La provo su 40
e 38 guariscono, riesco a trovare un intervallo in cui è compresa la media della popolazione? Se si capisco pure in
quale intervallo c’è la mia media della popolazione.
Che problema ho? Che non posso cercare intervalli deterministici. 𝐿 ed 𝑈 sono variabili randomiche. Posso cercare un
intervallo L ed U in cui ho una certa probabilità di trovare la media della popolazione. Questo intervallo è l’intervallo di
confidenza.
𝑃{𝐿 ≤ 𝜇 ≤ 𝑈} = 1 − 𝛼
𝛼 o 1 − 𝛼 è detto livello di confidenza.
Quindi il livello di confidenza è la probabilità di trovare la media 𝜇 nell’intervallo di confidenza 𝐿 ed 𝑈.
Se io dico che dato questo campione, guardo l’inferenza e se da questo campione riesco a dire che la % di successo
dell’aspira è tra il 78 e l’83% posso dire che: nel 99% dei casi la media della popolazione è lì in quell’intervallo.
Che è la CDF f(x)? È la probabilità che una V.A. assuma valore minore di 𝑋.
Di questa normale se prendo i quartili o i percentili, ho che la probabilità che la media campionaria sia al di fuori è
uguale alla somma del valore della CDF di sinistra con quella di destra. 1 − 𝛼 è proprio la probabilità di trovarla lì al
centro.

L’intervallo di confidenza della variabile normale standard è proprio −𝒛𝜶 ; 𝒛𝜶 . Per ritornare alla nostra distribuzione
𝟐 𝟐
normale devo levare quel −𝜇 e quel 𝜎 2 √𝑛.
Fatto questo ho trovato i miei intervalli di confidenza.

La probabilità che la media della popolazione 𝜇 sia compresa tra questi estremi è 1 − 𝛼 è il livello di confidenza. Il
livello di confidenza è calcolato con la formula espressa sopra (la seconda). Purtroppo, il nostro problema è che
ancora non conosciamo la deviazione standard della popolazione, infatti, stavamo ancora con l’ipotesi della
VARIANZA CONOSCIUTA.
Definizione:

Se 𝑥̅ è la media campionaria di un random sample di dimensione n di una popolazione normale con media 𝜇 e varianza
𝜎 2 , posso dire che con un livello di confidenza 100(1 − 𝛼)% la media ricade nell’intervallo:
𝜎 𝜎
𝑥̅ − 𝑧𝛼 ( ) ≤ 𝜇 ≤ 𝑥̅ + 𝑧𝛼 ( )
2 √𝑛 2 √𝑛

dove 𝑧 è l’alfa mezzo quantile della normale. Z lo troviamo o in tabella o con i tool.
Che vuol dire a livello pratico? Se prendo l’aspirina e ho che al 99% funziona vuol dire se do l’aspirina a 1mld di
persone mi aspetto che ci siano persone per cui non funziona. Allora per una certa probabilità 1 − 𝛼 questi campioni
contengo 𝜇, ma ci può essere un campione che non contiene 𝜇. Se fosse stato tutto deterministico non avrei fatto
questo bordello e non facevo manco gli esperimenti.
Che problema ho? Che se io sapessi la sigma, era tutto apposto, ci rimane però sto fatto che non conosco. Uso il
TEOREMA DEL LIMITE CENTRALE dove dico che approssimo 𝜎 ad S (deviazione standard del mio campione) per N>30.
Lui vuole che capiamo bene la parte analitica. Cerchiamo di capire, che cos’è questo intervallo di confidenza a livello
pratico.
Ho un campione. E dire che questo è l’intervallo di confidenza (Rosso, linee tracciate in verticale), l’errore massimo
che commetto approssimando 𝑥̅ con 𝜇 è compreso in questo intervallo.

Trasformiamo il tutto in un problema ingegneristico. Se devo fare misure su un web server e prima di fare una
campagna sperimentale voglio che le mie misure abbiano questa precisione del 99% devo definire la dimensione
campionaria, che è quell’N che vedo sotto la radice. Capire quale N mi permette di ottenere misure precise al 99%
vuol dire capire determinare dimensione campionaria. Nel mio BENCHMARK con NBODY devo capire che misura
campionaria mi serve.
Rispetto ai problemi di biologia siamo fortunati perché assumiamo che la dimensione campionaria sia un unico N.
STORIE DI VITA DI COTRONEO: ha un amico al policlinico, e lui fa i calchi per bimbi con neoplasia al cervello e questo è
così OP che è più preciso dell’acceleratore lamellare. Lui invece fa i calchi a mano, ne fa la stampa 3D e con il PC riesce
a capire dove deve schiaffare il raggio perché se sbagli affonn o criatur. Con lui ha partecipato ad uno studio
riguardante la percentuale di neoplasie rispetto a dove vivi. In questi casi, la popolazione cambia. Se dimostro che le
statistiche e le popolazioni sono diverse. Se vivo in X e tu in Y e dimostro che le incidenze di neoplasie è diversa e gli
intervalli sono disgiunti vuol dire che quelle popolazioni so diverse, allora devo capire cosa differenzia ste due
popolazioni.
Fecero degli esami sugli emocromi e dimostrarono che effettivamente cambiano le cose.
QUESTO PER DIRE CHE DEVO STARE ATTENTO PRIMA DI DIRE CHE DUE SISTEMI VENGONO DALLA STESSA
POPOLAZIONE.

Scelta del sample size (dimensione campionaria)

La sample size ci dice quanti esperimenti devo fare per ottenere un livello di confidenza 𝟏𝟎𝟎(𝟏 − 𝜶)%. Ed è la
formula mostrata sotto. Traduzione del testo:” Se 𝑥̅ è usato come stima di 𝜇, possiamo essere confidenti al
100(1 − 𝛼)% che l’errore |𝑥̅ − 𝜇| non eccederà uno specifico quantitativo E quando la dimensione campionaria è 𝑛 =
𝑧𝑎 𝜎 2
2
( )
𝐸

Capiremo che 𝜎 può essere approssimato con 𝑠.

Questa è la prima cosa da fare prima di fare una valutazione, la dimensione campionaria.
Come espando la trattazione che ho fatto ad un caso più generale? Se prendo 𝜎 dalla popolazione (non lo tengo,
magari l’avessi) ma il teorema del limite centrale ci dice che se N è abbastanza grande approssimo 𝜎 con S (deviazione
standard) del campione e quindi mi porterò dietro questo errore di approssimazione.
Vediamo che posso calcolare l’intervallo di confidenza sostituendo a 𝜎, S. In alcune cose critiche, come capire se
questa approssimazione è ragionevole o no, posso provare a plottare e vedere in base alla deviazione standard e
capire come esce l’intervallo di confidenza. Non devo temere che i dati siano imprecisi, se sto prendendo un abbaglio
mi escono intervalli di confidenza grandi non sto sbagliando.

Fate una sessione di 30 esperimenti per il mio benchmark, prendo la deviazione standard e mi calcolo la sample size
ad un certo livello di confidenza e di errore (ad esempio N=16). Devo fare questo per ogni dimensione del problema
(100 oggetti, 1000 oggetti etc etc) e ne prendo il massimo e quello sarà la mia dimensione campionaria.
L’obiettivo non è fare cose perfette, ma prendere un accuracy del 90% già va bene.
Facciamo un esempio, supponiamo di avere i tempi di un processore nel fare un certo programma. Ed ogni
esperimento è un osservazione.
Ho questa distribuzione (media, dev std, mediana, i range interquartile e quindi non mi aspetto assai outlier). Faccio il
diagramma e il qqplot e se sono sicuro che sono indipendenti sto facendo cose inutili, ma se non lo so è bene che io lo
faccia.

Se N è maggiore di 40 l’assunzione di normalità non è necessaria, uso il Teorema del limite centrale e calcolo gli
intervalli di confidenza.
E sono abbastanza confidente che 0.52 descrive bene il mio fenomeno con un errore piccolo.
Per generalizzare, se la varianza non è nota, ripeto tutto quello che ho detto sostituendo a 𝝈, s. QUANDO NON HO
TANTI CAMPIONI SI USA LA T DISTRIBUTION e l’intervallo di confidenza si calcola alla stessa maniera usando però i
percentili della T, non della normale.

T-distribution

CHE CI CAMBIA? Che i percentili sono della T e non della Z, ma a livello di calcolo non cambia niente.
Se ho 22 campioni, la media campionaria, 𝑠, e il numero di campioni è minore di 30 calcolo gli intervalli di confidenza
sulla T distribution e anche qui sono dati abbastanza variabili, ho un errore di 3 (che è abbastanza grande).
RIPETIAMO: ho una distribuzione della mia popolazione, posso assumere la normale per essere sicuro analiticamente
o con il teorema del limite centrale assumo di avere più di 30 campioni. Se ho una distribuzione normale con media 𝜇,
dire che ho un intervallo di confidenza con 0.95 significa che se estraggo N campioni ho una probabilità di 0.95 che la
media della popolazione stia nell’intervallo di confidenza e il restante, 5%, che sia all’esterno. Prendendo ogni
campione vedo se ricade o no dentro al mio intervallo di confidenza. È una probabilità. L’ampiezza è l’errore massimo
(l’ampiezza dell’intervallo di confidenza).
Ad esempio, nell’esempio 3 l’errore è di 3 e qualcosa, e rispetto al valore massimo è di sotto al 30%. Questo errore è
grande o piccolo? Dipende da che cosa sto testando, o se i miei dati sono presi male e quindi i miei dati sono
fluttuanti per qualche motivo.
Andiamo ora a chiudere il cerchio cercando di capire che cosa? Chiudemmo la prima lezione con due grafici che erano
lo stesso fenomeno con una differenza dovuta alla casualità.
Se ho un server s1 e un server s2, ho dei campioni 𝑡11 , 𝑡12 , … , 𝑡1𝑛 e poi 𝑡21 , 𝑡22 , … , 𝑡2𝑛 . Voglio capire qual è la differenza
tra questi server

Se faccio una media al primo mi esce 4,10 dall’altra 3,98. Posso dedurre che uno dei due server sia più veloce
dell’altro? NO.
Per capirlo supponiamo che faccio lo stesso numero di esperimenti e mi estraggo una serie temporale data dalla
differenza delle due serie (una serie delle differenze).
Che accade? Che se c’è differenza tra i due server e i campioni vengono da popolazioni diverse allora la media delle
differenze è diversa da zero. Perché se i server fossero uguali la popolazione è la stessa e la media della differenze
dovrebbe essere 0 quindi si applica il test di zero mean; ed è un test sulla significatività statistica.
Zero mean

Puntualmente questa cosa non la facciamo mai, a meno che non facciamo la tesi in ML.
Uno dei test più importanti della statistica è il t-test, che viene utilizzato quando si vogliono confrontare delle medie.
Esso è un test statistico ossia un test che data una ipotesi ne verifica la veridicità. Un esempio di t-test è lo zero mean
test che verifica l’ipotesi per cui la media della popolazione è nulla attraverso l’intervallo di confidenza del campione.
Cosa dice lo zero mean? Parte dalla seguente osservazione:
• Se l’intervallo di confidenza comprende lo 0 non posso escludere che la media della popolazione sia proprio
0, e quindi non possiamo dire che le serie temporali provengono da una popolazione diversa.
o Nel caso osserviamo questo possiamo poi lavorare su una sola implementazione poiché le serie
provengono dalla stessa
• Se l’intervallo non include lo 0 allora sicuramente la media della popolazione è certamente diversa da 0.
Rifacendoci all’immagine di sopra supponiamo di avere i campioni a, b, c, d e ne tracciamo l’intervallo di confidenza. Si
possono notare che:
• Nel caso di a e b, l’intervallo di confidenza include lo zero e per questo motivo c’è una buona probabilità
(data dal livello di confidenza) che la media della popolazione sia nulla e quindi il t-test non è rigettato.

• Nel caso di c e d, l’intervallo di confidenza non include lo zero e per questo motivo c’è una buona probabilità
per cui la media della popolazione non sia nulla e il t-test viene rigettato.
ESEMPIO: ho un sistema i1 e uno i2 e li sottopongo a 7 workload, w1…w7. Calcolo la differenza tra questi 7 workload
nei due sistemi. Ho meno di 30 campioni quindi applico intervallo di confidenza con T distribution che cosa noto
calcolando i CI? Che non posso concludere che la media delle popolazioni non presenti una differenza statistica tra i
workload.
Per comparare due alternative esistono delle classi di test:
1. Test parametrici

2. Test non parametrici

LEZIONE 11 21/10/2021
Intervalli di confidenza basandosi sulla media di una distribuzione normale, VARIANZA
SCONOSCIUTA
Riprendiamo la lezione dall’esempio visto la scorsa lezione. Sostanzialmente un intervallo di confidenza è
quell’intervallo con una certa probabilità 𝛼 dove trovare la media della popolazione; è una statistica da applicare su un
campione.
Ho questa distribuzione (media, dev std, mediana, i range interquartile e quindi non mi aspetto assai outlier). Faccio il
diagramma e il qqplot e se sono sicuro che siano indipendenti sto facendo delle cose inutili, ma se non lo so è bene
che io lo faccia.

Se N è maggiore di 40 l’assunzione di normalità non è necessaria, uso il Teorema del limite centrale e calcolo gli
intervalli di confidenza.
E sono abbastanza confidente che 0.52 descrive bene il mio fenomeno con un errore piccolo.
Abbiamo poi fatto una trattazione analitica che segue i seguenti passi:
1. Assumiamo, nell’ipotesi semplificate, una popolazione distribuita normalmente di cui conosciamo la media
e la varianza

2. Nella pratica non sappiamo la statistica della popolazione né se la popolazione sia distribuita
normalmente.

3. Quando siamo nell’ipotesi del teorema centrale possiamo approssimare la deviazione standard/varianza
della popolazione altrimenti può essere approssimata con la t distribution

Abbiamo visto anche un altro aspetto fondamentale, ovvero come comparare due serie temporali e se la loro
differenza è dovuta solo ad un caso o se è statisticamente significativa. Cosa vuol dire il secondo caso?
Vuol dire che le due serie temporali sono campioni di diverse popolazioni.
ESEMPIO: ho un sistema i1 e uno i2 e li sottopongo a 7 workload, 𝑤1 , … , 𝑤7 . Calcolo la differenza tra questi 7
workload nei due sistemi, ho meno di 30 campioni quindi applico intervallo di confidenza con T distribution; che cosa
noto calcolando i CI? Che non posso concludere che la media delle popolazioni non presenti differenza statistica tra i
workload.

Nello zero mean test noi assumiamo l’ipotesi che la differenza tra due serie temporali abbia media uguale a zero,
avere quest’ipotesi significa che le due serie temporali derivano dalla stessa popolazione e non c’è differenza
statistica.
Per comparare due alternative esistono delle classi di test di significatività:
1. Osservazioni accoppiate: si fanno delle osservazione e per ogni osservazione i-esima di un sistema A ne
abbiamo la corrispettiva nel sistema B. Si calcola poi l’intervallo di confidenza della differenza ed infine
possiamo applicare tranquillamente lo zero mean test.

o Se lo zero mean test non è rigettato (I.C della differenza contiene lo 0): La media della popolazione
delle differenze ha un’alta probabilità di essere è nulla (Si conosce anche con quale probabilità ossia
il livello di confidenza x%). I campioni, con quel livello di confidenza, provengono dalla stessa
popolazione (Altrimenti si avrebbe che la differenza delle medie delle rispettive popolazioni dei
campioni è diversa da 0) e dunque non sono statisticamente significativi per valutare il confronto.

o Se lo zero mean test è rigettato (IC della differenza non contiene lo 0): La media della popolazione
delle differenze ha un alta probabilità di essere diversa da 0 (Si conosce anche con quale probabilità
ossia il livello di confidenza x%). I campioni, con quel livello di confidenza ,provengono da
popolazioni differenti e dunque sono statisticamente significativi per valutare il confronto.

Vedendo l’esempio abbiamo che facendo i calcoli, otteniamo un intervallo di confidenza (−7.75, 7.11) che include lo
zero. Lo zero mean test non è rigettato. La media della popolazione delle differenze ha un’alta probabilità che sia nulla
(Ossia il livello di confidenza x%). Di conseguenza non possiamo dire che i campioni provengono da popolazioni
differenti (altrimenti si avrebbe che la differenza delle medie delle rispettive popolazioni dei due campioni non è nulla)
e dunque non sono statisticamente significativi per valutare il confronto
 2. Osservazioni non accoppiate: non si può applicare uno zero mean test così come visto ma altri come il t-test
in matlab, oppure il visual test.

o Il t-test è sempre un test statistico che verifica l’ipotesi di media nulla. Il t-test può essere:

▪ parametrico (tutta la statistica parametrica è quella che deriva dal Teorema del limite
centrale)

▪ non parametrico (tutta la statistica non parametrica rilassa il vincolo di indipendenza e

identicamente distribuita)

o Visual test (esempio mostrato esattamente di seguito)

Supponiamo di avere due campioni ottenuti applicando un numeri differenti di workload al sistema A e al sistema B
(così che la loro dimensione sia differente): Se disegniamo l’intervallo di confidenza al x% su un piano cartesiano,
possiamo vedere che:

(a) Se non c’è proprio overlap tra i due intervalli di confidenza, allora per quel livello di confidenza i campioni
provengono da popolazioni differenti e dunque sono statisticamente significativi per il confronto.

(b) Se c’è overlap tra gli intervalli di confidenza e la media di uno è nell’intervallo di confidenza dell’altro, allora per
quel livello di confidenza i campioni provengono dalla stessa popolazione e dunque non sono statisticamente
significativi per il confronto;

(c) Se c’è overlap tra gli intervalli di confidenza ma la media di nessuno è nell’intervallo di confidenza dell’altro occorre
fare il t-test perché non si è sicuri se i campioni provengono o meno dalla stessa popolazione
Che cos’è la correlazione?
Il concetto di correlazione deriva dal concetto di covarianza, ovvero le due grandezze covariano nello stesso modo,
quindi, c’è una relazione tra due variabili.
Negli altri corsi abbiamo imparato la formula della covarianza, essendo la moltiplicazione tra due scarti, ma per
correttezza la ripetiamo qui:
∑𝑛𝑖=1(𝑥𝑖 − 𝑥̅ )(𝑦𝑖 − 𝑦̅)
𝑐𝑜𝑣𝑎𝑟𝑖𝑎𝑛𝑧𝑎(𝑥, 𝑦) =
𝑁−1
La covarianza non è una grandezza standard perché dipende dalla scala degli 𝑥𝑖 e 𝑦𝑖 e da sola non può dirci a livello
quantitativo come una variabile varia rispetto ad un'altra, probabilmente dal livello qualitativo possiamo fare delle
congetture sulla covarianza di due grandezze.

Per renderla una misura standard la si normalizza rispetto alla deviazione standard e prende il nome di Coefficiente di
Pearson, il quale ci dice come varia una variabile rispetto ad un'altra:
𝑐𝑜𝑣𝑥𝑦 ∑𝑛𝑖=1(𝑥𝑖 − 𝑥̅ )(𝑦𝑖 − 𝑦̅)
𝑟= =
𝑠𝑥 𝑠𝑦 (𝑁 − 1)𝑠𝑥 𝑠𝑦

Questo coefficiente è sempre compreso tra -1 ed 1 e dagli esempi vediamo quando c’è una correlazione positiva
(variano allo stesso modo) e quando una negativa (variano in maniera inversa). È un coefficiente che useremo quando
vogliamo stabilire quando due grandezze variano nello stesso modo.
Esistono anche coefficienti non parametrici, ma cosa significa? Il coefficiente di Pearson, e tutte quelle campionate, si
applicano quando viene estratto un campione con delle osservazioni indipendenti e identicamente distribuite (IID),
quando quest’ipotesi non sono verificate e non è possibile fare assunzioni sulla distribuzione dei dati in ingresso, si
usano i test e quindi i coefficienti non parametrici.
Un test non parametrico che misura la correlazione tra due variabili temporali è il coefficiente di Spearman, anche se
più che coefficiente è un algoritmo che cerca di dividere le serie temporali e classificarli in base ai ranghi per poi
inferire l’eventuale correlazione tra le serie. All’interno dei tool lo troveremo come Sperarman’s rho.
Torniamo al problema della causalità, la correlazione esprime solo una covariabilità di due variabili verificata
statisticamente non la causalità; in effetti la causalità non può essere dimostrata dalla correlazione per via
dell’assioma “problema della terza variabile”. Ad esempio, alcuni anni fa si voleva dimostrare la correlazione tra
vaccini e autismo, lo studio effettuato da una serie di dati dimostrava l’esistenza di una correlazione ma avevano
sbagliato proprio perché avevano dimenticato di quest’assioma. La terza variabile, oltre chi non è vaccinato no,
consisteva nel fatto che il controllo nel quale si possono notare le prime avvisaglie è proprio quando si finiscono le
vaccinazioni.
Ma quindi come spieghiamo la causalità? Con altri test più restrittivi

Hypothesis testing
Formuliamo un ipotesi per la nostra popolazione, l’ipotesi è una congettura, ad esempio possiamo pensare che un
medicinale sia migliore degli altri oppure che l’affitto per una stanza a Napoli sia meno costosa da altre parti, etc.
L’ipotesi mi è utile perché potrei dimostrare, in maniera analitica, se e solo se avessi tempo infinito e tutta la
popolazione.
Statistical hypothesis: è una procedura che porta alla decisione di effettuare la null hypothesis (ipotesi nulla ed è
quella che vorremmo dimostrare o smentire) e un test basato su questa decisione è un test di una ipotesi.
Le procedure di hypothesis testing si fondano su un campione randomico per applicare il limite centrale. Prendo un
campione, prendo una statistica dal campione e vorrei capire se attraverso una procedura posso rigettare o meno
l’ipotesi nulla. Se rigettassi l’ipotesi significa che c’è un’alta probabilità che la mia affermazione non sia vera, non
rigettare non significa accettare ma significa che quell’ipotesi potrebbe essere vera.
Rigettare o meno non sono certezze, sono probabilità.
Tipicamente la formalizzazione del test di ipotesi è fatto attraverso due ipotesi:

• 𝑯𝟎 - ipotesi nulla: è quella che vorremmo testare ed è tipicamente espressa con un’uguaglianza. È chiamata
nulla perché, di solito, rappresenta lo status corrente o che non ha effetti. Ad esempio, ipotizzo che la media
sia pari a zero.

• 𝑯𝟏 - ipotesi alternativa: è l’affermazione che contraddice l’ipotesi nulla. Rigettare l’ipotesi nulla porta alla
decisione di accettare o non rigettare l’ipotesi alternativa 𝐻1

In altre parole, vogliamo determinare se c’è un’evidenza significativa che rigetti l’ipotesi nulla in favore di
un’alternativa.
Vediamo un esempio, il costo di un monolocale a Napoli e a Milano. Il costo medio è dato da 𝜇 per Napoli e 𝜇0 per
Milano, voglio dimostrare che il costo medio a Napoli sia uguale a Milano:
𝐻0 : 𝜇 = 𝜇0
𝐻1 : 𝜇 < 𝜇0
Questo modo è chiamato la one-sided alternative hypothesis che a differenza della two-sided che può essere
espressa come:
𝐻1 : 𝜇 ≠ 𝜇0
In base a come ci troviamo meglio.
Quindi la nostra congettura è che i monolocali abbiano lo stesso prezzo, prendiamo un random sample e stabiliamo
due punti, che si chiamano valori critici, nel quale spero che la media sia compresa. Supponiamo di avere 500 euro di
media per Napoli, stabiliamo l’intervallo di tolleranza come 490-510. Se il valore è fuori dall’intervallo l’ipotesi nulla è
rigettata e se è all’interno dell’acceptance reagion non possiamo rigettare l’ipotesi nulla.

Vediamo un altro esempio: Supponiamo che stiamo valutando la velocità di combustione di un certo motore e
vogliamo vedere se la velocità, come da requisiti, sia di 50 𝑐𝑚/𝑠. Formuliamo l’ipotesi two sided.
Fissati dei valori critici: 48.5; 51.5 diciamo che se preso un campione e la sua media è compresa tra i valori critici non
rigettiamo l’ipotesi nulla, altrimenti si. La parte gialla dove rigettiamo l’ipotesi la chiamiamo regione critica, nell’altro
caso parliamo di fail to reject.
Quale errore posso commettere in questo test di ipotesi? Prendo un campione prendo un valore 𝑥̅ e capita nella
regione critica anche quando 𝐻0 è vera, supponiamo che 𝜇 = 50 e 𝑥̅ = 60 ho commesso un errore di tipo 1.
L’altro errore, di tipo 2, è quando la media è rigettata e il mio campione è nell’acceptance region. Quando faccio un
test di ipotesi posso avere i seguenti casi

Riassumo i possibili risultati con questa matrice:

L’errore di tipo 1 è quello più importante perché è legata agli intervalli di confidenza ed è pari alla probabilità mostrata
nella slide precedente.

Errore Tipo 1
Abbiamo detto che in questo tipo di errore la media con un determinato valore (in questo caso 50) presenta un
campione con media esterna all’intervallo.

Se io so che la deviazione standard della popolazione è di 2,5 ed è distribuita come una normale, io posso
𝜎
rappresentarla tranquillamente tramite il limite del teorema centrale. Approssimo sigma come = 0.79 e mi calcolo
√𝑛
la probabilità:
Ottengo (basandomi sulla slide precedente) che il mio livello di significatività è 5.7% e quindi avere dei campioni che
sono al difuori dell’acceptance rate.
Se aumento il numero di campioni la curva si fa sempre più stretta e diminuisce l’errore 𝜶. Se passassi da 10
campioni a 16 avrei questi risultati:

Cioè fissati i valori critici, all’aumentare dei campioni potrei diminuire la probabilità di rigettare l’ipotesi. L’errore di
tipo due abbiamo detto essere quando l’ipotesi nulla è rigettata e il campione è nell’aria di accettazione. Lasciamo le
slide successive con i calcoli che mostrano le considerazioni anche sui grafici.

Errore Tipo 2
La probabilità di errore di tipo 2 è data dalla probabilità di fallire nel rigettare 𝐻0 quando 𝐻0 è falso, ovviamente
quando più 𝐻0 è vicino al valor critico 𝜇 diventa sempre più probabile quest’errore.
In generale per calcolare quest’errore dobbiamo descrivere l’ipotesi alternativa come uguaglianza, vediamo il calcolo
di seguito:
Più aumenta la curva e più aumenta l’errore, anche quest’errore ha una certa sensitività al numero di campioni.
Per chi vuole approfondire c’è il concetto di potere della statistica, ed è uguale alla probabilità di rigettare la statistica
nulla ed è pari ad 1 − 𝛽.

Potere della statistica

Vediamo un esempio per capire bene come funzionano le ipotesi one-side e quelle two side. Una ricerca vuole capire
se una donna incinta che prende vitamine porta all’aumento di peso del bambino, la media è di 3.6 kg per bambino a
nascita, quale delle due scegliamo?

Sceglieremo la prima perché se la madre prende queste vitamine e il bambino ha un aumento del peso, rigetto
l’ipotesi di base e protendo per quella con un peso maggiore.
Abbiamo visto l’errore 𝛼 che è l’errore di rigettare 𝐻0 quando esso è vero, ma potrei scegliere valori diversi rivedendo
l’esempio di prima.

Se prendessi gli estremi pari a 46 e 54, 𝛼 è più grande o più piccolo? Più grande perché l’area si fa più piccola. Questo
esempio serve a capire cos’è il P-value, ovvero il più piccolo livello di significatività in cui può essere rigettata
l’ipotesi nulla

P-Value
Tutti i test statistici dei nostri tool ci danno il P-value di una statistica, quando questo valore è molto basso possiamo
affermare che la statistica è buona (probabilità di rigettare l’ipotesi nulla).

Vediamo delle slide l’esempio in maniera più formale

LEZIONE 12 22/10/2021
Web Server Capacity Test Design of Experiment (WebServer_2)
Nota: quello visto nell’ultima esercitazione è abbastanza per poter fare il primo homework, quello di oggi si allaccia a
quello fatto ieri dal prof sul test hypothesis. Il nostro obiettivo è come effettuare il confronto tra i nostri dati.

Hypothesis Test in Matlab

Non è obiettivo nostro fare statistica pura ma vedremo le basi per i test d’ipotesi in un ambiente come MATLAB.

Quando parliamo di test d’ipotesi stiamo cercando di confrontare due diverse medie, ma non un semplice confronto
tra le medie ma uno dei tre test visti sopra in base a quale caso ci troviamo.
• Il primo è il one sample dove confrontiamo i nostri dati ed una media, vediamo un esempio. Ho un set di dati
estratto da una popolazione e so per ipotesi che la media è 𝜇0 , se prendo 30 campioni e voglio affermare che
 questi campioni hanno la stessa media della popolazione (quindi 𝐻0 : 𝜇 = 𝜇0 ). Se invece affermo che 𝜇 ≠ 𝜇0
mi pongo nell’ipotesi alternativa 𝐻1 . Lo zero mean test è un tipo particolare di one sample, perché ha la
media uguale a zero.
• La seconda categoria, paired observations, dove vogliamo confrontare due diversi set di dati e vedere se ci
sono differenze statistiche. In base a come ho collezionato i dati e come effettuo il confronto applico le
osservazioni accoppiate o il two sample (unpaired) observations; ma qual è la differenza? Nel primo caso ad
ogni osservazione i-esima ho un collegamento all’i-esima osservazione degli altri dati, mentre nel secondo
caso no. Il fatto che le osservazioni siano collegate porta ad avere il vettore di misurazione uguale e non è
possibile che siano differenti.
Come effettuiamo il one sample test su Matlab? Usiamo la funzione 𝒕𝒕𝒆𝒔𝒕 (𝒙, 𝒎) dove 𝑥 sono i nostri dati d’ingresso
in formato vettoriale o matriciale, supponiamo per adesso che sia un vettore.
L’ipotesi nulla è che i dati derivino da una distribuzione normale con media m e con VARIANZA SCONOSCIUTA.

L’ipotesi alternativa è che la media non sia m. NON POSSIAMO APPLICARE IL T-TEST PER DIMOSTRARE CHE I DATI
NON PROVENGONO DA UNA DISTRIBUZIONE NORMALE E CON VARIANZA SCONOSCIUTA.
Il valore di uscita h può essere 1 se è stata accettata l’ipotesi alternativa e rigettata quella nulla, zero altrimenti. Il one
sample t-test permette, oltre al modo base, di aggiungere un altro valore di uscita ℎ, 𝑝 che mi restituisce non solo la
prima ma anche il valore di p che è P value. Ovviamente se h è 0 P value è alto, mentre se h = 1 allora P value è molto
basso.
Se voglio un livello di significatività più alto, posso aggiungere un valore in ingresso 𝛼 come ad esempio 𝛼 = 0,01 per
avere un 99% di significatività, in questo caso per essere rigettato il P value deve essere minore di 0,01. Quindi per
applicare il t-test abbiamo bisogno che siano verificate le seguenti assunzioni:

• I data values sono continui, non posso fare il t-test su valori categorici

• I valori dei dati sono indipendenti

• I campioni dei dati sono stati scelti in maniera randomica da una popolazione

• La popolazione dalla quale stiamo estraendo i nostri dati è normalmente distribuita

Un’alternativa al t-test è lo z-test. Nonostante il funzionamento sia analogo vi è la differenza della conoscenza della
varianza per lo z-test.
Z-test

La richiesta della varianza, nonostante si possa pensare essere una richiesta di poco conto, ci pone in estrema
difficoltà poiché quasi mai la conosciamo. Conoscere la deviazione standard DI TUTTA LA POPOLAZIONE è molto
difficile.
Vediamo un esempio: hanno fatto uno studio sulle barrette e a livello di proteine è con media 20 gr. Allora uno ha
preso ed estratto 30 campioni e visto che la media della popolazione è 20 voleva vedere se le barrette campionate si
discostassero o meno dal 20.

Nella slide successiva ci sono alcune considerazioni come ad esempio: t-test è un metodo appropriato per testare che
le barrette abbiano 20 gr di proteine in media?
Lo step successivo è quello di confrontare due data sample diversi, abbiamo visto che il paired è possibile quando c’è
un’associazione tra le i-esime parte dei dati. Quando questo non c’è, passo al two-sample t-test. La funzione è uguale
solo che aggiungere la media m mettiamo i dati del secondo insieme collezionato.

Per poter usare il secondo t-test non dobbiamo avere solo che entrambi i dati campioni siano normalmente
distribuiti, ma devono anche avere la stessa varianza.
Il t-test accoppiato è lo stesso del one sample t-test solo con ingressi differenti. La varianza è ancora sconosciuta e
l’ipotesi nulla è che la differenza tra i due set di dati abbia media nulla.
Paired t-test

Mentre l’ipotesi alternativa e che la differenza tra i due set di dati non abbia media nulla e quindi rigetto
l’uguaglianza delle medie.
Il two sample t-test invece è quando non abbiamo la stessa dimensione per i dati, ma cosa significa? Immaginiamo di
avere un vettore con una colonna ed 𝑛 righe, per il paired t-test la dimensione deve essere uguale per tutti e due i
vettori 𝑥 ed 𝑦, nel caso del two sample t-test 𝑦 ha dimensione 𝑛2 ≠ 𝑛 ma questa cosa non è necessaria, possono
avere anche la stessa dimensione; questo perché essere comunque non accoppiate.
Il caso più difficile è quando abbiamo la matrice di dati, lì non abbiamo una sola colonna ma ne avremo diverse e cosa
facciamo? Prendiamo colonna per colonna? Assolutamente no, e quindi che faccio? 𝑥 ed 𝑦 possono essere
tranquillamente matrici l’importante è che le colonne siano uguali per non risultare differenti.

Two sample t-test

Vediamo un esempio con i risultati degli esami:

Qui posso effettuare il ttest accoppiato perché vi è un’associazione dei voti e anche perché la dimensione dei due
vettori è uguale.
Supponiamo che la dimensione sia ancora uguale, ma che sposti il voto 100, del primo, verso la decima posizione;
mentre il voto 65, del secondo, lo sposto alla settima posizione. Non ho fatto il collegamento tra gli indici dei vettori,
nonostante la dimensione sia uguale non posso effettuare il t-test ma devo usare il non accoppiato.
Ritornando al test non accoppiato ho un esempio sul grasso del corpo, la dimensione dei vettori non è uguale. Il
risultato di p mi dice che con un valore di significatività superiore al 95%, la mia ipotesi nulla di mancata differenza di
percentuale di grasso corporeo, è rigettata. Notiamo che se avessimo messo un livello pari al 99% il p-value non
sarebbe così piccolo da rigettare l’ipotesi nulla, perché varrebbe 0.0107 che è maggiore di 0.01.

Attenzione a non confondere il numero di componenti che confrontiamo con la dimensione di ogni componente,
praticamente il numero di componenti sono le colonne. Se io ho lo stesso numero di colonne ma diverso numero di
righe allora posso fare il confronto con il t-test non accoppiato

Nel caso in cui le varianze non siano uguali posso comunque applicare un test non parametrico ma devo aggiungere
altri due parametri. Normalmente Vartype è settato ad equal per questo dobbiamo specificarlo che è diverso,
specificato così capisce che non siamo nelle condizioni con varianze uguali per entrambe le popolazioni.
Quest’assunzione è fondamentale perché se applichiamo il t-test senza verificare la condizione otteniamo dei dati non
validi.

Assunzione di varianze uguali: homoscedasticity

Si assume che differenti campioni abbiano la stessa varianza, anche se provengono da popolazioni differenti.
L’assunzione può essere ritrovata in molti test statistici, incluse l’analisi della varianza (ANOVA) e il t-test. Altri test,
come il Welch T-test non richiedono la varianza uguale.
Effettuare un test senza controllare l’uguaglianza delle varianze può avere un impatto significativo sui risultati. Dire
che le varianze sono uguali non vuol dire che la varianza è conosciuta, si è un po’ strano ma significa che se io
prendessi due persone e le metto vicine per misurarne l’altezza potrei avere che sono uguali; adesso non so la
varianza di tutta la popolazione ma so che più o meno le due persone sono uguali.
Come effettuo un check sulle varianze uguali? Quando verifichiamo l’uguaglianza delle varianze o la normalità dei dati,
abbiamo due strade:
 • Test visivo, cioè plotto qualcosa e mi aiuta a capire se l’ipotesi che voglio accettare è valida o meno. SONO
PREFERITI DAL PROF. Per capire se le varianze sono uguali vado a vedere l’altezza del box, visivamente il C è
maggiore rispetto ad A e posso dire che le varianze tra A e C non sono uguali.

• Fare un test specifico, come quelli visti finora solo che invece di calcolare la differenza statistica, controllano
se le varianze sono uguali o altro.

L’alternativa al test visivo è vartest2 di matlab ed è la ripetizione di quello visto finora, solo che qui ipotizziamo che le
varianze siano uguali.

Fino ad adesso abbiamo sempre usufruito del limite centrale, ma se le ipotesi non ce lo permettessero? Se non
riuscissimo ad avere sempre l’indipendenza? Dobbiamo allora verificare quest’ipotesi con nuovamente due tipi di test:
• Test visivi, plot quantile-quantile

• Test non visivi, elencati di sotto

Quindi quando non possiamo dire a priori se i nostri dati provengano o meno da una distribuzione normale devo
verificarlo. Tutti i test visti oggi sono parametrici.

Il test visivo per la normalità è qqplot(x) che non fa altro che plottare i quantili dei dati rispetto ai quantili della
distribuzione standard normale, ed è praticamente una diagonale. Se i + si posizionano lungo la diagonale, come nel
caso di sotto, assumo che i miei dati provengano da una distribuzione normale. Se invece inizio a vedere qualche trend
strano allora non assumo che i dati provengano da una distribuzione normale.

In alternativa, o in aggiunta, al test visivo usiamo il kstest(x) che per verificare la normalità dei dati non è fatta in
contemporanea ma uno alla volta. A livello di funzionamento non differisce dal t-test o dagli altri visti prima.
Klmogorov-Smirnov Test

Quando si verifica il caso in cui non posso applicare i test parametrici uso altri tipi di test quali Wilcoxon rank sum test
(somma dei ranghi o test delle mediane). La cosa brutta di questa funzione è che matlab imbroglia sulle cose; infatti, il
primo parametro è p e non h, questo vuol dire che la prima uscita sarà il p-value.

Wilcoxon rank sumTest

L’ipotesi nulla è che non ci sono differenza tra le mediane dei due campioni.

Workload Characterization
Un workload è ciò che applichiamo ad un sistema, caratterizzarlo implica definire con precisione i requisiti di
prestazioni, affidabilità e capacità. Lo scopo della workload characterization è quello di ottenere un primo set di
parametri con la capacità di descrivere il carico il più indipendentemente possibile dall’applicazione stessa.
I requisiti chiave sono:

• Comparabili: i parametri che descrivono il workload devono essere poi confrontabili con altri parametri di un
altro workload

• Basic description: il comportamento dell’applicazione varia in base al workload applicato, la variazione

dipende dal tipo e dal quantitativo di lavoro
 • Specialization ability: dovrebbe essere possibile specializzare i parametri alto livello e indipendenti
dall’applicazione in parametri per workload dipendenti dall’applicazione. Ad esempio, applico una serie di
richieste ad un server, vedendo quello che accade lato server devo essere in grado di capire ciò che è stato
imposto lato client.

• Realistico : I valori del parametro del workload devono rientrare in range realistici

• Praticabile: Il numero dei parametri del workload deve essere mantenuto, in maniera ragionevole, basso.

High level workload characterization (sarebbe caratterizzazione lato client), nel nostro caso JMeter, viene vista come
una generica richiesta del servizio. Una richiesta di servizio è caratterizzata dai seguenti parametri:
• Intensity o throughput

• Size o dimensione della richiesta

• Tipo di richiesta

• Variazione della richiesta, attraverso il random controller.

Qua siamo a basso livello, livello applicativo lato server, per capire cosa succede usiamo le utility date dall’ultima
lezione di esercitazione. L’idea è quella che se io applico qualcosa dal client al server devo capire cosa sta accadendo, a
livello di processi e memorie, in modo da descrivere quello che è accaduto ad alto livello.

L’homework che ci verrà assegnato sarà questo, dove useremo quello visto l’altra volta, quindi come creare un
workload/collezionare i dati/etc.
Fase 1) costruiamo un workload reale, ovvero quanto più eterogeneo possibile, SUT = system under test e colleziono i
parametri sia di alto livello HL sia di basso livello LL. Per workload Characterization intendiamo prendere tutti i dati
raccolti, HL sono nomi della richiesta/dimensione/tempo di risposta della richiesta/etc, in formato XML e li
analizziamo con JMP. Faccio quindi la PCA e tolgo quelli che mi esprimono meno varianza, dopo di che applico il
clustering riducendo il numero di righe.
Quando faccio la caratterizzazione HL succede che ottengo un workload sintetico, ovvero ho estratto da quello reale
un sott’insieme che esprimono la maggior parte della variabilità. Ma come faccio a dire che il workload sintetico
caratterizza bene quello reale? Non posso fidarmi solo dei risultati di PCA e clustering, devo applicare questo nuovo
workload di nuovo al SUT facendo partire la fase due.
Fase 2) Non mi interessa caratterizzare i dati HL ma solo quelli LL. Quando ottengo 𝐿𝐿𝑐 e devo far in modo che i dati
caratterizzati contengano una % di variazione come 𝐿𝐿𝑐 della fase 1.
Fase 3) Quando otteniamo 𝐿𝐿𝑐 abbiamo finito poiché abbiamo caratterizzato i dati di basso livello, se voglio dire che il
workload sintetizza bene quello reale devo avere che 𝐿𝐿𝑐 non sia statisticamente significativo rispetto a 𝐿𝐿.
Prima di vedere l’algoritmo per effettuare la data validation deve essere chiaro perché per validare il workload
sintetico io vado a fare il confronto mostrato in figura. Lo facciamo perché il nostro workload deve essere comparabile
ed indipendente dal sistema che stiamo applicando, e visto che i client possono essere diversi noi vediamo ed
analizziamo il server.
Per fare la data validation si fanno tutte le tecniche viste nella giornata di oggi.

Attenzione, noi vogliamo che non ci siano differenze statistiche e che l’ipotesi nulla non sia rigettata.
L’esercizio per casa è quindi il seguente:

Homework 3? Non sono sicurissimo

Ripetiamo per high level intendiamo simple data writer, per low level intendiamo utility del sistema server.
Non abbiamo tre http request differenti, perché ogni thread group anche se chiede la stessa pagina non è la stessa
http request. Quest’ultima dipende dal thread e dal tipo di pagina.
Piccolo consiglio per chi usa più thread group, non è obbligatorio ma se lo facciamo, nella pagina di JMeter c’è una
spunta da mettere ed è quella mostrata in slide. Perché altrimenti creo una dipendenza dei vari Thread e voglio
evitarlo.

Le due slide successive le abbiamo già spiegate diverse volte.

Quando facciamo PCA e clustering ci troviamo che abbiamo delle differenti richieste raggruppate. Ho diviso in tre
cluster e vedo quale punto rappresentativo prendere di ogni cluster; infatti ho che il cluster uno è formato da 159
richieste di cui 120 solo request1. Quando ho una mole di dati enorme il punto rappresentativo lo prendo a caso, ma
nel nostro caso possiamo fare la considerazione sulla dimensione.
Nel cluster 2 e 3 prendo quelle che sono pari a 90 perché sono i maggiori.

LEZIONE 13 25/10/2021
Questa parte finirà tra massimo una settimana, ci sta anche un’altra esercitazione che ci vuole far vedere l’Ing. Liguori
in cui mostra anche vecchi elaborati, questa cosa sarà fatta online in un’oretta (forse anche fuori orario di lezione).

MODELLI DI REGRESSIONE (Lecture_6_IE)

Penultimo argomento di statistica, anzi è proprio l’ultimo di statistica inferenziale. Riguarda i modelli regressivi ma per
spiegarli ci vuole un corso a parte (un modello regressivo è un modello di predizione), ho delle osservazioni e voglio
dal campione cercare un modello di predizione della popolazione.
Il modello predittivo non è del campione ma è della popolazione. Questi modelli non servono a fare fitting, poiché il
fitting significa trovare una curva che meglio approssima i punti campionari (e non ce ne fotte proprio); un modello
predittivo invece è: dal campione otteniamo un modello che riesce a predire un certo errore/fenomeno riferendoci
alla distribuzione della popolazione (come se la volessimo inferire).
Facciamo il modello più semplice che è il modello regressivo lineare. È un modello semplice ma molto usato
soprattutto nel nostro campo.
Perché è utile? Supponiamo di avere un insieme di punti e si vuole conoscere il valore della response variable
(variabile stimata) in altri punti, ciò è possibile usando il modello regressivo, che mi permette di predire quel valore in
altri punti (Viene utilizzato molto nella manutenzione predittiva perché permette di capire quando sostituire un
componente prima che si rompa).

Regressione lineare
Per i sistemi che vediamo le grandezze sono quasi tutte legami di tipo lineare, per questo motivo ha un’importanza
specifica. La regressione lineare è un test che viene molto usato per vedere se c’è un trend in un certo campione
(sostanzialmente un trend è un andamento crescente che non è visivo graficamente). È un modello parametrico, e i
modelli parametrici si pongono nelle assunzioni del teorema del limite centrale; quindi, anche qui parliamo di
campioni o osservazioni parleremo sempre di random sample.
Posso anche trovarmi nelle ipotesi di una popolazione con distribuzione normale oppure con il teorema del limite
𝜎
centrale, per un grosso numero di campioni, possiamo avere la distribuzione normale con la deviazione standard se
√𝑁
𝑠
la conosciamo; altrimenti è .
√𝑁

Qual è il nostro campione in questo caso? Una coppia di valori, alcuni sono risposte ed altri sono predittori. La
regressione può essere lineare o non lineare e cerca di costruire un modello che spieghi la connessione tra predittori e
risposte. Nella simple linear regression c’è un solo predittore e una sola variabile di risposta.
Che vuol dire predittore? E che vuol dire variabili di risposta?
Y sono le variabili di risposta, X sono i predittori.
Se guardo i grafici, ho un insieme di valori osservati (sono delle estrazioni da una popolazione) e anche se il legame è
lineare estraendo campioni a caso, posso estrarre dei campioni che non hanno proprio distribuzione lineare.
Nella prima immagine in alto a sinistra, e in quella centrale vedo che i punti sono vicini alla retta e ci può essere un
legame lineare. Mentre nel terzo caso in alto a destra, probabilmente potrebbe non esserci legame lineare e il
modello regressivo non sa spiegare il legame risposta predittore.
NOTA BENE: Tuttavia, occorre fare una precisazione su cosa intendiamo per modello buono e non buono. Non
valutiamo la bontà di un modello a seconda se esso “passa” sui punti o meno (vedi grafico), piuttosto per noi un
modello è tanto più buono quanta maggiore variabilità dei dati si porta dentro.
Prendiamo in considerazione il grafico precedente e mettiamo in evidenza ulteriori dettagli. Quando si costruisce un
modello regressivo, posso trovare degli scatter plot.
Ma che è uno scatter plot? Data una retta regressiva candidata ad esprimere il modello, lo scatter plot indica l’errore
che facciamo se approssimiamo un punto 𝑦𝑖 con un punto della retta; mi fa vedere gli scarti che posso compiere nel
seguire la retta (errore negativo ho scarto con −, errore positivo scarto con +).

Scatter plot o modellazione dell’errore

Vediamo uno zoom dello scatter plot. Ho la retta regressiva, e ho un punto specifico in cui sto facendo predizione.
Il segno sul grafico è la risposta predetta, mentre la
risposta osservata è il punto compreso tra Measured y e
Estimated y. Che errore commetto approssimando la
risposta osservata con la predetta? È la distanza (error)
tra i due.
Il modello è un modello lineare e quindi 𝑦̂ = 𝑏0 + 𝑏1 𝑥,
ovviamente c’è un errore in realtà la y vera è pari ad 𝑦̂ +
𝑒𝑟𝑟𝑜𝑟𝑒. Abbiamo che 𝑏0 , 𝑏1 sono parametri regressivi
(parametri della retta che deve descrivere, e predice, il
comportamento di Y rispetto ad X).
I campioni sono fatti da coppie {𝑥𝑖 , 𝑦𝑖 } e la risposta
predetta la chiamo 𝑦̂ e voglio approssimare la risposta
con una retta. Facendo questa approssimazione
commetto l’errore residuo 𝑒𝑖 = 𝑦𝑖 − 𝑦̂𝑖 .
𝑏0 , 𝑏1 sono parametri randomici, e noi vogliamo capire
qual è il loro intervallo di confidenza.

Voglio fare un modello di previsione, il problema non è il fitting, devo capire quali sono gli intervalli di confidenza di
questi 𝑏0 , 𝑏1 . Questo è un modello di predizione che non è di fitting.
A seconda di 𝑏0 e 𝑏1 posso avere diverse rette, ricordiamo la formula della retta con il coefficiente angolare.
Vediamo però come calcolo questi parametri regressivi. Se vedo sul libro, dal primo modello statistico ad ora mi devo
sempre portare la varianza!
Come scelgo la retta regressiva?
1. Deve essere quella che minimizza la distanza lineare tra punti e retta e quindi in termini di scatter plot è
quella che è equidistante in media da tutti i punti.
Dire che è equidistante da tutti i punti vuol dire scegliere quella retta in cui la somma dei residui è nulla. Se sviluppo il
termine 𝑦̂ ottengo che la somma di 𝑦𝑖 − 𝑏0 − 𝑏1 𝑥𝑖 = 0. Ho un equazione a due incognite, potrei così ottenere tante
rette che minimizzano la distanza tra i punti!
Devo trovare una seconda equazione e quale diamo?
2. Quella che minimizza la devianza. La devianza dell’errore si chiama SSE e sta per sum of squared error.
Voglio minimizzare la SSE e devo associare alla prima una seconda equazione; quindi, devo trovare un modo
per minimizzare e come si fa? Prendo la derivata dell’equazione e la metto uguale a 0. Sostanzialmente è
questo che andremo a fare.
Dato l’errore zero, devo sostituire, si differenzia l’SSE e si pone uguale a 0. Quindi abbiamo la seconda equazione.

I parametri sono quelli nell’immagine seguente:

È un modello regressivo che non solo annulla l’errore medio, ma minimizza anche la varianza dell’errore e quindi
porta con sé la maggior parte della varianza. Intuitivamente questa congettura non è semplice da dimostrare e
soprattutto quando ci sono più predittori, ed esiste una correlazione tra loro, non è semplice allocare la varianza tra i
predittori, variabili di risposta e le variabili osservate.
Continuiamo con il nostro esempio semplice e quindi questo è il modello regressivo.
ESEMPIO: Supponiamo di aver effettuato una serie di misure di tempi di Disk I/O e tempi di CPU (osservazioni) in
seguito all’applicazione di 7 workload ad un sistema.

È un modello che sfruttando l’esempio con operazioni su disco e tempo di CPU ho dei tempi che rilevo da un monitor
e li grafico uno rispetto all’altro. L’andamento è più o meno lineare e applico un modello regressivo, ATTENZIONE io
per applicare un modello regressivo lineare devo prima osservare i dati. Applico un modello regressivo, non lineare
se non lo sono. I tool tipicamente che mi fanno fare? Mi fanno vedere i punti come sono posizionati. Calcola il modello
regressivo e se vado a vedere la somma degli errori ottenendo quindi una retta equidistante da tutti i punti e l’errore
quadratico è quello minimo.
 𝑏
OSS: Sappiamo che se il rapporto 𝑏1 ≠ 0, la retta ha una certa pendenza (come in questo caso
0
0.2438
( ≠ 0): questo vedremo che è molto importante per capire se c’è un trend nei dati.
−0.0083

Graficamente, la retta regressiva sarà quella di sopra (Avendo posto le condizioni viste in precedenza nel calcolo dei
parametri 𝑏0 e 𝑏1 , il modello è tale che la retta possiede errore medio nullo (equidistanza tra retta e osservazioni) e
SSE minimo).
Vediamo un poco la locazione della variazione.

Allocazione della variazione

Abbiamo detto che, minimizzando l’SSE, minimizziamo la devianza dell’errore. Dimostriamo ora che se minimizziamo
la devianza dell’errore (SSE), allora massimizziamo la devianza totale portata nel modello regressivo (SSR). (Questo ci
permette di dire che questo modello è il migliore possibile perché porta con sé tanta variabilità).
L’errore che cos’è? Sempre differenza tra risposta osservata e predetta.
La devianza dell’errore si esprime come sommatoria dello scarto quadratico e come è allocata questa varianza? Posso
dire che la devianza totale SST è la devianza di tutto il modello ed è data da SSR+SSE dove SSR è quella del modello
regressivo ovvero (𝑦𝑖 − 𝑦̅)2 . Si può dire che la varianza spiegata dal modello regressivo SSR, ovvero la devianza totale
meno la devianza dell’errore (𝑦̂ − 𝑦̅)2 . In altre parole, si può dimostrare per il modello regressivo lineare semplice che
la devianza totale SST è pari alla devianza spiegata del modello più la devianza dell’errore.

A sua volta la SSR è data da SST-SSE. (SSE è la devianza dell’errore).

Se noi abbiamo imposto in un modello statistico la minimizzazione dell’errore quadratico medio, quello che sto
dicendo è che il mio modello SSR sia il più grande possibile e che spieghi la maggior parte dei miei dati SST.
Questo possiamo vederlo sia per costruzione.
Se per ogni campione faccio questo gioco posso dire che per costruzione 𝑆𝑆𝑇 = 𝑆𝑆𝑅 + 𝑆𝑆𝐸.

Se voglio dimostrare che vale per qualsiasi N (numero di osservazioni) si può fare, per i più curiosi c’è sulle slide e devo
dimostrare che i primi due termini sono nulli.
Il primo è semplice e deriva dal fatto che la somma degli 𝑒𝑖 = 0, per il secondo è un poco più contorto però si può
cercare la spiegazione. Usando anche l’integrale per parti mi apparo anche la dimostrazione per N.
Nel modello regressivo semplice si può dimostrare che la devianza tot = devianza del modello + devianza dell’errore.
Se faccio il rapporto tra SSR e SST ho un rapporto tra devianze che è uguale ad un rapporto di varianze e mi dice
quanta varianza porta dentro il modello rispetto alla totale.

Bontà di un modello regressivo

La bontà di un modello regressivo si esprime attraverso il così detto coefficiente di determinazione 𝑹𝟐 , dato dal
rapporto di SSR ed SST

Tale coefficiente indica la percentuale di variabilità spiegata dal modello regressivo. Quindi se 𝑅2 = 0,99 allora il 99%
della varianza è spiegata nel mio modello ed è un buon modello. In genere i tool hanno un altro valore che è adjusted
𝑅2 il quale tende ad essere più robusto alla crescita dei regressori.
TIPICA DOMANDA D’ESAME
𝑅2 può essere basso? Dipende dall’utilizzo che dobbiamo fare del modello regressivo:
• Se vogliamo utilizzare il modello regressivo in termini di predizioni, dunque vogliamo che la retta regressiva
rappresenti bene i nostri punti, allora ci interessa un 𝑅2 𝑎𝑙𝑡𝑜
 • Se vogliamo utilizzare il modello regressivo per fare trend detection, il coefficiente 𝑅2 𝑝𝑢ò 𝑒𝑠𝑠𝑒𝑟𝑒 𝑏𝑎𝑠𝑠𝑜.
Occorre però verificare la significatività dei parametri della retta regressiva: se essi sono significativi, allora si
può dedurre che vi è un trend. [vedremo dopo cos’è la significatività]
Quando 𝑅2 è basso? All’aumentare del numero di punti, perché SSE soffre del problema di overfitting, dunque più
aumenta SSE, più SSR diminuisce e dunque anche 𝑅.
COME SI CALCOLA LA DEVIANZA TOTALE?

Questa qui è la somma degli errori quadratici, La SST è uguale alla somma di questi e si scrive come sommatoria degli
(𝑦𝑖 − 𝑦̅)2 .
La SS0 è la somma dei quadrati delle medie. Vediamo l’esempio rispetto ai dati di prima:

Questa roba non la dobbiamo dimenticare per i nostri homework. Sul sito c’è uno script per fare tutti questi calcoli.
Se devo farlo a manella guardo le slide.
Vediamo se questo modello è buono per descrivere l’andamento fra 𝑥𝑖 e 𝑦𝑖 appartenenti ad una popolazione e quindi
capire se questo modello è buono per inferire una relazione lineare, partendo dal campione. Per fare questo
dobbiamo procedere per passi, devo capire quali sono gli intervalli di confidenza e capire se i parametri regressivi e
gli intervalli di confidenza non contengono lo 0, quindi l’ipotesi di media nulla può essere rigettata.
Deviazione standard (Varianza) dell’errore
La prima cosa da capire è la deviazione standard e l’errore. I gradi di libertà sono importanti perché dati N campioni
sono N-1 sono indipendenti. Nel caso della regressione, siccome un modello di regressione ha 1 grado di libertà
(poiché avendo due parametri 𝑏0 e 𝑏1 , scelto un parametro, allora ho 1 grado di libertà per scegliere l’altro
parametro) allora il numero di gradi di libertà dell’errore è 𝑛 − 2.
√𝑆𝑆𝐸
Quindi, se volessimo calcolare la deviazione standard dell’errore, (MSE, mean squared error), si ha che 𝑠𝑒 =
𝑛−2

Quindi, se SST (la quale è relativa campione, poiché ricorda che SST è sempre sul campione) ha 𝑛 − 1 gradi di libertà, e
se SSR ha 1 grado di libertà, allora SSE avrà necessariamente 𝑛 − 2 gradi di libertà per far valere l’equazione 𝑛 − 1

Intervallo di confidenza dei parametri

Abbiamo detto che la retta regressiva che abbiamo costruito approssima (stima) il campione, il quale a sua volta non è
altro che una estrazione a partire dalla popolazione. Tuttavia, per i nostri scopi, siamo interessati a individuare una
retta regressiva che approssimi bene la popolazione (non il campione). A tal fine, occorre capire qual è l’intervallo di
confidenza all’x% sia dei parametri di regressione sia della response variable.
Andiamo ora a vedere, il problema statistico di quanto la regressione spieghi un legame a livello di regressione. I
coefficienti di regressione 𝑏0 e 𝑏1 sono stimati da un singolo campione di dimensione 𝑛, ovviamente se scelgo altri 𝑛
campioni il modello può essere diverso! Quando dico che il modello regressivo più o meno conferma un andamento
nella popolazione? Quando i nostri modelli regressivi variano di poco.
Supponiamo che 𝛽0 e 𝛽1 siano i valori della popolazione per cui viene spiegato questo comportamento lineare 𝑦 =
𝛽0 + 𝛽1 𝑥. I parametri 𝑏0 e 𝑏1 sono una stima di 𝛽0 e 𝛽1 rispettivamente.

Se conosco tutte le beta posso costruire il mio modello regressivo che spiega il comportamento lineare tra tutta la
popolazione Y e il mio X.
Questo è quello che è un modello inferenziale regressivo, in altri termini se oggi voglio sapere come vanno i contagi
devo avere 𝑏0 e 𝑏1 e devo capire questo campione quanto è lontano da 𝛽0 e 𝛽1 . Devo capire se riesco ad inferire questi
parametri dal campione.
Posso calcolare gli intervalli di confidenza dei parametri regressivi è come se io facessi un’ipotesi su ogni campione che
il valore 𝛽0 di un campione sia diverso da 𝛽0 (secondo me qui si è confuso ed intendeva 𝑏0 ) e voglio capire con che
probabilità rigetto l’ipotesi nulla.
Ad esempio, l’intervallo di confidenza è X,Y al 95% e nell’intervallo è contenuto 𝛽0 . L’intervallo di confidenza lo prendo
dai miei campioni e lo calcolo dal campione.
Ho un campione, calcolo l’intervallo di confidenza. Se l’ipotesi è rigettata dico che nel 95% dei casi il mio 𝛽0 è
contenuto là dentro.
Se vediamo i dati covid marzo 2020 delle previsioni sono ampissimi, perché l’incertezza sui dati è enorme.
Se l’intervallo di confidenza include lo zero, non posso considerare il parametro differente da zero al 𝟏𝟎𝟎(𝟏 − 𝜶)%
di confidenza.

Perché il fatto dello zero è importate? Se 𝑏0 = 0 la retta regressiva è orizzontale. Non devo avere sempre una
perfetta retta regressiva (dopo vedo dei dati, dove è difficile dire che un modello regressivo ha o no un trend).
Ad esempio, nella slide successiva calcoliamo l’intervallo di confidenza dei predittori e se è molto largo non è detto
che la retta regressiva sia buona. Ricordiamo che JMP possiamo forzarlo a darci questo valore, Matlab e altri no.

Visual tests for Assumptions

La regressione si basa su un insieme di assunzioni. Verificare che tali assunzioni siano precisamente soddisfatte
matematicamente può essere troppo complesso, dunque, si preferisce adottare dei test visuali.
Cosa ci permette di adottare tali test? C’è una notevole robustezza dei predittori rispetto alle assunzioni ossia se le
assunzioni non sono proprio esatte, il modello è comunque robusto.
All’inizio ha detto che con i modelli regressivi resto nell’ambito parametrico, ma ripetiamo le assunzioni di questo
modello. Assunzioni per cui applico e mi posso fidare dei risultati del modello regressivo (il titolo della slide è visual
test for assumption). Negli homework un sacco di gente fa i test statistici di indipendenza o indipendenza, quando poi
basta fare visual test (tutto è robusto ai test visuali).
1. La prima assunzione è che ci deve essere una relazione lineare tra la variabile di risposta Y e il predittore X.
Uno sguardo ai dati prima di applicarlo lo devo fare e devo vedere nei dati se ci sta o no questo andamento
lineare. Posso comunque applicare un modello regressivo se non sospetto il legame lineare perché voglio
vedere se ci sta un trend. (ci assicura che funziona).

2. Il predittore non deve avere un errore di misura e devono essere indipendenti, non che non si possa
risolvere ma mi complico la vita. Si fa in genere un random sample del predittore o si usano dei modelli di
bootstrapping dei parametri per avere parametri buoni

3. Gli errori devono essere indipendenti. Ce lo può lasciare come esercizio di ragionamento a partire dal
teorema del limite centrale.

4. Gli errori devono essere indipendenti e distribuiti normalmente (omoschedasticità = distribuzione normale
con media nulla e deviazione standard costante APOTEOSI DI INDIPENDENZA).

I sistemi di monitoraggio non devono essere troppo invasivi, se mi polarizzano le misure perdo la omoschedasticità.
Nella sicurezza profilare i tempi di risposta di un antivirus è difficile, siamo ancora lontani da una soluzione perché se
voglio fare delle analisi devo mettere dei sistemi invasivi.
Vediamo degli esempi per effettuare delle assunzioni visive:

• Relazione lineare tra y ed x, la possiamo verificare velocemente con uno scatter plot.
Vediamo degli esempi, (a) potrebbe essere lineare (b) lineare con spezzata (c) lineare con outlier (d) non lineare. Per
l’indipendenza degli errori vediamo la slide, ma possiamo farlo sostanzialmente in due modi:
1. Plottando i residui in funzione delle risposte predette e osservare che non ci siano trend

2. Plottare i residui con i numeri degli esperimenti ed è più facile

• Indipendenza degli errori, per verificarla basta fare uno scatter plot del residuo (errore) in funzione della
response variable: affinché ci sia indipendenza degli errori non ci dev’essere trend.

Come vedo la presenza di un trend oppure no? È inutile fare test non parametrici, facciamo direttamente una stima
lineare e se la retta ha un coefficiente lineare o meno, se è 0 la retta è orizzontale e non c’è trend.
L’altra possibilità è fare uno scatter plot del residuo (errore) in funzione del numero di esperimenti: affinché ci sia
indipendenza degli errori non ci dev’essere trend. La presenza di trend o meno la verifichi visualmente.

• Errori distribuiti in modo normale, Per verificare se l’errore è distribuito in modo normale, basta verificare
tramite un q-q plot se i quantili del residuo si posizionano similmente ai quantili della normale (Tool come
JMP forniscono e che ci permettono in modo molto veloce di verificare visualmente se è normale)

• Deviazione standard costante, conosciuta come omoschedasticità.

Per verificarlo basta osservare lo scatter plot tra l’errore (residuo) e la predicted response. Se la diffusione in una parte
del grafico è visivamente differente da quello in un'altra parte del grafico, ciò porta a dire che la distribuzione degli
errori non è costante ma dipende dalla predicted response.
La deviazione standard costante può essere vista come un assenza di trend tra residui e risposte predette.
Anni fa, non vide la parte che faceva all’inizio Liguori e lui che faceva? Svolgeva gli esercizi e faceva fare il test di
normalità e diceva fate tutti quello che volete. Venne la gente a fare l’esame e nessuno aveva superato il test di
normalità. Probabilmente, avendo pochi campioni Kolmogorov non fa passare il test di normalità. Il test di normalità
lo posso fare solo in un caso in cui non sono sicuro che ho un random sample. Il test di normalità serve per vedere se
ho preso cose indipendenti, poi passo al test visivo. Se voglio aspettare un test di normalità su dati normali, mi faccio
vecchio.

Altri modelli Regressivi, Regressione multi lineare

Nel modello regressivo multi lineare mi accordo che c’è sì un legame lineare, ma non da una singola retta ma da più
rette. Questo modello ha una variabile di risposta e più predittori e può essere espresso dall’equazione nella slide.

Anche qui ho delle osservazioni, se avevo una coppia prima ora è una ennupla con n-1 predittori e una variabile di
risposta. Ora se invece di X associo una matrice posso far valere le stesse cose dette in precedenza.
Anche in questo caso si vuole individuare la miglior forma lineare 𝑦 = 𝑿𝑏 + 𝑒 con 𝑿 matrice ed 𝑒 errore, tramite la
scelta di opportuni parametri regressivi. Come per il caso lineare semplice si deve:
1. Imporre l’errore medio pari a zero
2. Minimizzare la somma degli errori quadratici
L’unica cosa che dà fastidio in questi modelli è la multicollinearità, che afferma che se i predittori sono linearmente
dipendenti ovvero vi è correlazione tra loro:
1. Non possiamo più dimostrare l’indipendenza dell’errore
2. Non possiamo più dimostrare che SSR = SST - SSE

Per eliminare il problema della multicollinearità:

• Si calcola la correlazione tra i predittori ed eliminiamo manualmente i parametri correlati

• Facciamo una PCA e in seguito facciamo una regressione sulle componenti principali (ma così facendo si
complica il problema)
ATTENZIONE, Se prendo l’esempio e voglio capire la problematica
 .
Capita la problematica vado come un treno a fare i modelli regressivi. Guardiamo il campione, ho tre dimensioni:
T.CPU, T.DISCO, Dimensione della memoria. Faccio il modello regressivo e ottengo con il calcolo dei parametri il
modello regressivo con anche gli errori.
Che problema ho? Se 𝑅2 è nel 97% nel modello non è vero che 𝑅2 spiega il 97% dei dati perché con più predittori ho
multicollinearità (ovvero dipendenza tra i dati).

Nel nostro caso 𝑅2 si gonfia perché c’è dipendenza tra i dati, e se c’è dipendenza fra i dati 𝑅2 è drogato. Quando faccio
i modelli regressivi devo stare attento che non ci siano fenomeni di correlazione tra i dati e come faccio? Qualcuno
potrebbe dire facciamo PCA, si fa ma dipende dai dati e se teniamo ferma la dimensione del problema. Devo eliminare
le linee che mi danno più fastidio e devo capire se quei valori possono essere evitati. È una cosa non semplice e
lasciata a noi.
LEZIONE 14 28/10/2021
Vediamo qualche esempio sulla regressione lineare incominciando con un esercizietto dove vediamo le prestazione di
un mail server con fenomeni di degradazione della memoria al crescere di thread della virtual machine.
Questi dati vengono da uno studio comparativo tra windows e linux e ho in una colonna la quantità di heap e la
quantità di thread attivi. Vediamo se si può fare un modello di regressione lineare e iniziamo a studiare questo
campione reale.
Posso fare un analisi o multivariata o stimare Y rispetto ad X ed è proprio il regressivo. La variabile di risposta è il
numero di thread e l’heap è il fattore; voglio vedere se c’è una relazione o un trend crescente/regressione lineare tra X
ed Y.

Questo è un sample vero, e quando analizzo dati reali mi trovo in questa situazione. La prima cosa che mi conviene
dire è: ci sono dei legami lineari(In questo caso posso avere degli outliner che elimino)?
Si ci possono essere, ovviamente JMP fa vedere prima i grafici perché prima capisco di che pasta sono fatti i dati e poi
posso applicare lo specifico modello regressivo che secondo me va meglio. Nel nostro esempio posso applicare la
lineare e facciamo sta stima lineare.
Questa stima, fa sì che il tool disegni la retta regressiva in rosso. Prima di vedere le assunzioni del modello regressivo
facciamo un giro per vedere se nel caso in cui le assunzioni sono verificate se mi posso fidare di questo modello.

𝑹𝟐 è 12% e come modello statistico si porta dentro poca varianza, la differenza con 𝑹𝟐 corretto è poco e quindi non
ci sono polarizzazioni e ho un solo predittore.
La retta ha un coefficiente positivo (lo notiamo dentro il tratto “stima lineare”) quindi ci può essere un trend. Se c’è un
trend, che a crescere dei thread cresce l’heap, posso avere un problema di esplosione dell’heap e potrebbe
sovrascrivermi lo stack; e questa è un analisi anche di sicurezza. Se ci sta un trend del genere posso far crashare l’app
perché l’heap “fa a capate con lo stack”, c’è un trend perché il coefficiente angolare della retta è positivo.
C’è anche 0.002 che nel modello porta un p value piccolo e quindi ho un’alta confidenza che quello è il valore.
Questo valore regressivo ci dice che c’è un trend e posso dire che tale trend può essere statisticamente significativo.
Ora devo stimare i residui.
Quali sono i residui? Per i residui sulla variabile di risposta ho più o meno uniformità e sembra non esserci un trend e
sull’esperimento anche sembra che sia buono. I problemi che abbiamo sempre sono sul qqplot

Per capire o si fa un test non parametrico, oppure un trucco del mestiere vedo quali sono i punti e se sono outlier
provo ad eliminarli se non sono influenti. Mi prendo quindi quelli in alto a destra e me li studio sugli altri diagrammi,
noto che sono tutti esterni. Mentre quelli che si trovano all’inizio del grafico se rapportati con i grafici precedenti
vediamo che hanno un carico insignificante e potremmo tranquillamente ignorarli.
Vediamo adesso se dal punto di vista di consumo di heap, a parità di workload, Windows e Linux si comportano allo
stesso modo.
Cosa dovremmo fare? Molti generebbero un grafico facendo la stima di Y rispetto ad X e ragionerebbe su un grafico
che praticamente non permette di capire nulla
Invece sul grafico mostrato precedentemente posso dire un sacco di cose, prima di tutto in Linux i fuori range sono
minori. Ci sono condizioni che hanno portato problemi su entrambi i sistemi, ma la media è un indice più affidabile in
windows o in Linux?
In windows perché la componente media spiega più varianza. C’è un comportamento diverso? O è solo dato dal
caso?
Partiamo scrivendo l’intervallo di confidenza al 95% ? sì e vediamo che non si sovrappongono quindi c’è un
comportamento diverso
Potevo fare in un altro modo facendo un test di ipotesi sulla media. Ad esempio, se prendo la media di windows
pari a 6555071 e faccio un test di ipotesi sul campione; non metto la deviazione standard perché non la conosco e
vedo che la probabilità sia maggiore è alta e viene dunque rigettata l’ipotesi della media.
Sono test collegati, infatti l’intervallo di confidenza che esprime un intervallo in cui l’ipotesi può essere rigettata è pari
a test di ipotesi e al Pvalue, che è la più piccola probabilità che l’ipotesi nulla venga rigettata.
Stiamo usando test parametrici. Vediamo il diagramma dei quantili normali ed è un’opera d’arte perché i test sono
fatti abbastanza bene.

Per tirare questi dati ci hanno messo 8 mesi circa.

Esempio PCA e Clustering studentə
Inizia ora la presentazione dei ragazzi sul PCA e Clustering.

Sono partiti dal dataset del prof e ogni colonna corrisponde ad un parametro e riporta anche il link per chi vuole
approfondire i parametri. In grassetto i parametri costanti che sono stati levati. I valori costanti che ho eliminato ora,
li elimino anche del workload sintetico? No, li levo solo per la mia analisi ma fanno parte del workload.

La colonna SLAB ha molti valori costanti ad eccezione di 2 osservazioni su 3000, sono state quindi analizzate attraverso
il comando “Distribuzione” e si è notato come fossero 2 outliers e non mostrando un carico particolare le hanno tolte.
Se seleziono un outlier su jmp me lo fa vedere in tutte le distribuzioni così nell’ipotetico caso risulti difficile da capire
in una distribuzione posso vederla in un’altra. (Inizialmente queste due colonne erano state tolte, ma quando hanno
visto che c’erano 2 outlier hanno pensato che forse servisse, invece no e hanno tolto lo stesso).
Cotroneo, lo fa tornare indietro e gli chiede perché questo punto, che per me è un outlier, non lo trovo come outlier in
writeback? Non è strano? No, perché sono parametri diversi, o meglio queste due dimensioni sono non correlate. Se
vediamo che in un punto ci sono degli outlier e in un altro no è proprio perché le dimensioni non sono correlate.
Per vedere la correlazione procediamo con la matrice di correlazione, nello specifico vediamo solo i due di interesse
Slab e writeback.
Sono incorrelati proprio perché a 45°. Anche nella matrice vedo che il coefficiente di correlazione è molto basso.
Prima giustifico gli outlier e poi li elimino.
Altri outlier sono relativi alla prima riga che presenta un carico basso e per questo li hanno eliminati.

Altra considerazione per gli outlier di MemFree che corrispondono alle prime 84 righe del dataset e inizialmente si
pensavano essere un regime di basso carico del sistema e che potevano essere eliminati. Ma in corrispondenza di
questi c’era alto writeback e allora hanno pensato che forse sia una sorta di transitorio.
Il parametro di VmSize indica la somma dello spazio di indirizzamento logico di tutti i processi all’interno del nostro
sistema e ci dice che il sys sta lavorando a basso carico.
Osservando writeback hanno visto che sono per l’altro parametro e quindi a causa di un elevato numero di cache miss,
e allora era per questo. Man mano che la memoria va a regime, il writeback si stabilizza e sono tutti felici.
Non li hanno tenuti e non eliminati anche se forse era opportuno non considerarli. C’è una piccola fase di transizione
iniziale, questo lo vedo sempre! C’è un ramp up verso la situazione di regime. Quando vado sul cloud computing,
vedo che si adeguano al carico. Quello che fa paura è la velocità con cui cambia la richiesta di prestazioni e questa
isteresi mette in difficoltà queste piattaforme (quindi in cloud il ramp up è bene tenerlo sott’occhio).
Dopo questa analisi e aver diminuito il dataset da 24 a 19 colonne hanno fatto la PCA e hanno considerato 3
componenti principali con una percentuale cumulativa di 87%. La domanda che sorge spontanea ora è: se abbiamo
ridotto il dataset a 19 colonne, perché negli autovalori ne abbiamo solo 18? Vediamo la matrice di correlazione e
vediamo che il valore tra writeback e memFree è esattamente 1, quindi significa che vi è una dipendenza lineare tra
le due variabili.
Abbiamo ridotto con la PCA e devo ora fare il clustring e vediamo di ridurlo pure nei valori e vediamo che da 60k punti
a 6k punti.
All’inizio avevamo pensato di usare tre componenti principali però per l’analisi di sensitività hanno preso circa cinque
componenti. Attraverso i loading plot hanno visto che AvgElapsed era molto importante.

I primi due cluster rappresentano forse il transitorio del sistema, mentre dal 3° cluster il sistema è a regime e per
clusterizzare hanno usato il metodo di Ward, che fa minimizzare la varianza intragruppo e massimizza intergruppo.
Che cosa vuol dire scegliere dove ho cinque cluster e dove ho una trentina di cluster? (Dal grafico è vedere le linee
che si congiungono) Che cosa cambia il numero di cluster?
Diminuire la varianza intragruppo vuol dire aumentare il numero di cluster. Spostandomi da destra verso sinistra, la
varianza intragruppo diminuisce o aumenta? Diminuisce.
Se mi metto ad inizio grafico quanta varianza perdo? 0%, e se mi metto alla fine il 100%. Se mi metto in mezzo la
metà. Non mi servono tecniche e calcoli un poco di osservazione mi appara.
Prima dei risultati possiamo espandere in maniera personale i valori, che cosa cambia se scelgo 2PC e 6 cluster o 3PC
e 6 cluster? Aumentato i componenti principali diminuisco la devianza persa. C’è un legame sempre lineare tra il
numero di componenti principali ed il numero di cluster? Se tolgo da una parte recupero dall’altra? Già da questo
primo grafico dei risultati ho scoperto che non è così.

La linea tratteggiata è la devianza portata con PCA con 3,4,5 componenti mentre la continua è quanto ci avviciniamo
alla devianza con 3,4,5 cluster.
Quando facciamo un grafico, mettiamo le etichette in ascisse e ordinate. (Buona abitudine).
Qui sulle ascisse ho il NUM DI CLUSTER. E quindi i punti di mezzo non mi servono il dato è categorico e quindi mi
servono 1.5,2.5 etc (Consigli di cotroneo). Perché se prendo 4 cluster perdo meno varianza con 4 componenti
principali che con 5 (da vedere la matrice in alto a destra) visto che dovrebbe decrescere (parla del punto con valore
23.4144 e 21.9070)?
La devianza persa dovrebbe decrescere.
Scelgo 3 componenti e con 3 cluster la devianza persa è 43,69 ma con 4 è 47,63. Ma non dovrebbe diminuire? Il
problema è che non è apprezzabile per come hanno fatto clustering e hanno preso cluster non apprezzabili. Ma può
essere che perché l’angolazione a fine grafico era maggiore per il grafico 5

Qui abbiamo i conteggi che sono sbilanciati, abbiamo quindi bisogno di avere un numero di cluster maggiore,
potrebbe essere la soluzione.
Poi c’è la rappresentazione del Workload Sintetico dove mostrano la varianza spiegata ed è fondamentale senza di
esso non chiuderemmo il cerchio.
LEZIONE 15 29/10/2021 (Lecture_7_IE_new)
Experimental Design and Analysis Parte 1
Vediamo che significa fare il Design Of Experiments, noi infatti abbiamo sempre parlato di fare sperimentazione ma
non è che abbiamo mai avuto delle linee guida con cui si fanno questi esperimenti.
Oggi vediamo l’introduzione e il design full factorial, di tipo 2𝑘 e 2𝑘 𝑟 e anche quello frazionario, mentre gli ultimi due
li vediamo nella prossima lezione.
Partiamo dall’inizio ovviamente, che cos’è un esperimento? Un esperimento viene definito come un test in cui io, che
sono l’analista interessato a quello che avviene, voglio capire come la variabile di risposta ad una variabile di uscita
di un sistema possa variare andando a modificare una serie di fattori che posso controllare; nel senso che posso far
variare. Sono interessato all’output dato un input, e voglio capire come questi fattori controllabili 𝑥1 , 𝑥2 , … , 𝑥𝑛
vadano ad influire sul valore delle variabile di risposta.

Supponiamo di avere un sistema (il nostro PC) che fa un determinato lavoro e sto misurando le performance in X o in
determinati secondi perché sono interessato a capire quanto tempo impiega per svolgere un determinato lavoro.
Quali possono essere i fattori controllabili in questo sistema?
La dimensione delle risorse può essere l’input, il carico anche posso vederlo come parte del workload e quindi come
input.
I possibili input sono:

• I fattori controllabili sono la memoria del nostro sistema o il numero di processori, ossia quelli che possiamo
controllare e che riusciamo a far variare. In VM posso cambiare questi fattori e vedo come cambia l’output.
• I fattori NON CONTROLLABILI su cui non posso fare nulla, ovvero disturbi o fattori non controllabili e quindi
nel nostro esempio traffico sulla rete, utilizzo di risorse etc.

Un esempio tipico è lo strumento di misurazione, Anche lo strumento di misurazione, mi può restituire un errore.
Usare uno strumento di misurazione anziché un altro mi dà risultati diversi.
In questo design of experiments ci focalizziamo sui fattori controllabili e mi interessa capire come l’output varia in
funzione dell’ingresso. Cosa più importante, oltre a capire che fattori sono più influenti sulla variabile di risposta, è
separare gli effetti dei fattori. Quando ho un esperimento e ho più fattori da valutare, il fattore A può influenzare il
fattore B e quindi diventa difficile valutare la variabile di risposta quando possa dipendere da:
• Quanto dipende da A
• Quanto da B
• Quanto dall’interazione A/B.
Oltre a separare i fattori l’altra volta ci ha detto che se faccio un esperimento senza ripetizioni non posso valutare
l’errore; quindi, l’unico modo per valutare l’errore è fare delle ripetizioni.

TERMINOLOGIA UTILE PER LA LEZIONE

• Variabile di risposta: quello che è l’output. Siamo interessati a capire come varia in funzione dei fattori.
• Fattori: variabili che influenzano la variabile di risposta
o Primari: di più interesse
o Secondari: minor interesse
• Livelli: sono il numero di valori che ogni fattore può assumere. Se ho una configurazione, ho il fattore
memoria che posso far variare nel mio sistema e può assumere 2GB, 4GB, 8 GB dico che il fattore memoria ha
3 livelli.
• Repliche: numero di ripetizioni
• Design: l’esperimento viene definito in base a tre valori:
o num_livello
o num_fattori
o num_repliche.
• Interazione: Dati due fattori ho interazione quando l’effetto di uno dipende dal livello dell’altro.

Un design viene definito come 𝐵𝑎𝑠𝑒 𝐸𝑆𝑃𝑂𝑁𝐸𝑁𝑇𝐸 ∗ 𝑅, dove Base = numero di livelli, Esponente = numero di fattori, R =
numero di repliche.
Se scrivo 2𝑘 è un design con k fattori e ogni fattore ha due livelli che moltiplico per R numero di ripetizioni.
Abbiamo parlato di interazione tra fattori che cos’è? La variabile di risposta può dipendere da fattore A, B o dalla loro
interazione.
Come capisco che due fattori possono interagire?
1. Ho A e B ed entrambi si possono trovare in due livelli (A1,A2, B1, B2). La tabella ci fa vedere che quando B si
trova al livello 1 (prima riga in alto), A al livello 1 vale 3 e al livello 2 vale 5. Mentre in B2 ho A1 al 6 e A2 al 8;
quindi, se cambio livello di B si ha un aumento di A (se vado da B1 a B2), graficando ho 2 rette parallele che
non si toccano mai e questo vuol dire che questi due fattori non interagiscono mai e non andranno mai ad
influire sulla variabile di risposta questi due fattori. E quindi i fattori sono non interagenti.
2. Nel secondo caso questo non avviene vedo infatti che A2 da B1 a B2 ha un aumento di 10 e allora non ho più
due rette parallele e ci va a suggerire che il fattore A è influenzato dal fattore B e viceversa. Quindi i fattori
sono interagenti.
Esempio pratico dal libro: sono in un design in cui ho un fattore CPU con 3 livelli, il fattore memoria con 3 livelli a sua
volta, il fattore disco con 4 livelli ho poi il workload applicato (3lv) e l’educazione dell’utente che è anch’essa a 3 lv.

Partendo da questo esempio che possiamo vedere come vado a classificare il nostro design of experiments in tre
categorie.

1. Simple design
Il nostro design è semplice e si chiama simple design. Ho 5 fattori e allora prendo per ognuno un livello e creo una
configurazione, dopo di che faccio un esperimento. Al secondo esperimento mantengo la configurazione di prima ad
eccezione di un fattore dove faccio variare un livello.
Il numero totale di esperimenti N, per un simple design, è dato dalla sommatoria in slide dove 𝑛𝑖 indica il numero di
livelli del fattore i-esimo.
Quindi applicando al nostro esempio ottengo 12 esperimenti. Allora con un simple design ho un totale di 12
esperimenti che è buono come numero. Però ha dei contro quali sono? che con un simple design non ho effettuato
tutte le possibili combinazioni perché facevo variare un solo livello di un solo fattore e quindi non tutti i livelli dei
fattori vengono confrontati con tutti i livelli degli altri fattori.
Se ho solo 2 fattori con 2 livelli che ottengo? Ho A1,B1 poi faccio A2,B1 e faccio A2,B2 ma mi sono perso la A1, B2 e
non saprò mai come si comporta la variabile di risposta.

2. FULL FACTORIAL DESIGN

In contrapposizione al primo caso faccio variare tutti i livelli di tutti i fattori e il numero di esperimenti N è dato da
una produttoria.
𝑛𝑖 indica il numero di livelli del fattore i-esimo

Se applicassi il full factorial al nostro esempio avrei 3 ∗ 3 ∗ 4 ∗ 3 ∗ 3 = 324 esperimenti. Che problema ho?
Misuro tutte le interazioni ma tengo troppi esperimenti così a secco e senza ripetizioni, se ci metto pure le ripetizioni
diventa infattibile realizzare un full factorial.

3. FRAZIONARIO
Questo parte dallo stesso tipo di design del full cercando di fare meno esperimenti.

Se prima veniva indicato con 3𝑘 (ho k fattori da 3 livelli) in questo caso il frazionario si indica con 3𝑘−𝑝 dove questo
meno p, che in base al proprio valore, mi modifica il numero di esperimenti.
Se p=1 gli esperimenti diventano 1/3, se p=2 gli esperimenti diventano 1/9 e quindi vado a diminuire di molto. Il
frazionario perde sempre delle informazioni sulle iterazioni; è una via di mezzo tra simple design e full. Nel
frazionario scelgo P in modo da avere un trade off tra numero accettabile di esperimenti e non perdere troppe
informazioni.
ESEMPIO da slide

Ogni livello, ognuno dei 3 livelli dei fattori, viene preso 3 volte. Questa tabella verrà vista per bene a breve e avremo
che A1, B1 si trova tre volte per questo specifico tipo di design.

𝟐𝒌 factorial design
Finita l’introduzione passiamo ad un design full molto utilizzato ed in particolare perché utilizza 2 livelli. Il design full
𝟐𝒌 è interessante da vedere perché ci fa capire come funziona con 2 livelli e può essere utile anche quando ho
tantissimi livelli per i fattori ma ne prendo solo 2, per semplicità di analisi, e in genere vanno a corrispondere al
valore minimo e massimo del fattore. Quindi supponiamo di avere fattori con molti livelli, se applichiamo questo
design prendiamo solo i due principali.
Esempio introduttivo: ho 2 fattori e 2 livelli sono in un design 22 . Dobbiamo capire come questi due fattori, memoria
e cache, vadano a influire sulla variabile di risposta Y. Le Y sono le performance del computer in MIPs.
Dalla tabella vedo il cache size che può prendere o 1kb o 2kb, poi ho i memory size che è di 4Mb o 16Mb.
Che succede? che la nostra variabile di risposta Y, quando sto in 1kb/4Mb vale 15, quando aumento la memoria e
passo da 4 a 16Mb le performance migliorano e passano da 15 a 45 stessa cosa con 2kb di cache e passo da 25Mips a
75 Mips.
La variabile di risposta Y la esprimo con i metodi regressivi lineari e quindi la vedo data dalla somma dei contributi (o
meglio effetti):

• 𝑞0 che è l’effetto medio, non dipende da un fattore specifico ed è la media delle performance
• 𝑞𝐴 𝑥𝐴 : dove 𝑥𝐴 è il fattore A (memory size) mentre 𝑞𝐴 è l’effetto del fattore A
• 𝑞𝐵 𝑥𝐵 : dove 𝑥𝐵 è il fattore B (cache size) mentre 𝑞𝐵 effetto fattore B
• 𝑞𝐴𝐵 𝑥𝐴 𝑥𝐵 : dove 𝑞𝐴𝐵 è dato dall’interazione tra A e B.

Dato che ho solo 2 livelli associo i due valori dei livelli -1/+1 ai due livelli 𝑥𝐴 e 𝑥𝐵 .
Se sto in 4MB 𝑥𝐴 vale -1,
se 𝑥𝐴 si trova in 16Mb vale +1.
Stesso discorso per 𝑥𝐵 che viene associato alla cache.
Quello che ci interessano sono gli effetti, e come li calcoliamo? Sostituiamo i valori delle 𝑥 in base alla configurazione
e sapendo il valore della variabile di risposta mi trovo un sistema di equazioni.

Avendo 4 incognite e 4 equazioni riesco a risolvere questo sistema e ho i valori per le varie 𝑞.
Che significa? Che le performance medie di 𝑞0 sono di 40Mips quindi il mio sistema fornisce performance di 40 MIPS.
L’effetto della memoria è di 20, della cache è 10 e l’effetto dell’interazione è 5.
Ho così modellato il mio sistema ed espresso dall’equazione finale di y mostrata nella slide.

Sign Table Method

Quando il numero di fattori e livelli diventa elevato come lo faccio il sistema di equazioni? Diventa impraticabile e
quindi adotto un’altra soluzione che si chiama tabella dei segni.

Come funziona? È una tabella che ha un numero di righe e colonne che dipende dal tipo di design. Nel caso di 2𝑘 ho 2
alla K righe e 2 alla K colonne. Nel caso di un design 22 avrò 4 righe e 4 colonne, anche se ne vedo di più nel nostro
esempio abbiamo che la y non si conta.
La prima colonna è unitaria poi seconda e terza sono dei due fattori e la quarta è data dall’interazione. Se avessi avuto
un altro tipo di design avremmo avuto magari otto colonne.
Viste le colonne ora passiamo alle righe, abbiamo che la prima è unitaria e la seconda la facciamo variare come le
tabelline dei bit. Dobbiamo coprire tutte le iterazioni. L’interazione è data dall’effettiva moltiplicazione dei valori dei
fattori.
La colonna y è stata aggiunta per aiutare i calcoli e va riempita in base alle scelte fatte. Ad esempio, il valore 160 non è
altro che il prodotto di elemento per elemento e lo vediamo nella slide.
Proprietà delle colonne:
1. la somma di tutti i valori in ogni colonna è 0. Per ogni colonna non faccio riferimento alla i-esima ma a quelle
dei fattori. È banale da verificare basta sommare i vari +1/-1.
2. La somma dei quadrati in ogni colonna è sempre 2𝑘 (dipende sempre dal tipo di design).
3. Ci permette di semplificare i calcoli. Le colonne sono ortogonali se moltiplico qualsiasi colonna per un’altra
colonna ho un risultato pari a 0.
Queste tre proprietà sono fondamentali.

Allocazione della variazione

Ricordando che l’obiettivo è capire come un fattore impatta sulla variabile di uscita è fondamentale comprendere
l’importanza dei fattori.
Parliamo quindi della devianza del nostro sistema, introduciamo un concetto che è fondamentale ed è l’importanza di
un fattore ovvero se un fattore esprime una buona percentuale di variazione rispetto alla variazione totale del
sistema.

Ricordiamo che i gradi di libertà sono 𝒏 − 𝟏 perché non mi servono tutti gli elementi per conoscere tutti i dati.
La SST (somma quadratica totale) è data dal numeratore della formula mostrata in slide, ma perché si scompone in
questi tre contributi? Innanzitutto, abbiamo detto che possiamo sfruttare le proprietà della tabella dei segni.
Il primo contributo 2𝑘 𝑞𝐴2 è detto SSA (somma quadratica di A) e lo stesso vale per gli altri due contributi. Come faccio
a dire che il fattore A è più importante di B? Vedo il rapporto tra SSA/SST e valuto la percentuale.
Sempre in riferimento all’esempio precedente abbiamo:
In questo esempio abbiamo che il 76% della varianza è da attribuire da A. (Non è 55 ma 45 nel calcolo di 𝑦̅)

Estensione a K-fattori
Siamo partiti dalla base con due livelli e due fattori, la stessa metodologica può essere estesa ad esperimenti con k
fattori, ognuno con due livelli. Le considerazioni fatte prima rimangono le stesse, anche se la tabella dei segni si
complica.

Vediamo l’esempio di prima del PC complicato con anche il numero di processori.

Non ho più 4 valori ma ne ho 8.

In questo caso non è cambiato nulla rispetto a prima; infatti, 𝑞0 lo calcoliamo con il dot product tra la colona i e la y.
La somma è 320 e devo dividere stavolta per 8.
Anche nell’allocazione della variazione abbiamo che la SST si può scomporre in varie parti dovute ai vari fattori e alle
loro interazioni. Le formule sono le stesse.

Perché diciamo che “consideriamo” la importanza? Perché non è un concetto statistico, dire che la memoria spiega il
18% della varianza è per me è importante ha un valore solamente relativo.

𝟐𝒌 𝒓 factorial design
Il caso 2𝑘 si può estendere al caso 2𝑘 𝑟 con 𝑟 numero di repliche. Lo diciamo ancora una volta, quando usiamo più
ripetizioni possiamo stimare il contributo dell’errore, la 𝑦 è uguale ai precedenti ma c’è un contributo 𝑒. QUANDO
NON EFFETTO RIPETIZIONI L’ERRORE C’è MA NON RIESCO A STIMARLO.
La tabella dei segni varia e diventa la seguente, supponiamo di avere tre ripetizioni e poi mi calcolo la media. E gli
effetti delle q verranno calcolati in base alla media.

Ma come andiamo a quantificare la e finale? L’errore viene definito come la differenza tra il valore che osservo e il
valore stimato, in questo caso la stima ci viene dato dal valore medio. Se guardiamo la prima riga abbiamo che
rispetto alla prima valutazione l’errore è 0 (15-15) nella seconda valutazione l’errore è 3 (18-15), e così via.

Avendo anche la ripetizione ogni misurazione non dipende solo dalla configurazione (riga) del sistema ma dipende
anche da un indice j che sta ad indicare la j-esima ripetizione. La risposta stimata è la stessa vista negli esempi
precedenti solo che prima coincidevano ora abbiamo ovviamente anche la media e quindi la formula è quella mostrata
in slide.
Ora che abbiamo stimato l’errore per ogni ripetizione e per ogni configurazione come facciamo a capire il contributo
sulla variabile di risposta? Sempre gli stessi passaggi con SSE

Facendo questa somma ottengo questo è l’ultimo contributo che devo andare a dare alla SST nel caso di ripetizioni.
Rimostriamo i calcoli fatti prima.

Il contributo dell’errore è detto non spiegato, prima questo 1.45% non è che era assente ma era confuso tra le
interazioni di A e B.

𝟐𝒌−𝒑 Fractional Factorial

Passiamo all’ultimo design che è quello di tipo frazionario, si parte da uno di tipo full e si va a sottrarre all’esponente
il valore p. Se p è pari ad 1 significa che sto facendo metà esperimenti, se 2 sto facendo un quarto degli esperimenti e
così via.
Vediamo un tipico esempio, dove partiamo sempre un due livelli mentre la lezione successiva vedremo livelli
superiori, con un design full che richiederebbe 128 esperimenti mentre noi se imponiamo p = 4 avremmo solo 8
esperimenti. Ma come si fa a passare da uno full a frazionario? Sfruttiamo sempre le proprietà della tabella dei
segni.

Abbiamo 8 colonne ed è lo stesso nel caso di full 23 solo che avere le interazioni abbiamo i nomi dei fattori. Questa è
una scelta che facciamo noi. Ovviamente questa tabella risulta tagliata perché non tutti i livelli del fattore A vengono
visti con i livelli del fattore G avendo solo otto combinazioni; e non posso coprire tutte le configurazioni. Più elevato è
p e meno interazioni calcolo.

Vediamo l’algoritmo per passare da una tabella full ad una tabella frazionata:
 1. Prepara la tabella dei segni per un design full factorial con k-p fattori
2. Marcate la prima colonna I come unitaria
3. Le prime k-p colonne le marchiamo con i k-p fattori
4. Le restanti colonne, che non ho ancora marcato, le marco con i p fattori rimasti. (Quindi nel nostro caso D =
AB, E = AC, F = BC, G= ABC)

Quello che è importante di questa lezione, per il design frazionario, è che la scelta su come sostituire i fattori con le
interazioni dipende da noi, non vi è una regola. Ci sono dei casi in cui il mio p è piccolo, in questo caso è due livelli,
quattro fattori ma dimezzo il numero degli esperimenti.

In questo caso entriamo nella così detta algebra di Confunding che è l’ultimo argomento per oggi. Dato che ho deciso
di confondere D con ABC, gli effetti di D e ABC sono confusi.

Algebra di Confunding
Ovviamente D ed ABC non sono gli unici effetti confusi perché se facciamo questa prova e vado a vedere la colonna
del fattore A e moltiplico colonna BCD mi trovo che hanno la stessa configurazione; questo perché avendo dimezzato
il numero di righe hanno gli stessi valori. Tale problema è normale proprio dovuto al dimezzamento.

Come faccio a capire quali sono gli effetti confusi? Parto dal polinomio generatore, le regole che si usano sono:
1. La colonna iniziale che vediamo è vista come la unitaria
2. Ogni colonna al quadrato è uguale alla colonna unitaria.

Questo I = ABCD è il polinomio generatore e mi permette di ricavare tutti gli altri effetti, mi basta moltiplicarlo per
qualsiasi colonna per ottenere i termini rimanenti. C’è una scelta migliore? No, ma esiste una convenzione che mi
permette di calcolare tutti gli effetti confusi.

Vediamo alcune definizioni, in I = ABCD la media viene confusa con l’interazione di ordine quattro, nel secondo caso
dove metteva D al posto di AB e il polinomio generatore era ABD la media era confusa con una interazione di ordine 3.
L’ordine di un effetto è il numero di fattori inclusi in esso.
Definiamo la risoluzione del design come il minimo ordine degli effetti che sono confusi. Come vedo l’ordine di un
design? Vado a vedere il polinomio generatore nel primo caso era ordine quattro nel secondo tre. La risoluzione si
indica con R e a pedice i numeri romani. Qual è la scelta migliore? Nuovamente non esiste nessuna indicazione che ci
indica cosa sia meglio fare, però la convenzione ci dice che un design di risoluzione maggiore è preferibile ad uno
inferiore.

La prossima volta vedremo la One-factor experiments dove non avremo più solo due livelli ma avremo un numero
diverso

Lezione 16 04/11/2021 (Lec_IE_DEP_1)

(quella del lunedì di questa settimana non si è svolta perché era festa)
Ha inizio oggi la seconda parte del corso ovvero, al parte di affidabilità. Se la parte di prima era no error free adesso
entriamo nel mondo ERROR FREE e facciamo argomenti che poi sono richiesti nel mondo del lavoro. Questo corso ci
deve permettere di raccordare con quello che troviamo fuori e se vogliamo possiamo chiedere stesso al prof numerosi
approfondimenti. Andiamo poi a vedere delle cose che trascendono il percorso scelto e vediamo un poco di security e
un poco di cloud computing.
Si riferirà in questa lezione alla reliability e Availability engineering, Modelling, Analysis and Application come testo di
riferimento; il libro parla anche delle catene di Markov e parla anche della parte di Rosiello.
Quando si alza il livello di criticità di un sistema abbiamo che i mondi di sicurezza e affidabilità si fondono nei sistemi
dando vita a quello che chiamiamo SAFETY.
Oggi c’è un grosso indotto in Italia dei sistemi safety critical, questo perché non esistono sistemi solo safety. Abbiamo
delle aziende anche piccole e medie che fanno sistemi di controllo per aerei, etc.
Noi tratteremo i sistemi safety critical, ovvero i sistemi che in caso di fallimento portano alla potenziale morte di
qualcuno o il danneggiamento ambientale.
I mission critical, non solo il sistema è safety ma è un sistema che ha una missione, ad esempio un software che eviti
problemi agli aerei militari. Hanno delle missioni e devo massimizzare la probabilità che questa missione sia eseguita
senza avere problemi.
Business critical system, se in questo sistema trovo un bug e questi portano a dei problemi potrei avere perdite
economiche (esempio di Intel, non ci sono ancora report, ma secondo lui la quota che ha perso Intel nel mercato è
grossa. Pensate ai Nokia che hanno usato symbianOS ed è passata a detenere l’80% del mercato fino a poi perdere
quote di mercato, avendo hardware più complessi e le installazioni di app complesse).
I domini principe della safety sono ferroviari, avionici e aerospaziali, e come visto nelle prime lezioni abbiamo che in
questo ambiente si parla tanto di digital twins. Va di moda adesso configurare anche solo la costruzione (secondo lui
qua troviamo lavoro a scatafonno).
Il teorema di Dijkstra dimostra che non esiste un software bug free, posso dimostrare la presenza di un difetto ma
non l’assenza. Questo è un grosso problema perché per quanti test faccio può sempre uscire un bug anche su un
sistema super controllato.

Fa vedere qualche paio di errori belli tipo il BSoD di windows, poi problemi di configurazione di BGP routers che ha
causato i problemi di Facebook del mese scorso.
Quando parlo di fallimenti possiamo parlare di guasti accidentali e non accidentali, a livello ingegneristico non mi
interessa chi causa il fallimento, lo tratteremo allo stesso modo ma a noi interessa sapere come si migliora il tutto.
Devo trovare tecniche per migliorare la security del sistema, quando si mette a punto il processo cerco di minimizzare
il fallimento rispetto a vulnerabilità e attacco. Al livello di safety non faccio differenze ed è tutto fallimento.
Esistono delle specificità che fanno distinguere tra guasto accidentale e guasto malizioso. Il guasto malizioso è
causato da qualcuno malevolo. Parlando di affidabilità e safety dobbiamo parlare di cose anche fatali perché sennò
non so come migliorare.
C’era un virus sui pilot control che metteva un AND con tutti 0 per non far aprire i flap dell’aero per aumentare la
portanza per poter atterrare. Questo flap non aprendosi per via del virus creò un sacco di morti.
Il problema è se ho un solo sensore io non ho minimamente la certezza della correttezza sui valori che mi restituisce,
se uso più sensori vedo se tutti mi danno la stessa risposta (o vanno a maggioranza) e posso fare una decisione più
precisa. La soluzione del Boing, ad esempio, è pezzotta e usa un sensore a dx e uno a sx.
Studieremo i sistemi dependable, senza entrare troppo nella terminologia, sono quei sistemi da cui posso dipendere
(reliable): Ad esempio abbiamo bisogno di fidarci di qualcuno o qualcosa per fare quello che dobbiamo fare o quello
che si aspettano che noi facciamo. In inglese notiamo che c’è una differenza tra i termini dependable e reliable,
anche se in italiano sono identici; nel caso di dependable parliamo di una cosa più generale di rely

Dependability
Sono state messe due definizioni proprio perché fino al 2001 si è portata la definizione: “Laprie: un sistema che
forniva servizi affidabili.”
Nel 2004, al crescere della complessità era divenuto impossibile pensare che tutti i servizi fossero affidabili, e quindi si
usa la nuova definizione: “la dependability è la capacità di evitare che i fallimenti dei servizi siano più frequenti e
critici rispetto a un limite di accettazione”
Il fallimento e la severità si misurano in costi, anche le vite umane sono costi. Quando faccio questi sistemi per me è
un costo.

Il mondo della dependability si divide in tre macroaree, come mostrato in figura:

• Attributi, sono le declinazioni della proprietà su un tipo di sistema. Ad esempio, di un web server non
interessa che funziona continuamente, ma solo quando lo pingo. Un aereo voglio che funzioni sempre
o Availability
o Confidentiality
o Integrity

Questi ultimi tre insieme creano il concetto di security.

• Mezzi
• Minacce

Partiamo, da concetti semplici : Sistema, Servizio, Interfaccia, Utente.

Ci servono questi concetti per poter modellare e capire il fallimento di un sistema, ad esempio un’auto è un sistema
complesso fatto da componenti che fornisce un servizio (trasporto) ad un utente. Perché una macchina fallisce e a che
è dovuto il fallimento? Cerchiamo di capire la FAULT-ERROR-FAILURE (catena di fallimento).

Fault-Error-Failure chain.
In una macchina, supponiamo che si rompe il faro, se la uso sempre la mattina non me ne accorgo mai che tengo sto
FAULT sul faro (che è uno stato alterato della macchina). Quando vado di notte vedo che il faro non funziona e allora il
mio FAULT diventa un ERRORE. Se per questo ERRORE faccio un’incidente fatale vado in FAILURE.

Il fault è quindi uno stato improprio del sistema, ho varie classificazioni dei guasti, i quali possono essere sia
hardware che software ed è impensabile cercare di trovare tutti i fault di un sistema. Ci interessa lo studio dei guasti
perché se li elimino alla base elimino anche gli errori.
I guasti (fault) li suddivido in base a varie dimensioni:

• Cause: possono essere :

o HUMAN FAULTS (interazioni con la macchina, anche parti di progettazioni introdotte magari durante
il design di sistema o durante le modifiche)
o PHYSICAL FAULT (dovuti a fenomeni fisici come la rottura dell’hardware)
• Persistenza di un Fault (classificazione a livello temporale):
 o Permanente (una volta che buco la ruota resta così in qualunque momento e lo rilevo sempre sto
guasto)
o Transitorio (un fault che si manifesta per brevissimo tempo, o per una specifica condizione) sono i
più brutti. Sono i più difficili da rilevare.
o Intermittente (sono fault non modellabili statisticamente e sono dovuti a cambi di configurazione hw
o a cambi di workload).
• Intenzionalità:
o Maliziosi: sono diversi dalle VULNERABILITÀ e si trovano ad un livello di astrazione più basso. Sono
guasti introdotti che potrebbero essere parte di una vulnerabilità, io la vulnerabilità la devo sfruttare
per fare exploit e portare a termine un attacco.
o Non maliziosi
• Origini
o Interal fault
o External fault

Un errore è dunque la manifestazione di un fault, essi possono accadere anche in posizioni (spaziali e temporali)
distanti dal sito di fault.

Ma quindi un errore è uno stato improprio del mio sistema, in questo momento il mio fault diventa pericoloso. Un
solo fault può generare più errori e vedremo come ridurre questa ridondanza, useremo tecniche di DM per evitare
tutto ciò.
Quando l’errore si propaga sulla service interface ho il fallimento, che è una deviazione dalle mie specifiche.
Qualunque deviazione delle specifiche è un fallimento.

Questo schema vecchio, ma ancora buon mostra come i difetti fisici dei componenti portino quasi sempre a fault
permanenti.
Vediamo la threats propagations dove transito dallo stato di fault alla error.

Threats propagation
Un sistema può funzionare in uno stato “correct free” riportato come correct behavior o stato on, in uno error o uno
stato fallito. Durante il funzionamento di uno stato corretto un fault può essere presente ma dormiente (esempio del
faro); il fault viene attivato e transito nello stato di errore; qua posso avere la fault detection o la fault treatment che
mi permette di evitare l’errore e di ritornare allo stato di correct behavior. Tali sistemi si chiamano fault tolerant
perché sono tolleranti ai guasti e riescono a recuperare o grazie a ridondanza o routine di self repair.

Anche quando un sistema funziona in uno stato erroneo ci possono essere errori (file che non mi servono), se però
l’errore si manifesta all’interfaccia e mi fa deviare dalle specifiche allora il mio sistema è fallito.
La prossima figura è la stessa di quella di prima (threats propagation 1/2) ma permette di capire la differenza tra cause
interne ed esterne.
Abbiamo due sistemi A, B. Il A è formato dai componenti A1 e A2

Il componente A1 può avere dei guasti che chiamo dormant fault. Quando dal dormant fault si genera un guasto
questo entra nel componente e si può propagare con internal propagation. Quando A1 fallisce ho un component
failure.
Se A2, interagisce con A1 (esempio un client che vuole risolvere con un host) il fallimento esterno diventa un fault
interno e si propaga in A2. Quindi un external fault entra nel componente e fa fallire A2. Se questo fallimento si porta
all’interfaccia del sistema A si dice che A è fallito e a sua volta si può propagare sul sistema B
Questa slide è importante.
Il concetto di Fault-Error-Failure dipende dal punto di prospettiva in cui ci poniamo, se mi metto a livello di sistema A
abbiamo che un fallimento di componente A1 per me è un errore e un errore di un componente per me è un guasto.
Se mi metto a livello di componente è chiaro che un guasto è un guasto di componente quindi dobbiamo sempre
scegliere un punto di vista.

Un bug di un processore per noi è un guasto.

In letteratura trovo molto materiale su sistemi HW e trovo la catena fault/error di un processore, trovo anche degli
hardware fault model.

Esistono anche software fault model tanto importanti in letteratura.

Andiamo ora a definire gli attributi più importanti della dependability.

Dobbiamo capire che se il mio sistema è in UP o in DOWN, non ci interessa più l’errore. Che succede se il mio sistema
fallisce? Distinguerò due tipi di sistemi.

• I sistemi non riparabili, quelli che una volta falliti non posso più riparare.
• Sistemi riparabili che possono applicare delle procedure di ripristino e di restore per tornare UP.
Ad esempio, un web server è un sistema riparabile o non riparabile? Il web server è riparabile, l’aereo se precipita ho
affondato.
Con i modelli si può giocare (petri net) la prima cosa che devo capire quando faccio il modello è se il sistema è
riparabile o non riparabile. Ci sono casi in cui da failed posso tornare in up. Iniziamo a vedere i sistemi non repairable
che li definiamo in base alle considerazioni sulla distribuzione X dei tempi di fallimento; e quindi come se avessimo i
tempi di fallimento di un’unità e li chiamo con X grande.
La CDF di X ovvero la probabilità che X è minore o uguale di t è unreliability, cioè la probabilità che X fallisca in un
tempo minore di t.
Reliability

1 − 𝐹(𝑥) è reliability ed è la probabilità che il sistema non fallisca prima del tempo t (mission time). Un aereo di
medio raggio deve avere una reliability molto molto alta (mission time di circa 3h). Sui sistemi di lungo raggio il
mission time è di 15h/20h.
Non esiste un sistema reliabile se non indico il mission time.

Le due curve hanno parecchi legami e dovremmo familiarizzare con entrambe. La pdf della reliability è importante, ed
è chiamata hazard rate, perché se voglio la probabilità che il sistema non fallisca in un intervallo A,B lo vedo così e la
chiamo interval reliability.
Per noi sono molto importanti i valori medi, perché quando modelliamo o compriamo componenti dai rivenditori loro
ci parleranno di MTTF (mean time to failure) ed è il valore medio di affidabilità

1
Si misura come . La lambda è il failure rate che non serve tanto per i sistemi software ma a livello elettronico si usa
𝜆
assai.
Poi ho la BATHTUB CURVE.
Quando produco un sistema come un cellulare ho un periodo esponenziale che si chiama mortalità infantile (il primo
terzo del grafico). All’inizio il componente ha un'alta probabilità di rompersi poi la reliability diventa molto bassa e
costante e in quella fascia abbiamo il momento in cui lo immetto sul mercato. Dopo di che, dico al committente che
dopo tot tempo dobbiamo fare manutenzione perché poi ricresce la curva della lambda.
Questa curva mi dice quando immettere sul mercato e quando fare manutenzione. Per l’aereo non faccio
manutenzione quando si rompe il pezzo ma si fa manutenzione predittiva. Si fa una curva del genere e si fa quando
fare manutenzione sul singolo componente.
Queste sono le non repairable unit a noi interessa che il sistema non fallisca entro il mission time.
Nella reperable unit che vedo? Che il sistema può transitare tra uno stato UP e uno stato DOWN. Quando il sistema
fallisce si innesta una procedura di ripristino che porta il sistema in uno stato X2.

Availability
Possiamo dire che l’availabilty 𝐴(𝑡) è la probabilità che al tempo t il sistema risponda correttamente nello stato di UP.
La unavailabity 𝑈(𝑡) è la probabilità che il sistema sia in down. Allora l’availability è la prontezza del servizio.
NON REPERABLE VOGLIO RELIABILITY, REPERABLE VOGLIO AVAILABILTITY
Nei riparabili devo accorciare quanto più possibili i tempi di down per avere l’availability più alta. Lo ottengo
abbassando i tempi di ripristino (posso farlo con ridondanza).
La ridondanza si usa anche in reliability ma non per abbassare il tempo di ripristino ma per mascherare un guasto.
Quindi la ridondanza si usa in maniera diversa nei due tipi di sistemi e la ridondanza non è la cura a tutti i mali.
La ridondanza serve fino a un certo punto ma alla lunga aumenta il tempo al fallimento del sistema.

LEZIONE 17 05/11/2021 (continua pg 46

Lecture_7_IE_new)
Experimental Design and Analysis Parte 2
Si chiude con questa lezione la parte di performance analysis. Abbiamo visto nella lezione 15 come fare il DoE in casi
particolari. Quali casi particolari? Quando avevamo un numero di fattori K, variabili, e due vincoli:

• I fattori dovevano avere lo stesso numero di livelli, o alternative. Nello specifico per semplificare
dicevamo che avevano solo due livelli (min e max)
• Potevo aggiungere delle repliche che permettevano di distinguere il contributo dell’interazione, dei
fattori che stavamo analizzando, dal contributo non spiegato dovuto all’errore di misurazione.

Oggi vedremo casi diversi dove non ho il vincolo di avere solo due livelli, in particolare vedremo one factor
experiment, two factor experiment e infine un ultimo in cui aggiungeremo le ripetizioni.

One factor experiments

Nella one factor ho un fattore ma non ho vincolo di livelli, stessa cosa con il two factor, ad esempio posso avere un
fattore A con 3 lv e il B ne ha 5.
La one factor viene utilizzata per analizzare più alternative per un singolo fattore non avendo più limiti dovuti al
min/max, e i dati campione consistono in r osservazioni con un certo numero di alternative.
Facciamo un esempio: ho 3 differenti processori (R, V, Z) e ho 5 programmatori che effettuano un workload.
Ho 3 livelli e 5 repliche, avremo un numero di esperimenti pari al numero di alternative moltiplicato per il numero di
livelli. Mi devo porre nelle stesse problematiche dei DoE dell’altra volta e il nostro obiettivo è sempre capire l’effetto
di ogni alternativa. A prescindere da quello che applico devo vedere come i livelli e i fattori influiscono sui parametri di
risposta.

Devo calcolare la media totale (grand mean) 𝝁 che è la media di tutti i valori collezionati ovvero sommatoria lungo le
righe e le colonne delle mie 𝑌𝑖𝑗 ; la quale indica la variabile di risposta quando abbiamo utilizzato l’alternativa j-esima
con la ripetizione i-esima (Quindi rappresenterà lo storage medio necessario per i processori). Ovviamente il tutto
diviso per il numero totale di osservazioni.
̅..
Quando calcolo la media totale non dipenderà né da 𝒊 né da 𝒋 e allora ho una Y segnato punto-punto 𝒚
Gli altri valori che ci servono sono i valori di colonna (che nell’esempio sono le alternative del processore e quindi lo
storage medio necessario al singolo processore j-esimo) , attraverso il calcolo della media di colonna posso valutare gli
effetti della colonna e lo indico con 𝒚̅.𝒋 . Per ogni colonna calcolo la media e faccio quindi la sommatoria lungo le righe
della colonna j-esima diviso il numero di righe r.
Dall’esempio possiamo notare che l’effetto dell’alternativa R pari a 174.4 è negativo e quindi l’alternativa impiega in
media di meno rispetto alla media totale (Per effetto si intende la differenza tra la media lungo la colonna j-esima e la
media totale)
Il modello veniva espresso partendo dal modello di regressione lineare come 𝑞0 + 𝑥𝐴 𝑞𝐴 + 𝑥𝐵 𝑞𝐵 + 𝑞𝐴𝐵 𝑥𝐴𝐵 e con la
tabella dei segni ci calcolavamo tutti i valori.
In questo caso ho però un solo fattore, se prima 𝑞0 era la media ora lo chiamiamo 𝜇. La 𝛼𝑗 è l’effetto della j-esima
alternativa e in questo caso ovviamente non ho iterazione e non ho il secondo fattore ma abbiamo l’errore perché
abbiamo delle repliche.
Il modello di un DoE one factor, cioè con un fattore (k = 1) e con un numero generico e non fissato di livelli si esprime
con la cosiddetta rappresentazione ad effetti:
𝑦𝑖𝑗 = 𝜇 + 𝛼𝑗 + 𝑒𝑖𝑗

Effetti dei fattori

Sfruttando le proprietà della tabella dei segni ci mettiamo nelle condizioni in cui gli effetti di ogni alternativa j-esima è
pari a zero e la stessa cosa vale per gli errori. Quando vado a calcolare gli errori, dato che vengono calcolati rispetto
alla media, per ogni colonna dividendo lungo la colonna j-esima sommo la componente degli errori e ottengo che
questa sommatoria è pari a zero.
𝑟 𝑟 𝑟
1 1 1
̅.𝒋 = ∑ 𝑦𝑖𝑗 = ∑ 𝜇 + 𝛼𝑗 + 𝑒𝑖𝑗 = (𝑟𝜇 + 𝑟𝛼𝑗 + ∑ 𝑒𝑖𝑗 ) = 𝜇 + 𝛼𝑗 + 0 → 𝑎𝑗 = 𝒚
𝒚 ̅.𝒋 − 𝝁 = 𝒚
̅.𝒋 − 𝒚
̅..
𝑟 𝑟 𝑟
𝑖=1 𝑖=1 𝑖=1

Come calcolo l’effetto dell’alternativa j-esima della colonna, ovviamente l’effetto lo vediamo.
La media totale non dipende da 𝑖 e quindi quando vado a fare la sommatoria per 𝑖 che va da 1 a r viene fuori r per la
media. La stessa cosa succede con 𝛼𝑗 e quindi applico lo stesso ragionamento, chi non posso portare fuori dalla
sommatoria? L’errore perché dipende sia dall’alternativa che dalla ripetizione.
Però dalla precedente slide ci siamo detti che la sommatoria lungo tutta la colonna dell’errore è pari a zero. r lo
troviamo al denominatore perché deriva dal fatto che sto calcolando sempre la media e ci resta che la media lungo la
colonna j-esima è pari alla media totale più l’effetto dell’alternativa j.
Perché tutto questo ? Per calcolare l’effetto della alternativa j che è l’unica cosa che ci interessa.
Dato che gli errori dipendono dalla media di tutte le osservazioni, se ho come nel caso precedente 12/15/18 faccio la
media e fa 15. Quando faccio il valore osservato meno stimato ho -3/0/3 sommando questi errori viene 0, per fare
questa supposizione il valore stimato deve essere la media di tutte le osservazioni e posso così applicare questa
proprietà.
Partendo dall’esempio iniziale viene fuori che qua ci portiamo la somma di tutte le colonne quindi nella tabella due, in
alto a destra, abbiamo che la prima riga rappresenta la somma delle colonne, la seconda rappresenta la media della
colonna mentre la total rappresenta la media totale.
Quindi con l’effetto di colonna ho che è la differenza tra media di colonna e totale per ogni colonna e quindi facendo
i conti ottengo gli effetti di ogni colonna; quindi, come nel caso precedente riesco a dare la average processor.
Come si leggono i risultati ottenuti sopra? Ci interessa comprendere l’effetto di 𝛼𝑗 dunque nella tabella di destra si
prende l’elemento j-esimo della riga “Col.Mean” e si sottrae alla media totale 𝜇 = 187.7 (Ovvero quanto i nostri 3
processori richiedono in media di termini di storage per eseguire tali workload). Tuttavia, se vediamo gli effetti 𝛼𝑗 , il
processore R rispetto alla media generale ne richiede 13.3 in meno (essendoci il segno meno); il processore V rispetto
alla media generale ne richiede 24.4 in meno; il processore Z rispetto alla media generale ne richiede 37.7 in più.

Stima dell’errore
Ci resta ora da stimare l’errore 𝑒𝑖𝑗 , ricordiamo che è dato dalla differenza tra la risposta osservata 𝑦𝑖𝑗 e quella stimata
𝑦𝑗 , per ogni j-esima alternativa.

La risposta stimata rappresenta la media delle mie ripetizioni per ogni alternativa.
La somma di ogni errore è uguale a zero e ci serve solo per calcolare l’effetto delle colonne, ma a noi interessa la
variazione totale spiegata, sia dal fattore che dall’errore, ci viene incontro la somma quadratica dell’errore (SSE) che è
data dalla doppia sommatoria sulle 𝑒𝑖𝑗 .
Volendola calcolare come SSE (sum of squared errors) nel nostro esempio la faccio per ogni riga e per ogni colonna e
ottengo una somma quadratica.

ALLOCAZIONE DI VARIAZIONE (Importanza e significatività di un fattore)

Non vediamo più i singoli errori e contributi ma ci interessa la somma quadratica. A questo punto ci serve
comprendere l’allocazione della variazione (% della varianza totale) che ci permette di capire quanto un fattore è
importante e dunque quanto influisce sulla variabile di risposta 𝑦 (Dobbiamo calcolare gli SSY, SSA, SSE ed SST). Faccio
la sommatoria lungo i e j di ogni nostro termine, partendo dal modello, ed eleviamo al quadrato.

Questo sarà pari a tre sommatorie + i cross products terms. Questi ultimi però sono tutti nulli, perché? Perché quando
prendendo due qualsiasi colonne ho che il prodotto si annulla totalmente.
Questa somma lungo 𝑖𝑗 di 𝜇 2 la chiamo SS0, poi ho SSA che è del fattore(delle colonne) e infine la SSE dell’errore.
Tutto questo ci dà la SSY che rappresenta la sum of square di ogni singola osservazione.
Ovviamente quando faccio questa sommatoria al quadrato devo vedere che la media non dipenda ne dà i ne dà j;
quindi, questa sommatoria è il numero totale di righe r per il numero totale di colonne a moltiplicato la media al
quadrato.

Nel caso di 𝛼𝑗2 dipende da j e quindi ho 𝒓 (𝒕𝒐𝒕𝒂𝒍𝒆 𝒓𝒊𝒑𝒆𝒕𝒊𝒛𝒊𝒐𝒏𝒊) ∗ ∑𝜶𝒋=𝟏 𝜶𝟐𝒋 . L’errore dipende dà i e j quindi non
possiamo fare questa semplificazione
L’altra volta non abbiamo visto SSY ma la SST. In realtà sono nello stesso caso perché la SST altro non è che la
differenza tra SSY ed SS0.
 2
𝑺𝑺𝑻 = ∑(𝑦𝑖𝑗 − 𝑦̅.. ) = ∑ 𝑦𝑖𝑗2 − 𝑎𝑟𝑦̅..2 = 𝑆𝑆𝑌 − 𝑆𝑆0 = 𝑆𝑆𝐴 + 𝑆𝑆𝐸 → 𝑆𝑆𝑇 = 𝑆𝑆𝐴 + 𝑆𝑆𝐸
𝑖,𝑗 𝑖,𝑗

Tutto questo per capire l’importanza di un fattore, infatti, prendo la sum of square del fattore di cui voglio capire la
sua importanza, quindi la SSA, la divido con la SST e capisco che l’importanza spiegata dal fattore è di circa il 10%
mentre l’errore è del 90% allora devo prendere questo esperimento e buttarlo tutto.

Va bene ancora che il fattore spieghi il 10% ma il fatto che l’errore spiega il resto mi fa affondare e non sto spiegando
nulla.
Questo concetto è ancora interpretabile perché non è statistico, c’è un altro concetto che è ancora più importante
dell’importanza ed è la significatività di un fattore.

Significance of a factor
La significatività di un fattore rappresenta il contributo spiegato da questo fattore rispetto all’errore e mi dà la
concezione, o comunque la possibilità, di fare assunzioni importanti.
Importanza e significanza sono diverse.

Quando il mio fattore è significativo sto dicendo che ripetendo l’esperimento mi trovo nelle stesse condizioni di
prima. Se dico che il mio fattore esprime un qualcosa rispetto all’errore e quindi è significativo all’errore, se ripeto
l’esperimento probabilmente mi ritrovo nelle stesse condizioni di prima; cosa che non posso dire per l’esempio di
prima con il 90%.
Non ho la possibilità di fare queste affermazioni nel caso in cui non è significativo. L’importanza di un fattore indica la
significatività? No, un fattore può essere importante ma non significativo.
Invece se un fattore è significativo, implica l’importanza? Si, perché indica un altro contributo alla variazione di un
fattore rispetto all’errore.
La significatività non è banale, nel caso precedente era SSA/SST o SSB/SST o SSAB/SST, e non si ottiene come SSA/SSE
poiché non sarebbe statistico ma si ottiene dalla tecnica di Analysis off Variance (ANOVA) che è un test parametrico.
Ma come funziona ANOVA? Per calcolare l’importanza di un fattore A valutiamo il rapporto tra SSA/SST, il quale ci
fornisce la % di varianza spiegata del fattore sul totale. Per calcolare la significatività valutiamo un certo valore F.

Uso il test di Phischer questo calcola un F value che è pari al rapporto di due contributi:
• Il primo contributo, nel caso in cui siamo interessati alla significatività del fattore A, è dato da SSA/𝑣𝐴 (𝑣𝐴 è il
numero di gradi di libertà del fattore).
• Il secondo contributo, al denominatore è SSE/𝑣𝐸 (dove 𝑣𝐸 è il numero di gradi di libertà dell’errore).
Il primo contributo si indica con MSA (Mean Squared A-Error), il secondo con MSE (Mean Squared Error).
Ogni volta che faccio gli esperimenti, a seconda del numero di livelli e ripetizioni, avremo che questi due 𝑣𝐴 e 𝑣𝐸
cambieranno sempre. Cambiano a seconda del tipo di esperimento che ho settato.

Nel caso precedente (one factor experiment) ho SST che è pari a SSY-SSO, ma SSY è la sum of square di tutte le
variabili e dato che assumo che tutte le mie osservazioni sono indipendenti ottengo che il numero di gradi di libertà di
SSY è proprio dato dal numero totale di misurazioni = 𝑎 ∗ 𝑟 (alternative*repliche). SS0 è legato alla media ed è quindi 1
perché è un valore indipendente. 𝑎 − 1 è la SST ma non ci interessa, solo per il legame dell’altra volta. SSA dipende dal
numero di livelli meno 1.
L’errore dipende dalla ripetizione, l’errore è il numero di livelli dei nostri fattori, nel caso avessimo due fattori, in
questo caso i gradi di libertà sarebbero A*B per numero di repliche meno 1. Nel caso generale abbiamo che il numero
di gradi di libertà di un fattore è pari al numero di alternative che ha meno 1.
Nella slide “D.f” sta per gradi di libertà.
Possiamo calcolare MSA e MSE e alla fine calcolare tutto questo per calcolare il famoso F value. F value è 0.7.
Mo che devo fare? Che ci faccio con questo F value? Lo confronto con un altro F che è detto F statistico che deriva
dalla distribuzione, la distribuzione di chi? Di Fisher.

Questa distribuzione, quando vedo F vedo due valori n ed m ma chi sono n ed m?

• n è il numero di gradi di libertà del fattore di quello che troviamo al numeratore,
• m è il numero di gradi di libertà dell’errore.
Quindi a seconda di questo n ed m il valore di 𝐹𝑛,𝑚 cambia. Da che altro dipende? È un test statistico il senso di tutto
ciò è che il nostro F value deve trovarsi nella parte del nostro grafico che si trova a destra di un qualcosa.
Perché 𝑭𝟎.𝟗𝟎 , 𝑭𝟎.𝟗𝟓 , 𝑭𝟎.𝟗𝟗 sono i nostri livelli di confidenza.
Con un livello di confidenza maggiore il mio F value deve trovare sempre più a destra della curva, più il livello di
confidenza aumenta più il p-value è basso.
Il mio fattore è significativo quando l’F value che ho calcolato si trova alla destra dell’F0.9 che è l’F con livello
statistico di confidenza del 90% e così via.
Ovviamente, per motivi pratici devo avere dati alla mano e capire 𝐹(3,15) per capire i valori.

Quindi come si effettua questa valutazione?

1. Si prende la corretta distribuzione di Fisher 𝐹(𝑛,𝑚)
2. Se voglio verificare la significatività del fattore rispetto all’errore al x% di livello di confidenza prendo
x(esimo)-quantile [Che si trovano online perché valori noti)
3. Se F < x-quantile l’effetto del fattore non è significativo al livello x% di confidenza. Altrimenti se F > x-quantile
l’effetto del fattore è significativo al livello x% di confidenza
Vediamo un esempio:

Esistono queste tabelle su Google (F-table Fisher test) e in base ai miei fattori mi faccio i conti.

Sulle colonne ho gli n (numero di gradi di libertà del numeratore) e sulle righe il numero di gradi di libertà dell’errore.
𝐹(2,12) è 2.81 circa e questo è l’F statistico, è il nostro F value maggiore dell’F statistico? No e allora posso dire che il
90% del livello di confidenza il fattore A del nostro esperimento non è significativo. Ovviamente questi valori
cambiano a seconda dell’alpha. Più alpha è piccolo più diventa difficile dire che il nostro fattore è significativo.
Lunedì ci sarà una esercitazione insieme
Tutta questa parte è fondamentale per il design of experiments.
Torna sulla distribuzione di Fisher che dipende da n ed m e mi devo confrontare il mio F value dato da MSA/MSE con
quello della curva di distribuzione di Fisher e il valore che prendiamo da essa si chiama F statistico. Sto F statistico lo
prendo dalle tabelle che trovo (so tabelle immense). Vado a cercare quella che mi interessa. Il mio F deve essere
maggiore di questo per dire che il fattore che sto valutando sia statisticamente significativo.
Questa è la tabella riassuntiva di quello che ho visto fino ad ora. (slide 63).
A slide 64 ci sta un pezzo aggiuntivo che fa vedere al deviazione standard legata all’errore come rapporto della MSE
sicuramente è utile ma nel nostro caso non ci serve. Chiudiamo qui il ONE FACTOR EXPERIMENT

TWO FACTOR EXPERIMENT

Premessa: “il libro di testo fa una semplificazione, quale? Che faccio la two factor senza repliche. Ma io so che solo con
le repliche so scindere il contributo dell’errore da quello dell’interazione. Il libro per fare tutte le considerazioni su
ANOVA va a dire che la SSAB (interazione tra fattore A e B, la chiama SSE quindi dell’errore) e gli serve per fare
un’introduzione al 2-factor con repliche che è più difficile.”
Quindi solo in questi esperimenti la SSE è una semplificazione.
I fattori usati sono categorici, questo vuol dire che appartengono ad un numero limitato di categorie (ad esempio,
acceso o spento)

Prendiamo l’esempio: due fattori A e B ognuno con a e b livelli, Il numero di esperimenti è ab. In questo caso abbiamo
i due fattori che sono caches e workloads.
I fattori sono il workload che applico al sistema, ne sono cinque, mentre l’altro fattore sono le cache che hanno tre
livelli.

Il modello del DoE two factors come diventa ? è simile al caso one factor ma presenta un componente in più: 𝛽𝑗
𝑦𝑖𝑗 che è la media totale, l’errore fasullo (semplificazione) 𝑒𝑖𝑗 , 𝛼𝑗 e aggiungiamo 𝛽𝑗 .

Fatto il design di prima tutto questo diventa più facile, quello che applicavo prima lo posso applicare anche in questo
caso. La sommatoria degli errori lungo 𝑦𝑖𝑗 o i e j è pari a 0.

Effetti dei fattori (two factors)

Anche in questo caso per capire gli effetti sia sulle colonne di A che di B devo trovare la media. In questo caso, non
avendo un solo fattore ma due mi serve la media lungo le righe rispetto a quella lungo le colonne.

Se calcolo la media 𝑦̅.𝑗 posso calcolarmi 𝛼𝑗 ed è lo stesso calcolo di prima. Che ho in più? Ho 𝛽𝑖.

Infatti, il terzo termine di 𝑦̅.𝑗 lo ottengo quando faccio la media lungo la colonna j e devo fare la sommatoria lungo le
righe diviso il numero di righe. Questa qui, la media totale non dipende dalla riga e ovviamente si annulla la
sommatoria diviso il numero di righe.
Chi dipende? 𝛽𝑖 e l’errore. Ma dalle proprietà precedenti avevamo detto che la sommatoria di 𝛽𝑖 è 0 e la sommatoria
dell’errore sia lungo le righe che lungo le colonne è 0.
Andando a fare questa sostituzione esce fuori che l’affetto dell’alternativa j-esima del fattore A è uguale alla media
della colonna j-esima meno la media totale. Ed è identico al caso precedente, cosa cambia? Che aggiungiamo la media
di riga e quindi andiamo a fare al sommatoria lungo le colonne sull’indice j e non più i dello stesso modello e mi
trovo 𝑦̅𝑖. . Facendo le stesse considerazioni ci resta di nuovo 𝜇 e 𝛽𝑖, ci ricaviamo 𝛽𝑖 allo stesso modo ed otteniamo la
media della colonna i-esima meno la media totale.
Nel nostro esempio, considerando queste ultime cose viste abbiamo:

La tabella diventa brutta come me.

La media è in blu ed è sottolineata (ottenuta dalla somma e la divisione di Row Mean). Calcolo la media di riga e di
colonna e la vedo per i vari casi. Qual è l’effetto di colonna? La differenza tra 51 e 72.2 = −21.2. Qual è l’effetto
della prima riga? 71.7 – 72.2 = −0.5 e così calcolo gli effetti di ogni alternativa.
Come può essere interpretato? il tempo con 2 cache è 21.2 ms in meno che il tempo richiesto di un processore con
funzionamento medio.
Vediamo gli errori sperimentali, abbiamo calcolato gli effetti 𝛼𝑗 e 𝛽𝑖 conosciamo la media totale ci manca solo l’errore
sperimentale. SSE non cambia, cosa cambia è solo l’indice perché prima andava da i a r, in questo caso fino a b
numero di alternative.

Stima dell’errore (Two factors)

Anche qui possiamo valutare l’errore (uguale al caso one factor), dato dalla differenza tra il valore osservato e quello
stimato.
Analogamente, possiamo valutare la SSE (è simile al one-factor ma qui nel two-factor sulle righe non vi sono le
repliche ma le alternative di un altro fattore)
Di sotto i passaggi.
Nella prima osservazione 𝑦11 vale 54 e devo andare a sottrarre a questa osservazione al media totale (72.2) meno
l’effetto di colonna meno l’effetto di riga.
Allocazione della variazione (Two-Factors)
Ovviamente a noi interessa l’SSE per calcolarci la famosa variazione spiegata da ogni fattore rispetto a quella totale e
dunque quanto influisce sulla variabile di risposta y. Dobbiamo di nuovo calcolare SST che è uguale a SSA + SSB + SSE.

Da cui possiamo valutare l’importanza dei fattori e dell’errore facendo il rapporto del SSi-esimo/SST. Nel nostro
esempio otteniamo i seguenti valori:

Ciò significa che il fattore A (cache) spiega la maggior parte, ossia il 96% della varianza totale, mentre B solo il 2,3% e
l’errore l’1,8%
Nella successiva slide riparliamo della significatività e del test di Fisher. Necessariamente dobbiamo calcolarci i gradi di
libertà, nel caso dei fattori è il loro numero di livelli – 1 mentre per l’errore è (𝑎 − 1)(𝑏 − 1). Nuovamente questi
sono i gradi di libertà dell’interazione non dell’errore, sempre per la questione della semplificazione.
Come interpretiamo il valore dato da F?
A questo punto calcolato il valore del rapporto 𝐹, per vedere se l’effetto di un fattore è significativo rispetto all’errore
ad un certo livello di confidenza, dobbiamo valutare la distribuzione di Fisher 𝐹𝑛,𝑚 , dove :

• 𝑛 è il numero di gradi di libertà del numeratore di F (fattore che stiamo misurando)

• 𝑚 è il numero di gradi di libertà del denominatore di F (nel nostro caso dell’errore)
Come si effettua tale valutazione?
1. Si prende la corretta distribuzione di Fisher 𝐹𝑛,𝑚
2. Se voglio verificare la significatività del fattore rispetto all’errore al x% di livello di confidenza prendo
x(esimo)-quantile (trovando sempre la tabella online con i valori noti)
3. Se F < x-quantile l’effetto del fattore non è significativo al livello x% di confidenza
a. Se F > x-quantile l’effetto del fattore è significativo al livello x% di confidenza.
Quindi di nuovo F value è MSA/MSE e questo rapporto è maggiore dell’F statistico allora A è significativo con un livello
di confidenza 1 − 𝛼%.
Questo secondo tipo di design, in cui ho due fattori, fa introdurre un altro fattore B che si comporta in modo tale che
possegga le stesse considerazione del fattore che ho chiamato A. Infatti, il numero di gradi di libertà è sempre il
numero di livelli meno uno, e in via generale quello che ottengo è: quando devo calcolare la significatività devo vedere
sto F statistico che dipende dal numero di gradi di libertà del fattore considerato che sto calcolando, e dal numero di
gradi di libertà dell’errore.
ESPERIMENTI CON REPLICHE (Two factors)
Aggiungiamo ora l’ultimo indice, se fino ad ora ci siamo messi a giocare i e j ora aggiungo l’indice K che fa riferimento a
quelle che sono le ripetizioni, ogni singola misurazione ora dipende:
• Tipo di alternativa del fattore A
• Alternativa del fattore B
• K numero di ripetizione

Il modello di DoE a due fattori con più repliche è il seguente:

Ovviamente, l’unico che dipende da tutti e tre è l’errore! Perché ogni volta che misuro ho un errore. L’altro che dipende
da tutti e tre gli indici è la misurazione. Mentre la media non dipende da nessun indice. 𝛼𝑗 è solo l’alternativa j-esima
del fattore A e quindi solo un indice, stessa cosa per 𝛽𝑖 solo che per l’indice i
EFFETTO dei fattori:
Infine, otteniamo il valore 𝑦𝑖𝑗 è l’effetto dell’interazione. Rispetto al caso precedente, senza ripetizione, ora riesco ad
aggiungere l’interazione tra alpha e beta. Quindi questo modello è completo, in generale quando faccio esperimenti di
questo tipo non opero senza ripetizioni.
Quando faccio DoE devo fare esperimenti altrimenti non so dire quanto è significativo il contributo del nostro fattore.
Si applicano le stesse proprietà. Gli effetti sono calcolati in modo che la sommatoria lungo A è pari a zero, lungo B è
pari a zero e ovviamente anche il resto.

Stesso modo di procedere per calcolare gli effetti. Devo fare o la media di riga o di colonna e ci uscirà di nuovo pari
alla differenza tra la media della colonna j-esima e la media totale. Per calcolarci l’interazione tra 𝛼𝑗 e 𝛽𝑖 abbiamo
bisogno prima di calcolarci la media totale, una volta calcolati tutti e tre e avendo questo valore otteniamo
l’interazione tra i due fattori
Questa slide successiva ci dice questo chi sono 𝛼𝑗 e Β𝑖 e 𝑦𝑖𝑗 . Inoltre, che significa 𝑦̅𝑖𝑗. ? Significa la media lungo tutte le
ripetizioni, infatti K non lo tengo perché è la media delle ripetizioni.

Il risultato ottenuto (l’interazione ) di 𝛾𝑖𝑗 (gamma) è dato dalla media su tutte le ripetizioni, media lungo la riga i,
media lungo la colonna j e la media totale.
Esempio: Abbiamo che W, X, Y, Z sono le quattro alternative del fattore processore; I, J, K, L, W sono le cinque
alternative del fattore workload e per ogni esperimento abbiamo tre repliche.

Al solito, possiamo ricavarci le medie di colonne e le medie di righe (ovviamente lungo le 3 repliche), così come gli
effetti di colonna e gli effetti di righe possono essere valutati allo stesso modo. (Effetto colonna j = elemento j-esimo
sulla riga Col.mean - media)
Le interazioni sono le ultime cose da calcolare prima di avere l’errore e deriva dalla formula segnata nelle due slide
precedenti: 𝑦𝑖𝑗𝑘 = 𝜇 + 𝛼𝑗 + 𝛽𝑖 + 𝛾𝑖𝑗 + 𝑒𝑖𝑗𝑘

Possiamo anche vedere la tabella per le interazioni (ad esempio, se abbiamo l’interazione WI, significa che il workload
I quando eseguito sul processore W, richiede 0.0212 in meno rispetto alla media)
Arriviamo dunque all’errore che è dato dalla differenza di risposta osservata e risposta stimata. La osservata dipende
da 𝑖, 𝑗, 𝑘 mentre quella stimata non dipende da k.
STIMA DELL’ERRORE:
Sia 𝑦̂𝑖𝑗 la risposta stimata pari a = 𝜇 + 𝛼𝑗 + 𝛽𝑖 + 𝛾𝑖𝑗 = 𝑦̅𝑖𝑗 . L’errore è dato dalla differenza della risposta osservata
meno quella stimata, da cui tramite una tripla somma otteniamo la SSE.
Vediamo la slide di sotto con l’esempio e la spiegazione.
Arriviamo finalmente al calcolo della varianza e la sua analisi con MSA e MSE. Rispetto al caso precedente aggiungo la
ripetizione e mi permette di dividere SSAB da SSE.
Allocazione della varianza: Importanza di un fattore
Come al solito consideriamo il modello, eleviamo tutto al quadrato ed effettuiamo la somma di ogni termine.

Significatività:
Relativamente ai gradi di libertà, qui grazie alle repliche riusciamo a dividere l’interazione (A e B) dall’errore. Quindi
abbiamo:
Calcolo il mio F value e vedo che non dipendono più dà a e b ma anche da un r perché ogni osservazione ha anche
una ripetizione. E questi 𝑎𝑏(𝑟 − 1) sono i gradi di libertà dell’errore perché l’errore dipende dalla ripetizione.
Se il numero di gradi di libertà di A è A-1 e il numero di gradi di libertà di B è B-1 allora i gradi di libertà dell’interazione
è dato dalla moltiplicazione dei due.
A seconda del tipo di significatività che voglio calcolare vedo al tabella di Fisher con n pari al numero di gradi di libertà
del numeratore e m quelli del denominatore. Mi devo ricordare che la tabella dipende dal livello di confidenza; quindi,
più alpha è basso più sto imponendo un livello di confidenza maggiore.

Riferito all’esempio di prima, se calcoliamo l’F value otteniamo i risultati mostrati.

Finita la teoria ci chiede per quanto questa lezione sia molto di numeri e calcoli a noi interessa che i concetti siano
chiari, quindi: Come fare un design, quando mi trovo con due livelli e quando mi trovo con un numero di livelli che
varia come possiamo dire se un fattore è importante ed significativo o meno.

ESERCIZIO che vedremo lunedì.

Portare PC e JMP. Portare il PC se possibile perché lo facciamo tutti insieme. Se ci riusciamo ad organizzare gli fa
piacere.
Con JMP che riusciremo a fare? Questo è il primo esempio, abbiamo ora 2 livelli con 2 fattori e ora aggiungiamo tre
ripetizioni, per un totale di 12 misurazioni. Riusciamo a costruire un piano sperimentale e automaticamente ci
costruisce il modello, la sum of square total. Diciamo che ci calcola direttamente questa sum of square ovviamente noi
riusciamo a dire che il modello spiega la maggior parte della variazione totale, in particolar modo vediamo anche la
variazione spiegata dai singoli fattori. Quando andiamo a vedere la somma dei quadrati otteniamo la percentuale
spiegata dal fattore A, stesso per gli altri.
Questa colonna fa riferimento al p value e assume un senso in base al colore. Nel caso in cui arancione vuol dire che
abbiamo un grado di confidenza altissimo che mi rigetta l’ipotesi nulla. Quando è rosso significa che rigetta ancora ma
non al 99%. Quando è nero abbiamo che p-value è abbastanza grande e non posso rigettare l’ipotesi nulla.
Che ipotesi nulla rigetto? Quella del test di Fisher e cosa mi dice? Che la memoria con un p value basso è
statisticamente significativa. Se esce una cosa del genere sto dicendo che la memoria è importante ma anche che è
statisticamente significativo con un test parametrico.
Ultima cosa che vediamo e poi ce ne andiamo:
Questo test di Fisher è parametrico e quando lo posso usare? Quando verifichiamo l’ipotesi di normalità,
sicuramente, ma nel caso di Fisher devo anche verificare la omoschedasticità.
Nel caso in cui l’errore è molto basso, con replicazioni, ha senso dare la significatività? Anche fattori poco importanti
possono avere significatività alta. Si la significatività mi serve sempre proprio perché come concetto statistico mi
consente di trarre delle conclusioni. Invece, se mi trovo un fattore non importante e allo stesso tempo è non
significativo ho una situazione in cui mi risulta essere importante, ripetendo lo stesso esperimento. Quindi non posso
fare ad occhio, devo sempre verificare con un test parametrico o no.

LEZIONE 18 08/11/2021
Experimental Design and Analysis Parte 3
Riprendendo dall’ultima parte della scorsa lezione procediamo nel vedere meglio ANOVA e il suo utilizzo

L’ANOVA che abbiamo visto è chiamato “classico” e si basa sul test di Fisher, il quale si basa su alcune assunzioni:

• L’errore è normalmente distribuito

• La deviazione standard degli errori è costante (parliamo di omoschedasticità)

L’immagine successiva ci permette di capire se i nostri dati provengono da una distribuzione normale o attraverso la
statistica inferenziale ed un test visivo. Possiamo usare il normal quantile plot, visto in Matlab, oppure il test
Kolmogorov-Smirnov.
L’altro test, di Shapiro-Wilk lo troviamo in JMP (da usare se il numero di elementi N è < di 2000), è uno dei migliori test
per verificare la normalità. Tuttavia, siccome essi sono complessi come abbiamo detto ci affidiamo spesso ad
un’analisi visiva dove:
Effettuiamo il plot quantile-quantile, e verifichiamo se i nostri punti non superano determinate barriere.

Oltre a verificare l’omoschedasticità in forma visiva attraverso i residui, che sono le differenze tra la risposta osservata
e quella predetta, possiamo plottare il box plot.
Per il test visivo abbiamo che nella prima immagine (a) non ho un trend perché i punti sono omogenei e non possiamo
dire che vi sia una variazione, cosa che possiamo fare con la seconda immagine (b) visto che vi è poi una diffusione e
più aumento x più vedo il trend.
Per il box plot abbiamo la media, il terzo quartile e primo quartile, e gli estremi con minimo-massimo. Quando l’altezza
del box plot è molto diversa l’una dall’altra possiamo assumere che le varianze non siano uguali e quindi la deviazione
standard all’interno dei nostri dati sono differenti.
Come per la normalità, abbiamo dei test per l’omoschedasticità e sono quelli elencati nella slide e sono tutti presenti
in JMP.
La tabella successiva permette di capire quando applicare l’F test e quando no, ci sono quattro casi:
 1. Il primo caso è detto ANOVA classico, ovvero l’F test, e lo abbiamo visto la lezione scorsa.
2. Nel secondo la normalità non è verificata e quando questo capita non possiamo applicare i test parametrici,
questa cosa è importantissima. Come test non parametrico abbiamo visto la somma dei ranghi in Matlab.
(useremo il test di Kruskal-Wallis e se i livelli dei fattori sono due si può usare anche il Wilcoxon-Test)
3. Il terzo caso non ci permette di assumere l’uguaglianza delle varianze e quindi non possiamo applicare il test
di Fisher, si parla di heteroschedasticità e si procede con ANOVA non parametrico heteroschedastico: in
particolare si utilizza il test di Welch.
4. Nel quarto caso la normalità è violata e la homoschedasticità è violata, ossia si parla di heteroschedasticità,

Nelle slide successive c’è la ripetizione di quanto detto sopra.

Nel caso due applichiamo un altro tipo di test non parametrico, il Kruskal-Wallis test. Questo test può essere visto
come la controparte non parametrica dell’F test.
Nel caso tre usiamo un altro test, Welch’s ANOVA, ma non ci interessa capire come funziona ci interessa solo sapere
quale applicare di volta in volta.

Esercizio DoE 𝟐𝟐 𝟑 (Qui non ci sono slide, c’è la registrazione della lezione)
Quando apriamo JMP facciamo DOE -> custom design (piano personalizzato) una volta aperta la finestra indichiamo
qual è la nostra variabile di risposta e quali sono i nostri fattori. In questo momento non dobbiamo esprimere nessun
obiettivo, come minimizzare il tempo di risposta o che, dobbiamo solo capire in che modo i fattori influiscono su y.
Aggiungi fattore -> Categorico -> a 2 livelli, facciamo per due volte questa operazione. È possibile dargli un nome
qualsiasi ma ovviamente per pulizia e correttezza li chiamiamo, in questo caso, memoria e cache. I valori che possiamo
settare sono categorici e servono sempre per migliorare la leggibilità, impostiamo 4 Mb e 16 Mb per la memoria
mentre 1 Kb e 2 Kb per la cache.
Una volta settato i valori vado su continua e mi esce un modello:
Le interazioni le aggiungo di secondo livello, vado su interazioni e metto secondo livello. L’ultima cosa da fare è settare
il numero di ripetizioni, in questo caso 3, per un totale di 12 misurazioni.

A questo punto ho due scelte, nel caso dell’esercizio posso simulare le risposte e JMP per ogni tipo di osservazione
immette un valore. Se ci interessa dare un ordine di run possiamo aprire la finestra di “ordine delle esecuzioni” e
scegliamo l’ordine che vogliamo, se non mettiamo simula risposte ci fornisce tabelle vuote.

Quando inseriamo noi le y nel caso non simulassimo le risposte, devono corrispondere alla configurazione e devono
avere un corrispettivo con il design.
Ricopiamo però i valori dell’esempio mostrato nelle slide dell’ultima lezione

Quando costruiamo un piano sperimentale del genere come facciamo a calcolare l’allocazione di variazione, ovvero
SST, SSA, etc.? Faccio analizza -> stima modello (fit model), ci viene fuori la specifica del modello quindi ho la y e gli
effetti e ci vado ad inserire anche l’interazione selezionando: memoria e cache e poi premo cross (se non già
presente). Prima di eseguire il run bisogna mettere l’enfasi sul leverage degli effetti in modo da ottenere locazione
della variazione più un'altra cosa che ci mostra ora.
A cosa sono interessato? Prima di tutto al “diagramma dei residui rispetto ai previsti”, perché mi permette di vedere
se posso applicare il t-test non accoppiato, dato che richiede l’omogeneità delle varianze. In questo caso non c’è un
trend sembrano ugualmente distribuite. Ulteriori tabelle interessanti sono:

• Analisi della varianza: mi fornisce la sum square del modello, dell’errore e la totale.

Cosa me ne faccio del modello se non so ogni fattore come ha influito sulla variazione spiegata dal modello?
• Test degli effetti: la sum squadre del modello viene scomposta in memoria/cache e nell’interazione quindi
per capire l’importanza facciamo memoria/C. Totale ovvero SSModello/SST e ad occhio vedo la memoria
come fattore più importante.

Come interpreto questo DoE? Se devo investire qualcosa investo sulla memoria, però prima di fare questa
affermazione vedo se il parametro è significativo o meno. Il parametro “Prob > F” rappresenta il P-value dell’F-test e
deve essere molto basso.
Nel test degli effetti capiamo che la memoria, la cache e la loro interazione sono tutti significativi poiché colorati in
arancione; se verifico la normalità dei residui e verifico l’omoschedasticità (applicando poi l’F test) ottengo che sono
significativi oltre che importanti.
A questo punto dobbiamo verificare la normalità, abbiamo detto nella lezione di oggi dell’esistenza di alcuni test.
Partendo dal salvare la colonna dei residui, visto che mi servirà per l’F test, attraverso i seguenti passi:

Ritorno nella tabella iniziale e me li vedo stesso li. Per plottare i residui rispetto alla normal quantile plot devo fare
analizza -> distribuzione e aggiungo i residui premendo sul bottone Y Colonna ottenendo un nuovo grafico. Sui residui
y seguo questi passaggi

Ottengo il grafico da interpretare, lungo la diagonale rossa ho la rappresentazione della distribuzione dei quantili e
quella normale, mentre i punti neri rappresentano i quantili della mia distribuzione e quindi; vorrei vedere che se i
miei dati provengono da una distribuzione normale devono distribuirsi lungo questa diagonale così facendo
seguono una distribuzione normale.
Visto che tutti i punti nell’immagine successiva si posizionano dentro le bande di confidenza (le due curve) possiamo
facilmente affermare che la distribuzione è normale (e quindi possiamo applicare i test parametrici), ma se alcuni
punti risultassero all’esterno? Bisognerebbe indagare ma il prof ci suggerisce di considerarlo direttamente non
normale. Il perché è ovvio perché non possiamo dire quanti punti necessitiamo per non definirlo normale.
Oltre al test visivo, se vogliamo validarle queste ultime affermazioni una seconda volta, possiamo usare il test di
Shapiro-Wilk che va abilitato facendo un operazione preliminare che è l’abilitare gli installatori legacy (nel caso
abbiate la versione 14 di JMP la procedura è diversa e potete seguire questo link
https://www.youtube.com/watch?v=sqRF_xNKyHY): tasto destro sul triangolino rosso residuo Y -> continuos fit ->
enable legacy fitter, una volta abilitati esce la nuova opzione di legacy fitter -> continuous fit -> normalità, esce una
nuova tabella

Come tutti i test di statistica inferenziale abbiamo un p-value, che però è colorato di nero ed è molto elevato, non
posso rigettare l’ipotesi nulla e confermo così il test visivo.
Adesso che il mio test è parametrico devo sapere se è anche omoschedastico. Ritorno alla tabella iniziale e faccio
analizza -> stima Y rispetto ad X -> in questo caso non faccio più riferimento ai residui ma ai dati che ho. Nella
risposta Y metto Y mentre nei fattori X metto cache e memoria, non sono interessato alle loro interazioni.
Questi grafici rappresentano i valori della Y quando si trova memoria/cache si trova nei suoi due differenti livelli, ora
per capire se sono omoschedastici clicco sulla freccia rossa di “analisi a una via di Y per Memoria”, duale per cache, e
vado su “varianze ineguali”.

Questi sono i famosi test visti ad inizio lezione e non danno tutti la stessa risposta, quali test noi facciamo riferimento?
Ne applicheremo uno solo e sceglieremo uno dei primi tre test tra O’Brien e Levene. Dato che il P value è basso rigetta
l’ipotesi nulla dell’uguaglianza delle varianze e quindi assumo che non sto nel caso di omoschedasticità. Nel caso
contrario avremmo ottenuto l’omogeneità.
Nel caso mi trovassi nel test parametrico eteroschedastico facendo l’analisi dell’uguaglianza delle varianze otterrei un
test di Welch, che è lo stesso da applicare nel caso parametrico non omoschedastico. Il P value mi risulterà basso per il
fattore memoria ma non basso per la cache e così possiamo notare che la memoria è importante e significativo,
nonostante il test non sia omoschedastico; mentre per la cache avevamo che fosse significativo ma applicando il
test giusto scopriamo che non lo è. La considerazione da fare è che la verifica è sempre fondamentale.
Ultima cosa da vedere è cosa facciamo se la normalità non è verificata? Rimaniamo sempre nella pagina di “stima Y
rispetto ad X” e per entrambi i fattori verifichiamo un test non parametrico con il test di Wilcoxon (Che è la somma
dei ranghi in matlab).
Vediamo la tabella finale “Test a una variabile, approssimazione chi-quadrato” e nello specifico il P value.
Questo è tutto quello che dobbiamo sapere per fare l’overview dei nostri dati.
Homework 3 – Web server capacity test DoE
Nelle prime slide c’è una ripetizione di quanto mostrato oggi, per completezza le rimettiamo.
L’esercizio richiede il creare un design sperimentale, il piano sperimentale dobbiamo crearlo noi attraverso il web
server, l’obiettivo è creare una variabile di risposta (tempo di risposta) e usare due fattori (intensità e tipo di
pagine). Non siamo vincolati ad usare 22 risorse, anzi è consigliato aumentare i valori.
Visto che abbiamo solo due fattori possiamo scegliere diverse opzioni:
• Raggruppare insieme l’intensità in due livelli, low e high, e quattro tipi di livelli (quattro differenti pagine)
 • Raggruppare insieme l’intensità in 4 livelli, low, low medium, high medium, high e due tipi di pagine (pagine
di grosse dimensioni o piccole dimensioni, oppure statiche e dinamiche)
• Etc

Come possiamo scegliere l’intensità? L’intensità può essere determinate in termine di percentuale rispetto all’usable
capacity che ho trovato nel capacity test. Il vincolo è che le ripetizioni siano ALMENO cinque.

La cosa importante delle ripetizioni risiede nel fatto che nell’F test io faccio il confronto tra l’F statistico e F value, il
quale è dato dal rapporto di MSA/MSE e il denominatore lo desidero il più piccolo possibile in modo che l’F value sia il
più grande possibile. Per far sì che MSE sia piccolo ho bisogno che i miei gradi di libertà siano i più grandi possibile.
Una volta creato l’esperimento ripeto l’analisi fatta questa mattina.
Potremmo anche fare due volte lo stesso esperimento ma con tempo di risposta diverso. Riprendendo l’immagine
della caratterizzazione del workload possiamo ripetere i passi da fare:

• Partiamo da un workload reale, il quale ha tante richieste diverse tra loro ma non nel senso che un host
richiede la pagina 1, un'altra il 2 e un’altra ancora il 3 perché facendo così quando creo il workload sintetico
non riesco a fare la validazione.
• Con il workload sintetico rifacciamo la workload characterization e prendo i dati di basso livello proprio
perché voglio le risposte al sistema.
• Data validation da fare con matlab, lo script è quello che ci ha fornito lui durante l’ipotesi testing. Quando
eseguiamo il test ci interessa capire la normalità dei dati

É possibile rivedere per bene i passaggi dal minuto 1:10.00.

Ricordiamoci che il numero di componenti principali deve essere lo stesso sia in fase uno che in fase due, questo
perché abbiamo un confronto tra colonne e due matrici con colonne differenti non è possibile. In più, se è possibile,
mantenere la stessa configurazione che mantiene quindi lo stesso tipo di varianza. Il numero di cluster (righe) non mi
crea problemi ma vogliamo avere una varianza spiegata leggermente differente.
Immagine del risultato in Matlab, le variabili sottolineate indicano il valore di ipotesi che è zero se l’ipotesi nulla non
viene rigettata riguardo la normalità dei dati sul K-S test.
Nel caso avessi avuto una distribuzione normale si va a verificare l’ipotesi di uguaglianza delle varianze, ed esiste
vartest2 che mi dice se le varianze sono omogenee o meno e prende in ingresso l’intera matrice restituendomi un
vettore. Per ogni componente principale applico il T test sia nel caso di uguaglianza che non uguaglianza delle varianze
(nel secondo caso devo aggiungere il parametro ‘vartype’).
L’ultima cosa che può crearmi fastidio è quella sul test non parametrico, da applicare quando il test di Kolmogorov-
Smirnov mi dice che i dati non provengono da una distribuzione normale, poiché è differente dagli altri test poiché
restituisce prima il p value e poi h. Non lavora su tutta la matrice ma prima il vettore.

LEZIONE 19 11/11/2021 (LEC_IE_DEP_1 slide 17)

Riprendendo dalla lezione scorsa (Lezione 16) dove abbiamo visto i concetti e gli attributi fondamentali della
dependability.
Abbiamo anche parlato dei non repairable unit e dei repairable unit. Reliability e unreliability sono duali tra loro, la
seconda è definita come il tempo da fallimento del sistema.

Unità non riparabile

Consideriamo X una variabile aleatoria che rappresenta il tempo di fallimento di un’unità. La CDF 𝐹𝑋 (𝑡) di tale v.a.
esprime la probabilità che il sistema fallisca prima del tempo t:
𝐹𝑋 (𝑡) = 𝑃(𝑋 ≤ 𝑡)
Tale funzione viene detta anche unreliability (essendo una CDF sappiamo che è sempre maggiore di 0, monotona
crescente e il suo limite (per t tentende ad infinito) è pari ad 1
Non esiste un concetto di reliability se non esiste il mission time, esso è fondamentale per ottenere sistemi reliable.
Bisogna avere un mission time e tarare che quel sistema, entro un tempo t, abbia probabilità di non fallire data dalle
specifiche.
Tra oggi e domani vediamo come useremo in maniera duale le due.

Repairable unit
L’availability è un attributo di dependability che si applica ai sistemi repairable, ovvero quelli che possono essere
riparati o meglio ripristinati.
Tali unità possono essere ripristinate e tornare operative dopo uno stato di failure. Normalmente posseggono due
tipologie di stati:
• Up
• Down.

Come vedo il funzionamento di un sistema available? È un sistema che si sposta tra un UP e un DOWN e la availability
misura la probabilità di lavorare in questo intervallo di tempo.
L’unavailabiity invece, visto che si esprime come 1 – availability, è la probabilità di trovarmi negli stati DOWN-
ripristinato-UP.
Availability

Questo concetto di availability cosa esprime? Mentre nella reliability io non ho interesse nella durata temporale,
nell’availability si vogliono minimizzare il tempo di down, ma nello specifico i costi che esso mi comporta.
Che vuol dire alzare l’availability? Accorciare i tempi di ripristino. Se minimizzo il tempo di ripristino aumento la
probabilità che ad un certo istante T il sistema funzioni. I tempi di down portano a perdite economiche e misuro il
tutto anche con il numero di 9, più 9 ho meno minuti di down ho in un anno intero.

Dai quattro 9 in poi reliable e available si iniziano a confondersi.

Quando andremo a lavorare, questi concetti li troviamo molto chiari e ben delineati in ambienti NON CRITICI, quando
vado in livelli di criticità alti i costi aumentano e i contorni diventano più sfumati. In cima alla piramide c’è la safety e
questi concetti man mano convergono verso un unico concetto che è la punta della piramide.
Dai 6 nove in poi sto trattando sistemi long life e life critical e anche safety critical, sotto i 4 nove sono non critici e
distinguo bene tra i vari -ability.
Quando faccio ingegneria dei sistemi e faccio assestments devo seguire gli assets dell’azienda se voglio proteggere gli
asset aziendali, devo capire i costi che devo proteggere.
A seconda dell’asset decido che fare e la vita di un ingegnere è un bilanciamento tra costi e tecnicismi. Ad un livello
più da mortale reliability e availability non sono la stessa cosa. Un sistema che fallisce, in media, una volta ogni ora e
che si ripristina in dieci millisecondi è NON RELIABLE ma molto AVAILABLE.

Safety
Per safety intendiamo la probabilità di assenza di un fallimento catastrofico, per catastrofico si intende un
fallimento che porta a conseguenze catastrofiche agli utenti o all’ambiente. Esso è un concetto totalmente
differente dalla reliability.

Che differenza c’è tra la reliability? La reliability è la probabilità che il sistema non fallisca prima di T; la safety è la
probabilità che non esibisca prima di T un fallimento catastrofico.
Questa piccola differenza tra fallimento e fallimento catastrofico fa variare i costi di diversi ordini di grandezza.
Un aereo deve decollare e atterrare in modo safe, non è quindi né un sistema available né reliable. Quindi quando uso
un componente in un contesto catastrofico devo progettarlo in maniera totalmente diversa rispetto alla progettazione
classica; prima di tutto capire come può fallire.
Hazard → Rischio → Costo
Quindi safety e reliability sono due cose completamente diverse e con costi completamente diversi.
Ad oggi, quasi tutti i Sistemi Safety sono pervasi da software e pertanto sono stati necessari opportuni Safety standard
che vadano a regolamentarli. Tra quelli più importanti ricordiamo:
• IEC61508 per componenti elettronici e software
• DO178B per sistemi avionici.
• CENELC EN 50128 per sistemi ferroviari

RISK
Il rischio viene considerato come la probabilità di perdita per unità di tempo e l’analisi dei rischi è la probabilità di
incidente per il costo. Quindi:

𝑅𝑖𝑠𝑐ℎ𝑖𝑜 = ∑ 𝑝𝑟(𝑖𝑛𝑑𝑖𝑐𝑒𝑛𝑡𝑒𝑖 ) × 𝑐𝑜𝑠𝑡𝑜 (𝑖𝑛𝑐𝑖𝑑𝑒𝑛𝑡𝑒𝑖 )

NOTA Di risk assessment (permettetemelo gli appunti sono miei e ci faccio quello che voglio): C’è una differenza in
letteratura tra accidents(incidente) ed incidents (inconveniente), il secondo può anche non generare problemi di una
certa entità o portata, mentre il primo porta con sé danneggiamento e/o una perdita di materiale o effort; ma spesso
verranno usati entrambi o mescolati, tuttavia è giusto far notare la differenza.
Quindi abbiamo che: Costo basso ➔ rischio basso, costo alto ➔ rischio alto. Su questo torneremo e vedremo come si
fa risk analysis.
RELIABILTY, AVAILABILITY e SAFETY non sono la stessa cosa e sono i tre attributi che tratteremo maggiormente, in
particolare vediamo i sistemi reliable che si usano nell’industria.
Se facciamo performance, ricordiamolo i sistemi sono error free, se facciamo dependability i sistemi sono error prone
(soggetti ad errori) ma esistono anche metriche combinate e una di queste è la PERFORMABILITY. La performability è
una metrica combinata che misura le performance del sistema sotto presenza di fallimenti.

Rigetto la situazione in cui il sistema può essere up e down ma assumo che il sistema possa funzionare in maniera
degradata in un certo numero di stati. Se buco una ruota posso arrivare dal gommista anche se il mio sistema è in
modalità degradata.
Il sistema può funzionare sempre, pur se qualche componente è fallito. La performability di che si occupa? Fa misure
dirette di performance in questi stati degradati (S1 – S5).
Attenzione, per fare performability devo fare un modello dei guasti di questo sistema, se no è inutile. Mi devo
chiedere come arrivo in quello stato per misurare? (la fault injection o penetration test sta prendendo piede). Inietto
un guasto, degrado il sistema ed effettuo la misura. Perché il problema del 737 airbus non l’ha avuto? Hanno fatto
subito con il loro digital twin della fault injection e hanno visto che se fosse arrivato nello stato degradato avrebbe
fallito.
Mantainability
Di questa metrica ne parleremo poco ed è la parte legata alla manutenzione, si definisce come l’abilità di un sistema di
essere facilmente modificabile e manutentibile, o di entrare in tali stati.

Ormai non ha quasi più senso di essere usata perché si lavora sui modelli digitali e quindi nulla di fisico.

SECURITY
È combinazione degli attributi CIA (Confidentiality, Integrity, Availability)
• Confidentiality: assenza di “fuoriuscita” non autorizzata
• Integrity: assenza di alterazioni IMPROPRIE del sistema, non solo i dati ma anche i processi e le funzioni.
• Availability: disponibile solo per gli utenti autorizzati

MISURE DI DEPENDABILITY
Ragioniamo per valori medi, tali valori possono essere diversi:
• MMTC mean time to crash ➔ notiamo il TO quindi al primo crash
• MTBC mean time between crash
• MTTF mean time to failure ➔ vale per sistemi reliable
• MTBF mean time between failure ➔ sistemi available
• MTTR mean time to repair
• MDT mean down time
• MTBE mean time between error

Anche se per un available è più importante MTTR (Mean time to repair).

Vediamo il valore medio dell’availability (valore medio in cui il sistema si trova a lavorare in uno stato up) è dato da:
𝑀𝑇𝑇𝐹
𝐴=
𝑀𝑇𝑇𝐹 + 𝑀𝑇𝑇𝑅
Ma abbiamo anche: 𝑀𝑇𝑇𝐹 + 𝑀𝑇𝑇𝑅 = 𝑀𝑇𝐵𝐹

Devo focalizzare i miei sforzi sul tempo di ripristino.

Si mettono dei server in replicazione attiva e come un server si rompe allora la richiesta va sull’altra. Questo riduce
molto il MTTR, un esempio di chi fa ciò è Apache.
Nei sistemi reliable possiamo sfruttare questa cosa? Qual è il valore medio della reliability? Il valore medio della
reliability è proprio MTTF, che è il valore medio della probabilità che il sistema non fallisca in un tempo T.

ESEMPIO, ho la linea temporale T e parto da 0, ho un previous repair e ho un fault occurs (che o si attiva o inietto), il
guasto è latente fino a che non si attiva e diventa un errore.
La fault latency è il tempo tra nascita del fault che si attiva e diventa errore.
Una volta che si attiva l’errore in questo error latency abbiamo che si è avuto un’error detection (posso rendermene
conto con un try catch). Quando poi un errore viene rilevato bisogna passare al ripristino, dal suo rilevamento al
ripristino abbiamo il repair time.
Concentriamoci sulla reliability.

Reliability modelling techniques – Fault tolerance/avoidance

(Lec_IE_DEP2_RELTEC_NEW)
Cerchiamo di ragionare sulla reliability del sistema senza che lo stesso non sia ancora progettato. Facciamo un quadro
generale e iniziamo a declinare quello che abbiamo detto sui sistemi reliable.
I sistemi dependable sono quei sistemi che devono funzionare anche in presenza di guasti, è una riduzione sintetica
dei concetti fino ad adesso ma ci è utile per evitare di appesantire il discorso

Esistono delle tecniche per incrementare la dependability che sono FAULT INTOLERANCE (O FAULT AVOIDANCE) e la
FAULT TOLERANCE.
Esempio: devo andare ogni giorno a lavorare e se appendo un giorno non mi pagano per un anno. Vado con la 500 o
con la Mercedes? Con la Mercedes perché voglio fault intolerance. LO SPARAGNO NON È MAI GUADAGNO.
La tecnica di fault avoidance è una tecnica che sostanzialmente passa a componenti più affidabili per ridurre la
possibilità di fallimenti, lo svantaggio è che se si rompe un componente per forza di cose devo cambiarlo.

Se ho 20 cinquecento? Se l’availability non è bassa allora forse conviene.

Come tollero l’errore? O replico il sistema o replico gli input.
La ridondanza può essere o temporale o spaziale. Entrambe le tecniche hanno l’obiettivo di rilevare un guasto e di
tollerarlo e il sistema deve funzionare anche in presenza di guasti.
Nella tecnica temporale replico le esecuzioni, nella ridondanza spaziale replico i sistemi e se gli output sono uguali
sono confidenti che il sistema sia giusto.
La logica è che se raccolgo gli output posso dire se il sistema va bene se almeno due su tre hanno risposto la stessa
cosa. Tale tecnica si chiama voto a maggioranza

Ripetiamo la definizione della reliability e il MTTF

Giusto per chiarire, attenzione a MTTF e MTBF che possono essere simili in alcuni sistemi. Però per la reliability non
parliamo di MTBF ma di MTTF. Nel caso di tempo a fallimento esponenziale abbiamo i dati nella prossima slide

Se abbiamo una serie di somme esponenziali, cosa che capiterà spesso, abbiamo la MTTF pari a quella mostrata nella
slide precedente.

Duplication
Non bisogna pensare che la duplication sia la configurazione peggiore da usare, perché è quella che costa di meno e
quindi molto usata. Ma che cos’è? È un sistema duplicato che non può avere lo scopo di tollerare guasti però posso
rilevare ed è quello che succede in alcuni aerei, viene usato quindi a scopo di detection.
Lo schema è dato da n° unità duplicate e all’uscita di tutte viene messo un comparatore che uguaglia le uscite e nel
caso segnala l’errore. Ovviamente le due unità devono essere sincronizzate.

Quali sono i pro e i contro di una duplicazione?

Sicuramente permette di rilevare e quindi opera in safety mode, i problemi stanno nel numero addizionali di
componenti nei clock e comparatori affidabili; ma soprattutto quando uso la ridondanza riduco il MTTF.
ATTENZIONE C’è UN ERRORE NELLA SLIDE ED è MTTF NON MTBF

Esempio: Supponiamo che il tempo a fallimento di ogni task sia esponenziale e che la probabilità che il sistema fallisca
prima di T, o meglio la reliability, sia la probabilità che uno dei due fallisca. In altri termini la reliability del duplicator è
pari al prodotto della reliability, se il failure rate è 𝑒 −𝜆𝑡 esso fallirà il doppio delle volte.
Un esempio pratico può essere quello di un webserver nel quale non è sempre conveniente aumentare il numero di
server poiché in questo modo aumenta il failure rate, aumenta la manutenzione necessaria al corretto funzionamento
e MTTF diminuisce. Questo comporta un aumento dei costi e i failure possono essere più elevati.

LEZIONE 20 12/11/21
Ieri abbiamo parlato di tecniche per l’aumento della reliability e abbiamo visto la fault tolerance e la fault avoidance.
Con la fault tolerance spesso si usano tecniche per la ridondanza che può essere di due tipi:

• Spaziale, usata molto nei sistemi industriali

• Temporale, usata molto in ambito software
Il primo esempio di ridondanza è la duplication e si usa solo per scopo di detection, tipicamente se il sistema riceve
due output diversi segnala che vi è stato un errore e il comparatore se ne accorge segnalando il guasto. (sistema con
propagazione di ripristino).
Perché a livello software devo stare attento a queste configurazioni? Se c’è un bug nel sistema, il quale mi fornisce
un ingresso mal posto, ad esempio un carattere strano, se lui sbaglia a formare l’IP e io duplico il sistema e fornisco ad
entrambi i sistemi un input mal posto entrambi mi risponderanno male. Tale situazione si chiama common mode
failure; è una probabilità molto bassa ma porta i disastri.
Nel software se lo replico e basta ho tutti fallimenti comuni anche nella replica.
Capiremo a tempo dovuto cosa si fa in ambito software, anticipiamo che ci sono tecniche di ridondanza temporale e
che se volessi replicare userei la diversity ovvero, non uso lo stesso componente ma parto dagli stessi requisiti e faccio
una fork dei sistemi utilizzati per realizzare la funzionalità (sistemi sw, hw linguaggio etc).
Devo stare attento alla ridondanza perché ho visto che i failure rate aumentano e allora il sistema fallisce prima (un
concetto relativo). Dipende dal mission time.
Riportiamo nella figura sottostante un albero che fornisce una rappresentazione grafica della Reliability di un sistema.
La reliability in un sistema può essere affrontata (Osserva la figura) con:

• Sistemi ridondanti: Possono essere o fault tolerance (in cui utilizzo una ridondanza fisica maggiore di due o
una ridondanza temporale) o sistemi di fault detection (in cui utilizzo la duplicazione) di tipo Offline e Online.
• Sistemi non ridondanti: applico tecniche di fault intolerance o fault avoidance quindi utilizzo in generale
componenti più costose ed affidabili.
N-Modular redundancy
Finito con la ripetizione andiamo a generalizzare le architetture di duplication, ovvero non ho più una sola unità ma N
unità. Ma a cosa mi servono N unità? Due unità garantiscono la rilevazione, tre mi permettono il mascheramento del
guasto (Fault masking), quattro unità permettono una doppia linea di funzionamento.

Più crescono le unità più in certi contesti il sistema è reliable. Cominciamo a vedere quelli più usati come sistemi di
bordo degli aerei.

TRM Triple Modular Redundancy.

Estensione naturale della duplication, con la differenza che non faccio detection ma “correggo” perché replico le linee
(nei sistemi sono cavi) e poi c’è un voter che può essere configurato in vari modi.
Perché si parla di Voter? Perché maggior parte dei casi il mascheramento di un fallimento è realizzato per mezzo del
voto di maggioranza. Se 2/3 danno un voto (fail/working) allora il tutto sarà funzionante o meno mascherando il
sistema. Il voter può essere configurato con il caso di restituire l’errore solo in caso in cui tutti danno risposte diverse;
in safe mode vuol dire che o tutti e tre danno la stessa risposta o non parte. In alcune condizioni maschera e in altre
può anche fermarsi, dipende dalla criticità del componente.
Ripetiamolo, la ridondanza non è la panacea.

Nella slide di sopra abbiamo un poco tutte le tecniche, nella radice ho la reliability e può essere aumentata con un
primo split basato su sistemi ridondanti o non ridondanti.
Nel secondo caso l’unica cosa che posso fare, non ho molti soldi (o meglio il livello di criticità non è elevatissimo)
procedo con fault intolerance e quindi compro componenti più affidabili.
Le primo caso invece avendo il livello di criticità alto, ci basiamo nuovamente sul tipo di spesa. Se non abbiamo molti
soldi, o il livello di criticità non è elevato, si fa fault detection aumentando così l’availability.
Se il livello di criticità è alto devo usare la fault tolerance, la tolerance o la ottengo con un approccio di
mascheramento (dinamico o statico, lo becco e non lo faccio propagare) oppure la dynamic redundancy con i TMR e i
sistemi di self repair.
Se i sistemi di larga scala come Netflix e tutti i carrier su 5g iniziano a fare test su in-production online, nel senso che
se voglio fare dei test devo anche dimostrare che quelle statistiche che ho sono equivalenti al test bag reale. Se il test
bag su scala geografica dipende da tante cose che non sono manco modellabili non saranno mai statisticamente
equivalenti al reale.
Netflix, dall’inizio ha detto che i test si fanno sui sistemi veri.
Quello che noi facciamo è assessment, e come vediamo dall’immagine è valutazione quantitativa dei sistemi.

Metodi di quantificazione della Dependability

Le misure di dependability si basano su due approcci:
• Approcci basati in maniera diretta (su misure).
• Approcci basati su modello.

Le misure dirette le vediamo sulla parte dei fallimenti ma si hanno anche nei sistemi di intrution detection, cioè fare
misure dirette sui dati anche se non è facile.
Gli approcci su modello sono maggiormente usati in quando l’approccio su misure non può essere applicato quando il
sistema non è stato ancora realizzato.
Devo avere problemi che non sono sempre banali, in questa parte a livello industriale non fanno solo sempre misure
dirette. Se consegno un treno o un armamento non metto mai mano al sistema! Uso sempre un modello infatti
tendono a dare le specifiche e un mock up e io ci pazzeo. Anche per i sistemi critici ho quasi sempre un modello e io
lavoro con un modello; anche perché molte volte il sistema non lo tengo. Molte aziende come Hitachi, partecipano ad
una gare, forniscono un requisito di reliability etc

Vedremo modelli analitici che possono essere di due tipi:

1. Senza spazio di stato che sono molto semplici ma molto potenti. I modelli senza spazio di stato
possono essere:
 o reliability block diagram
o fault tree.

Sono due facce della stessa medaglia, infatti, uno ti dice quando non fallisce e l’altro quando fallisce. Per
una soluzione rapida questi modelli assumono che ogni componente di sistema sia indipendente
dall’altro

2. Con spazio di stato (modelli markoviani)

Possono avere delle sfumature e quindi andremo a vedere questi modelli che sono senza spazio di stato, e danno una
soluzione rapida, ma che cosa vogliono in ingresso? Una caratterizzazione di elementi componenti. Il sistema deve
essere caratterizzato da degli elementi di cui abbiamo informazioni che componendoli danno la reliability del sistema
totale.

Reliability Block Diagrams

Il RBD consiste nel:
1. Suddividere il sistema in un insieme di moduli che non si sovrappongono (non overlapping modules)
2. Assegnare ad ognuno di questi un Unreliability 𝐹𝑖 o Reliability 𝑅𝑖 (𝑡)
3. Calcolare la reliability totale del sistema 𝑅𝑠𝑦𝑠 (𝑡) o la funzione 𝐹𝑠𝑦𝑠
Cosa sono gli RDB? È possibile dividere il sistema in blocchi componenti, ogni blocco lo posso caratterizzare in forma
più semplice con la sua reliability o il suo duale.
L’obiettivo è subito trovare la reliability o unreliability totale del sistema. Quali sono le assunzioni? ATTENZIONE ALLE
ASSUNZIONI:
1. I fallimenti devono essere indipendenti quindi anche la modellazione deve essere indipendente. Quando
costruisco una reliability block diagrams mi devo assicurare che sia i moduli che i fallimenti dei moduli siano
indipendenti
2. Se un modulo è fallito deve essere SEMPRE fallito. Alcuni componenti, si mettono in uno stato di errore
anche se transitorio (fail safe).
3. Un sistema viene considerato fallito quando un numero MINIMO di componenti fallisce. Bisogna trovare una
condizione di fallimento.
4. Nel momento in cui il sistema entra in uno stato di fallimento, altri fallimenti non possono far tornare il
sistema in uno stato funzionante

Collegamento in serie tra componenti

Un sistema SERIE è un sistema in cui un sistema 1 è collegato in serie con il sistema 2. Quando fallisce 1 in serie a 2? Il
sistema non fallisce quando non falliscono tutti e due (pensiamo alla success line che attraversa i sistemi 1 e 2) quindi
il sistema fallisce se fallisce il 1° o il 2° o tutti e due.

Che conviene modellare qua? Reliability o unreliability? Con la unreliability ho tre condizioni, la reliability ha una sola
condizione.
Questo è un consiglio dato dall’esperienza, non trattiamo sempre la reliability possiamo usare anche la unreliability.
Che vuol dire il sistema non fallisce? Non fallisce uno AND non fallisce l’altro. La probabilità di un insieme unito ad un
altro, se sono indipendenti, è il prodotto delle probabilità. La unreliability della serie è il prodotto delle reliability.
La unreliability totale è un esponenziale, se come scritto il failure è esponenziale, con failure rate pari alla somma dei
failure rate; ma questo non mi sorprende perché sto aumentando gli elementi.
Possiamo dice che una serie equivale al prodotto delle reliability e poiché un prodotto di reliability (che vanno da 0 ad
1) è sempre la reliability del sistema essa è minore o uguale del minimo delle reliability.
Quindi la configurazione in serie ci fornisce un sistema più debole di quello semplice.
Collegamento in parallelo tra componenti
Vediamo ora i sistemi paralleli. Ci sono degli SPARES (delle ombre), non ho un solo sistema ma è dove ho più sistemi
replicati. SPARE NON È DUPLICATION! CON LO SPARE SE SI SCASSA UNO SOPRAGGIUNGE UN ALTRO.

In questo caso il sistema fallisce quando tutti i componenti falliscono. Per cui con la reliability sono 3 condizioni con
la unreliability solo 1 quindi prendo unreliability 𝐹𝑖 = 1 − 𝑅𝑖
La 𝐹𝑠𝑦𝑠 del sistema totale a che è uguale? Alla probabilità che il sistema 1 fallisce prima di T e il sistema 2 fallisce prima
di T. Poiché i fallimenti sono indipendenti abbiamo anche qui la moltiplicazione, allora è uguale a F1 per F2.
Ma allora a che è uguale? (1 − 𝑅1 )(1 − 𝑅2 ) → 𝑅𝑠𝑦𝑠 = 1 − 𝐹𝑠𝑦𝑠

Questa è la configurazione del parallelo. Lo SPARE è UNA COPIA DI BACKUP. IL SISTEMA NON FUNZIONA Più QUANDO
TUTTI SI SCASSANO.
Il parallelo di componenti indipendente segue la legge del prodotto di unreliabillity
Vediamo un sistema che posso scomporre in serie e parallelo (altro homework che discuteremo prima). Dato un
sistema composto da A e B , e C e D (2 CPU e due memorie ad esempio) ho un parallelo su due linee e su ogni linea ho
una serie.

La formula non sottolineata è una serie di paralleli.

Allora quale è la reliability del sistema? Quello basso perché ho più percorsi, la reliability di sotto infatti è quasi due
volta la reliability di sopra.
Altro esempio, dato un sys di trasmissione vocale più affidabile di una linea normale se voglio aumentare l’affidabilità
devo sostituire alle serie i paralleli. Come si fa il calcolo? Sviluppo il parallelo e moltiplico le probabilità, posso vedere
l’esempio nelle slide successive.
Ovviamente sui RBD ci possiamo giocare anche di più, attenzione però a che cambiamenti facciamo perché il modello
è bello ma è un astrazione della realtà. Questo modello può essere usato anche per rispondere a domande più
complesse come quella mostrata nell’esempio successivo:
Per ottenere una reliability di 6 nove quanti spare devo avere?

Devo stare attento a questo calcolo perché se sono esponenziali c’è l’effetto del failure rate e questo lo vedremo al
mission time. Anche i nostri esercizi avranno cose come queste. Sembra sempre tutto bello e semplice ma come per i
circuiti non è sempre detto che possiamo semplificare e ridurre, come nell’esempio successivo.
Un modo per risolvere il sistema è quello di enumerare il success path e c’è un teorema che ci permette di dire che
se trasformiamo il RBD in un parallelo di success path la reliability del nostro sistema è minore o uguale di quella
del sistema nuovo

Upper bound theorem

Tale teorema dice che, la reliability del sistema è minore o uguale della reliability del parallelo di ogni success path. (Si
ottiene un upper bound, cioè un valore oltre al quale non può andare),

Attenzione al minore o uguale, se i path sono indipendenti è uguale, se sono dipendenti sono minori ed otteniamo
quindi un upper bound.
Perché ci potrebbe servire un upper bound? Perché molte volte si cerca di capire se con determinati componenti si
può costruire un sistema con una reliability che soddisfa un requisito (Un determinato valore). Il teorema ci permette
di capire, in maniera rapida, se l’upper bound del sistema è maggiore del requisito (Se è minore non ha proprio senso
continuare a lavorare se non rispettiamo tale specifica).

Reliability Modelling
Per i calcoli ci affideremo alla regola di Bayes per le probabilità condizionate, il quale ci dice che l’evento A dato B è
𝑃(𝐵 |𝐴)𝑃(𝐴)
pari a 𝑃(𝐴|𝐵) =
𝑃(𝐵)

Se ho una rete come quella mostrata di seguito, con 5 blocchi, posso sviluppare il RBD come due sotto RDB con uno
che assume C3 down e l’altro con C3 up. La probabilità totale è data dalla reliability del primo, per il fallimento del
terzo componente, più il secondo, per la probabilità che il terzo componente non fallisca.

Questo si chiama anche conditioning.

Vediamolo nell’esempio precedente, possiamo dire che la reliability totale è quella mostrata nella slide
Il problema è: da dove parto? Non sempre si riesce in un passo.
Posso partire dal modulo B e posso dire che ci sono due Block diagram, B lavora o fallisce. Nel caso due lo sappiamo
risolvere (open è fallito). Scrivo che la reliability totale come mostrato:

Ora devo trovare il 𝑃(𝑠𝑦𝑠𝑡𝑒𝑚 𝑤𝑜𝑟𝑘𝑠 /𝐵 𝑤𝑜𝑟𝑘𝑠) e lo sviluppo guardando il grafico sulla destra. Se C lavora è un corto
circuito con A-F in parallelo in serie con D, nell’altro caso ho una serie a tre e so risolvere entrambe.

Lezione 21 15/11/21
Model Based performance analysis (01-markov_chains_2021)
Cosa vedremo in questo gruppo di quattro lezioni? Allora sostanzialmente abbiamo già visto che ci sono diverse
tecniche per analizzare le performance o l’affidabilità di un sistema, però ci siamo focalizzati sulle tecniche basate su
misure.
Quello che vedremo in queste lezione è come ricavare dei parametri di performance del sistema, senza averlo
davanti. Uso quindi dei modelli per la dependability, sostanzialmente ne usiamo due:
• Analitici: insieme di equazioni che rappresentano i parametri che voglio valutare
 • Simulativi: Hanno bisogno di un simulatore e servono per riprodurre il comportamento dinamico di un
sistema. Tutte le quantità che evolvono nel sistema sono di solito caratterizzate da un certo quantitativo di
aleatorietà. Ovviamente è fattibile se il sistema converge.

Ma perché studiamo i modelli? Come detto prima la cosa più importante è che non hai bisogno del sistema
funzionante, ma anche perché le misure potrebbero risultare molto costose (come le misure di affidabilità su un
aereo). Aiutano inoltre a comparare velocemente le alternative e per trovare condizioni di upper bound in condizioni
ideali oppure, per validare altre tecniche ed effettuare quindi la cross validation

Andiamo per ordine, cosa andremo a valutare?

• Misure di dependability (funziona? Per quanto tempo?): ossia tutte quelle relative all’affidabilità tra cui
Reliability, Availability, Downtime, Security e Safety.
• Misure di performance (dove assumiamo che non ci siano errori, assumendo che funzioni quanto bene lo
fa?): throughput, Probabilità di Blocco, Tempo di risposta in termini di media e distribuzione.
Tali misure, oltre che dal sistema reale, possono essere ottenute mediante l’utilizzo dei modelli.
Ma che cos’è un modello? Un modello è una visione astratta di un sistema reale che ne include solo gli aspetti
rilevanti, ovvero decidere quali sono i valori che mi permettono di raggiungere l’obiettivo dell’analisi. Quando si
costruisce il modello di un sistema, occorre decidere a che livello di astrazione e a che livello di dettaglio tale modello
dev’essere descritto.
In particolare, osserviamo che aumentando il livello di dettaglio, aumenta anche la complessità del modello
(diminuisce il livello di astrazione):
• Al più alto livello di astrazione, il modello descrive il sistema semplicemente come una “black box”(Sistema
ingresso-uscita)
• Man mano abbassando il livello di astrazione e aumentando il livello di dettaglio poiché ad esempio si vuole
porre l’attenzione su altri aspetti rilevanti del problema in esame:
Esempio: Potremmo essere interessati a descrivere il sistema studiandone anche i sui “utilizzatori” (in figura i
“terminals”). Si osserva che, talvolta, potrebbe essere necessario anche considerare la popolazione degli
utenti, cioè il numero effettivo di utilizzatori del sistema, in quanto ciò potrebbe incidere su alcuni parametri
di performance.
• Andando ancora di più nel dettaglio, potremmo essere interessati ad analizzare internamente il sistema,
suddividendo quest’ultimo in sottocomponenti.

Un modello troppo dettagliato potrebbe essere inadatto allo studio di un particolare parametro di performance

Perché dobbiamo includere quanti utenti devono usare il sistema nel mio modello? Perché la possibile sorgente di
input al mio sistema potrebbe influenzarne il comportamento. Se il sistema è il mio portatile e lo uso solo io ho che
tutti gli input possono arrivare da me e lo uso per 8/12h al gg ho un utilizzo del 50% su 24h; e quindi limito i possibili
stati in cui può evolvere ogni parametro di performance del mio sistema.
Ogni volta che un utente, attraverso i terminali, sottopone una richiesta rimane in attesa dell’output e quindi non può
più generare carico poiché deve aspettare.
L’ingresso al sistema dipende da una popolazione limitata. Se il numero di utenti non mi impatta il sistema assumo
allora una popolazione infinita.
Ma con un modello del genere che cosa non posso fare (Ovvero un modello che vede soltanto i primi due blocchi in
alto)? Con un modello del genere ho delle prestazioni che non vanno bene per quello che devo fare io poiché non
vedo tutti gli elementi, posso dire su quale aspetto devo lavorare? BLOCCATA LA REGISTRAZIONE, SE QUALCUNO HA
INFO IN Più LA AGGIUNGESSE.
Lavoro scompattando ulteriormente il sistema arrivando al modello alla base della piramide e arrivando anche a
capire qual è un possibile collo di bottiglia, ad esempio aggiungo più memoria per aumentare le prestazione.

Capacity
In termini di modelli, che cos’è la Capacity? In generale la capacity specifica l’abilita di una entità
(persona/organizzazione)o di una risorsa misurata in termini di quantità e livello di qualità su intervallo di tempo
esteso.

Consideriamo, ad esempio, i grafici throughput-carico e response time-carico di un sistema web server. Per quantità
della capacity ci riferiamo al throughput, mentre per qualità ci riferiamo al tempo di risposta. Quando misuriamo la
capacità su un intervallo di tempo esteso, diciamo che stiamo misurando la capacità a regime.
Possiamo osservare che, nel grafico, le linee tratteggiate sono state ricavate attraverso misure su modelli mentre le
linee continue da misure sul sistema reale.
Infatti, la retta rappresentante la Nominal Capacity del sistema, nonché la curva tratteggiata del primo grafico che sale
e poi si assesta, sono state ricavate da modelli attraverso cui sono state studiate le performance del sistema rilassando
alcune assunzioni.
Come ottengo la capacità nominale però? E che cos’è? La capacità nominale è una capacità che non riesco ad
ottenere con tecniche basate su misura. Io la ottengo in condizioni ideali e la riesco ad ottenere solo con tecniche
basate su modelli (anche la usable capacity la otteniamo con i modelli).
Vediamo un esempio, e vediamo come funziona la capacità nominale di una linea ADSL:
Ho uno spazio di banda che suddivido in sottoportanti e ogni sotto portante ha un support di 15Bits/symbol e ottengo
che il massimo rate della word è di 8128kbps.
Questo è utile agli operatori per vendere la linea.
Cosa succede se acquisto la linea e si prende una portante inferiore? Che cosa non è considerato in quel modello?
Il numero effettivo di portanti collegate, le quali dipendono da quanto sono distante dalla centrale.
Se voglio capire effettivamente la capacità nominale della ADSL dalla mia abitazione io devo modellare altro. Come la
distanza dalla centrale, ed in base a questa attenuazione, ottengo una perdita generale e riesco ad ottenere qual è la
massima velocità a cui riesco a collegarmi.

Ma io se attacco il modem mi connetto e faccio lo speed test perché mi fornisce ancora altri valori. Che cosa non sto
considerando? Un sacco di cose (congestione di rete, overhead, capacità del servente etc).
Sulla slide della capacità ho detto che misuro la quantità e la qualità del servizio. La qualità del servizio la posso vedere
con il ping e ho visto che la capacità la vedo su intervalli di tempo lunghi quindi questo speed test che è rapido non mi
fa capire bene nulla.
I modelli sono invece più affidabili per le misure di prestazione su internet.
Vediamo un altro esempio e ci iniziamo ad avvicinare al mondo delle code.

Ho un server multithread apache e ho una sorgente esterna di richieste http, le richieste sono accettate e vengono
messe in una coda di thread pronti ad essere schedulati. Ogni 20ms ho in media una risposta.
Questo è un modello con cui posso descrivere un web server e che posso ottenere? Un valore per la capacità
nominale e delle informazioni per il tempo di risposta.

Questo modello mi ha fatto astrarre tutto quello che ci sta sotto e mi anche dei valori che sono utili per il progetto del
sistema.

Highest level of abstraction

Vediamo ora in dettaglio lo studio dei modelli. Al più alto livello di astrazione ho un modello black box e in black box
posso misurare:
- Il rate (numero) di job in ingresso = 𝜆 numero di richieste medie al secondo (Nessun job viene scartato)
 - Osservo il throughput cioè le risposte prodotte dal mio sistema e posso vedere quant’è il tempo di risposta
del mio sistema.
- Response time T, misuro il tempo che passa tra arrivo richiesta e output di richiesta completata.

Queste quantità sono ovviamente aleatorie e assumo di conoscerne almeno la media, quindi media di arrivo di job e
tempo medio di risposta. Un’ulteriore assunzione è che non scarto mai, tutto quello che entra prima o poi viene
completato.
Posso usare queste info dall’esterno per capire che succede all’interno di questa scatola. Dentro questa scatola ho le
richieste che attendono di essere schedulate. Potrei voler studiare che concorrenza abbiano questi due sistemi e
quanti utenti ci sono all’interno del mio sistema.
Questo è possibile con la legge di Little

La legge di Little
Siamo interessati a studiare cosa succede mediamente all’interno del sistema, a partire dalla sola osservazione del
tasso degli arrivi 𝜆 e del tempo di risposta 𝑇 (essi sono gli unici parametri che riusciamo a misurare). Quanti job
concorrenti vi sono all’interno del sistema?
La legge di Little mi dice che il numero di utenti all’interno del sistema ed è pari al rate di ingresso per il tempo
medio di risposta. (Questo è una sorta di coltellino svizzero e lo posso usare su più sistemi) Quando faccio il capacity
test con JMeter impongo un certo tasso di ingresso, andiamo ad eseguire il test e ottengo dei tempi di risposta, se
faccio la media ottengo questi due fattori e posso capire qual è l’effettivo grado di concorrenza del sistema.
Questa formula è valida per qualsiasi sistema o parte di sistema e varia solo se tutto il traffico accettato dal sistema
viene effettivamente eseguito e non si perde nulla all’interno. Se parte del traffico viene bloccato posso applicare la
legge di Little solo alla parte effettivamente completata.
Ci sarà una parte dell’esame che riguarda un esercizio scritto su modelli e teoria delle code, ci verrà dato materiale
per esercitarci. Su web docenti ci sarà un file con esercizi svolti che stanno anche delle slide. Questo blocco di
esercitazioni copre l’intero programma di teorie delle code e modelli ed è parte dell’esame. Mi devo esercitare sul
processo di modellazione, capire un sistema a che modello può corrispondere e che tecniche uso per ottenere dei
parametri e delle misure di interesse.
Vediamo l’esercizio:

Sistema di packet inspection con pacchetti che arrivano con un tasso di 50ms (INPUT), leggendo tutta la traccia
capiamo che abbiamo pochi elementi del sistema e sappiamo solo che ci sono due componenti; vogliamo studiare le
quantità medie e posso applicare Little al primo sottosistema e ho info sul tasso di risposta del primo sottosistema.
 1
Per il primo sottosistema ho un tasso di ingresso pari ad 𝜆 = 𝑚𝑠 e informazioni sul tempo di risposta, nel primo
50
sottosistema ho in media 3.2 utenti. Posso fare lo stesso sul secondo sottosistema e so che il 20% di lambda va là e
ottengo 1.6 utenti.
il numero totale di pacchetti nel mio sistema è 3.2 + 1.6 = 4.8
la legge di Little ci aiuta su quantità medie. Per capire che succede devo capire come il sistema evolve nel tempo.

Modello stocastico
Ripetiamo che la legge di Little è applicabile solo su quantità medie. Se ho un ingresso aleatorio, anche lo stato
interno evolve come un processo aleatorio. Devo modellare lo stato all’interno del mio sistema, che nel nostro
esempio era il numero di utenti, in maniera più dettagliata. Pensiamo per esempio ad un sistema fatto con due
processori dove il tempo viene diviso in slot temporali e che funziona così:

Un job può arrivare ad ogni time slot e un arrivo può avvenire con probabilità 𝛼 = 0.5 o meno. Quando un processore
è occupato può completare un job con probabilità beta di 0.7 se tutti i processori sono occupati il job è perso. Se il job
è sottomesso quando entrambi sono occupati ma uno ha completato il job viene accettato.
• Quale è la long term efficiency? Per efficienza si intende quanto bene ho sfruttato i due core
• Che frazione ho di job persi?

Cosa cambia dal modello di prima? ORA DEVO CONSIDERARE CHE CI STA DENTRO IL SISTEMA E NON MI BASTA IL
BLACK BOX. Mi serve sapere anche gli stati all’interno ed è un poco più complesso. Per studiare e modellare ho
bisogno di altri richiami.
Processo stocastico
Che cos’e un processo stocastico? Un processo che per ogni istante di tempo T mi restituisce una variabile aleatoria.

In particolare, come può essere un processo stocastico?

• Se 𝑡 ∈ 𝑅 allora il processo è a Tempo Discreto

• Se 𝑡 ∈ 𝑁 allora il processo è a Tempo Continuo

• Se 𝑋(𝑡𝑛 ) è una v.a. continua, allora il processo è a stato continuo

• Se 𝑋(𝑡𝑛 ) è una v.a. continua, allora il processo è a stato discreto
Processi Markoviani
Un processo di MARKOV è un processo aleatorio che fa una assunzione in più. È un processo senza memoria e lo
stato che può assumere il processo al tempo n+1, considerando tutta la storia del processo, dipende solo
dall’istante temporale corrente, quindi, non dipende dalla storia passata.

Un processo a stato discreto è anche detto CATENA, una catena può essere a TC o a TD.
Quindi vedremo le catene di markov a tempo continuo e a tempo discreto.

Catene di Markov a Tempo discreto

La rappresento come un grafo dove gli stati sono i nodi e le transizioni tra gli stati sono disciplinati da una probabilità
che vedo sugli archi. Supponiamo un PC con due stati ON e OFF, se sto in OFF con una certa probabilità vado in ON e
con un’altra probabilità resto in OFF.
Questo grafo posso rappresentarlo anche con una matrice di transizione P in cui ogni elemento 𝑝𝑖,𝑗 rappresenta la
probabilità di passare dallo stato 𝑖 a 𝑗 nell’istante di tempo successivo. (Le righe rappresentano lo stato di partenza, le
colonne lo stato di arrivo in un passo temporale)
Oppure attraverso un vettore di probabilità che mi dice per ogni istante di tempo che probabilità ho di stare in ON e
che probabilità di stare in OFF.
Quindi il nostro obiettivo è descrivere l’evoluzione dello stato, ossia si vuole conoscere la probabilità di trovarsi in
tutti i possibili stati di arrivo dopo k passi.

Evoluzione nel tempo (Transitorio TD)

Come evolve nel tempo? Dopo un passo vado da 𝑖 a 𝑗 dopo due step in che stato mi trovo? E con che probabilità?
La calcolo come probabilità di stare allo stato i corrente ad uno dei qualsiasi stati del sistema, per la probabilità di
passare da quello stadio intermedio allo stato.
Questa sommatoria è l’elemento della matrice 𝑃2 e ottengo un’altra matrice in cui ogni elemento è dato da questa
somma e ogni elemento della matrice mi dice la probabilità che ho di passare da 𝒊 a 𝒋 in due step.
Come evolve lo stato del sistema? Il vettore di probabilità è dato dallo stato N precedente per il vettore di probabilità.
Posso iterare questo procedimento e arrivare a caratterizzare fino al momento iniziale che è 𝜋(0) ∗ 𝑃𝑁 .

Che vuol dire? Che ad un certo istante di tempo nel futuro che probabilità ho di stare in un preciso stato? Dipende
da come è iniziato il sistema e da come ho assegnato le probabilità.

Comportamento a regime (TD)

Vediamo dopo un intervallo di tempo molto ampio che succede e se esiste un regime. Se il limite per N che va ad
infinito di questo vettore 𝜋 esiste ed è finito ( 𝑙𝑖𝑚 𝜋(𝑛) = 𝜋), è chiamato distribuzione stazionaria di probabilità
𝑛→∞
della catena. Questo vettore definisce, a regime, che porzione di tempo il sistema trascorre in un determinato stato.
Se penso al sistema ON/OFF il 𝜋(1) mi dice la percentuale di tempo in cui il mio sistema viene usato.
Regime vuol dire che l’info sullo stato iniziale è stata dimenticata dal sistema e a regime ottengo che il vettore 𝜋
soddisfa l’equilibrio e quindi: 𝜋 = 𝜋 per la matrice P, poiché sto a regime non varia più e lo stato prossimo è uguale
allo stato corrente. Questa è la condizione di regime.
Se riesco a risolvere questo sistema ottengo questa soluzione 𝜋 di regime. Se il sistema è fatto così può avere infinite
soluzioni. Posso però imporre un’altra condizione, ovvero a regime la somma di tutte le probabilità deve fare uno,
vediamo come risolvere l’esercizio. Devo capire come posso modellare il sistema con una catena di Markov.

Ho un sistema con due processori, posso modellare lo stato zero in cui sono entrambi non attivi, in 1 uno e attivo e
l’altro in idle in 2 sono entrambi attivi. Il mio sistema evolve in tempo discreto.
Ho capito che ho tre stati e mi devo segnare le probabilità, 𝛼 è la probabilità che all’interno del time slot corrente
arrivi un job.
Quindi la probabilità che mi trovi nello stato zero di idle e ci rimanga è data dalla probabilità che non arrivi nessun job.
Viceversa, transito nello stato uno con probabilità 𝛼, un altro requisito diceva che con lo stesso time slot non
potevano arrivare più di un job e quindi la probabilità di transitare da zero a due è nulla.
Nella seconda riga ho invece che sono nello stato uno e devo transitare nello stato zero, la probabilità è 𝛽 che ho
completato un job e non ne arriva uno nuovo. Mentre passo da uno a due quando mi arriva un job e non ho
completato il precedente. E così via per gli altri modelli. Assegno la probabilità ad ogni arco del mio modello.
Ci basta questo? Ottengo un modello che descrive pari passo le specifiche che stavano nella descrizione. Devo capire,
adesso che tengo il modello, come studio l’efficienza e la probabilità di perdere job.
Vado a sostituire i valori e ottengo la matrice P.

Come modello l’efficienza? L’efficienza a regime la vedo (per convenzione) come 1 quando sono tutti i processori
occupati, ½ se ho un solo processore occupato e sto usando il primo sistema al 50% o la esprimo con 0 se sto idle.
Per quanto riguarda l’altra cosa (la frazione di job perso), è la probabilità di perdere un job o la probabilità di perdere
un job poiché tutti i processori hanno i time slot occupati e nessun job è stato completato all’arrivo di uno nuovo

Per calcolarmi queste due quantità ho la necessità di calcolarmi il vettore 𝜋. Per risolvere devo fare il sistema con 𝜋=
𝜋 ∗ 𝑃 e vedo che ho 3 equazioni che sono linearmente dipendenti (perché infinite soluzioni) e allora sostituisco una
delle 3 qualsiasi.
Ottengo un sistema che posso risolvere e questo sistema è idle per il 0.399%, per il 0.494% sto usando un core e per il
10% uso entrambi i core quindi l’efficienza è del 35% e la probabilità di perdere un job è dello 0.48%.

Posso provare a capire come funziona per un sistema con singolo processore e vedere come varia con un solo
processore efficienza e la probabilità di perdita di un job.
Devo definire un nuovo modello, nuovi obiettivi, calcolare l’efficienza e confronto i risultati.

Catene di Markov a Tempo Continuo

Il tempo è quello reale e risulta difficile calcolare la probabilità di transizione tra gli stati quindi metto una variabile
aleatoria aggiuntiva chiamata holding time 𝑯𝒊 che mi fa capire quanto tempo rimango in uno stato prima di passare
ad un altro stato.
La proprietà di Markov è simile e ci dice che lo stato prossimo non dipende da quanto tempo ho trascorso nello stato
corrente o in quelli passati. Ancora una volta è senza memoria.
L’unica distribuzione che soddisfa questo vincolo a TC è la distribuzione esponenziale. Tutti gli eventi del sistema
sono scanditi da questa distribuzione esponenziale e dal tempo di servizio distribuito esponenzialmente.
Anche qua posso rappresentare con un grafo (solo che ho una variabile interna, questo fa sì che non sia possibile la
presenza di auto anelli) ma ho solo le quantità q sulle transizioni che mi dicono quante volte al secondo passo da uno
stato all’altro.

Questi stati 𝑞𝑖𝑗 rappresentano tempo di permanenza in uno stato per la probabilità di passare da uno stato i ad uno
stato j. Per convenzione, sulla diagonale della matrice otteniamo la somma di tutti gli altri valori con il segno meno;
questo per avere segni simili a quello TD.
Come per le catene a TD oltre alla matrice di transizione dei tassi devo definire il vettore di probabilità.
Come nella catena a TD anche in quella a TC studio l’evoluzione del tempo, solo che invece di avere un equazione alle
differenza sostituisco con una DERIVATA. Quindi come varia la probabilità di T nel tempo, vado a moltiplicare sempre
il vettore P per la matrice Q.

Comportamento transitorio (TC)

Ricordiamo che la soluzione di un sistema di equazioni differenziali non è univoca e la soluzione particolare può essere
trovata utilizzando il vettore di condizioni iniziali 𝑝(0).
La soluzione di questo sistema è differenziale e una soluzione particolare la ottengo conoscendo le condizioni iniziali.
Solo che a me non interessa il transitorio, ma che succede a regime. Per fortuna a regime, la quantità non varia più e
allora la derivata è 0 perché la quantità è costante.

Comportamento a regime (TC)

Allora quel sistema di equazioni si traduce in un sistema di equazioni lineari dove moltiplico 𝑝𝑄 = 0. Anche qua ho
infinite soluzioni quindi devo imporre la condizione di normalizzazione (dove tutte le probabilità devono fare 1).
Esercizio a TC a slide 38. (risolto sul blocco di docenti).
Perché qui dovrei modellare il fatto di avere i due serventi attivi separati? Perché dalle specifiche uno è differente
dall’altro ed è più veloce quindi le prestazioni sono differenti.
Un processo di Markov particolare a TC è il processo di nascita-morte in cui ci sono transizioni solo tra coppie di stati
adiacenti.
Processo di nascita e morte (particolare processo continuo)

Ho un processo di nascita (esponenziale) caratterizzato da un tasso 𝜆, poi ho il processo tempo di servizio distribuito
esponenzialmente con 𝜇.
Perché conviene studiare, non ricavando la matrice? Perché lo posso fare in maniera più agevole soprattutto su
catene che sono molto lunghe con infiniti stati. Devo ricavare delle interazioni che mi permettono di studiare l’iesimo
elemento grazie a dei pattern.
Con nascita morte applico una equazione più semplice che è il bilancio dettagliato. Se taglio la catena ad un certo
punto, la probabilità di stare nello stato N, per il tasso di uscita da N, è uguale alla probabilità dello stato N-1 per il
tasso di ingrasso N-1. Questo vale ovunque.

Scrivo tutta una serie di equazioni e in più posso scrivere una ricorsione che mi scrivere con una produttoria il tutto.

Questo fino ad arrivare a 𝑝0 . Se tutti i lambda e mou sono uguali ho la parte finale dell’equazione
L’altra equazione che devo sempre poter applicare è la condizione di normalizzazione ed è la somma di tutte le
probabilità deve essere uguale a 1.
Con queste due equazioni posso studiare sistemi con un numero infinito di stati purché siano numerabili. Questo è il
modello sottostante ad ogni modello a coda che vedremo.
Queste ultime cose ci servono per poter studiare per bene le code. Questo può essere utile se voglio studiare quanta
memoria voglio mettere nel sistema.

LEZIONE 22 18/11/2021 (02-queuing_theory_p1_2021)

Model Based Performance Analysis
Ricapitoliamo quello che abbiamo visto lunedì 15. Abbiamo visto cosa significa modellare un sistema per ricavare
parametri di performance e abbiamo visto i modelli a scatola chiusa dove, guardando ingressi e uscite, ricaviamo info
sul numero di utenti nel sistema e abbiamo visto che per specifiche di sistema più complesse dobbiamo vedere come
evolve un sistema.
Grazie alle catene di Markov possiamo vedere come evolve nel tempo lo stato del sistema e come funzionano le
catene di Markov a TD e a TC, come poterle analizzare e come modellare delle specifiche di sistema con un sistema di
equazioni modellati dalla catena di markov. Oggi vediamo i MODELLI A CODA.

Modelli a Coda
Molti modelli a coda sono nati a partire dalle catene di markov. In una delle ultime slide di lunedì abbiamo visto
markov per un processo nascita-morte. Una catena con transizioni che possono avvenire solo tra coppie di stati
adiacenti.
Nel calcolatore ho molte code ed esse entrano in gioco ogni volta che ho un numero di risorse limitate (serventi) e ho
molte più richieste di quanti sono i serventi e quindi devo disciplinare l’accesso.
Che vediamo oggi? Una introduzione sui modelli a coda e di come descrivo l’arrivo e il servizio e come formulo
l’ipotesi che siano processi di markov (arrivo e servizio). Poi vedremo il modello semplice a singolo servente per poi
estendere a multipli serventi. Alla fine, vedremo i sistemi con blocchi, ossia sistemi in cui limito la capacità.
Quindi formalizzando il tutto, che cos’è un modello a code? Un modello a code è un modello utilizzato per analizzare
situazioni di contesa su un numero finito di risorse, in particolare:
• Le risorse prendono il nome di serventi
• Il numero di utenti (o jobs) è molto maggiore del numero dei serventi.
Come vedo una coda?
Una coda è rappresentata da una caterva di parametri:
• Ho il processo degli arrivi 𝐴(𝑡) che è un processo stocastico, rappresentato con una certa distribuzione,
• Il processo delle partenze 𝐷(𝑡) che dipende dagli arrivi ma anche dalla velocità e dal numero,
• Il processo di servizio 𝑆𝑖 (𝑡) (dipende dal servente e da quanto ci mette ad elaborare),
• Dalla capacità della coda 𝐾𝑞
• Numero di server 𝑛
• Dalla disciplina di scheduling all’interno della coda 𝑆𝐷.
Tutti questi sono i parametri di una coda.
Lo stato del modello rappresenta sempre cosa c’è all’interno quindi:

• Il numero di job all’interno della coda 𝑁𝑞 ,

• Numero di job all’interno dei serventi (e quindi job in esecuzione) 𝑁𝑠
• Il numero di job totali nel sistema 𝑁 = 𝑁𝑞 + 𝑁𝑠 .

Mentre per le metriche di performance abbiamo:

• Il tempo di risposta 𝑇, ovvero una richiesta che entra in un sistema del genere quanto ci mette ad essere
elaborata?
• Tempo d’attesa (queue time) 𝑊, oppure ci si può chiedere quanto tempo aspetta nella coda prima che verrà
servita da uno dei serventi?
𝐷(𝑡)
• Throughput , oppure quale è il throughput di questo sistema?
𝑡

Da tutti questi parametri risulta complesso classificare tutti i modelli a coda. Un modello usato spesso prevede la
notazione di KENDALL.
Notazione di Kendall

Ogni sistema si classifica in base ai valori scritti in quest’ordine e modo:

• A: processi di arrivo, distribuzione del tempo degli arrivi, quindi, può essere M (markoviano) o D
(Deterministico) o G (Generico), poi ho altre lettere (Lo stesso per la S che sono i processi di servizio)
• m il numero di serventi disponibili
• c il numero di posti che ho a disposizione nella coda e il numero di posti che ho a disposizione nel servente
(capacità del sistema)
• p dimensione della popolazione del mio sistema (info su chi usa questo sistema a coda o se i job hanno delle
sorgenti limitate).
• S.D: disciplina di scheduling (omesso se è FIFO)

Quindi descrivo il tutto con: A/S/m/c/p/SD

Una volta capita questa convenzione per i sistemi a coda, come capisco qual è il modello più appropriato da usare?
Devo capire i parametri della convenzione di sopra e saprò quale modello è appropriato. Quindi mi aiuta in
modellazione del sistema.
Andiamo ora a vedere le tipologie di modelli che possiamo incontrare:
1. M/M/1: arrivo markoviano, tempi di servizio distribuiti esponenzialmente con Coda infinita e popolazione
infinita e un singolo servente. Modello più comune e più facile da studiare
2. M/M/m dove aggiungiamo più serventi e non più solo uno
3. M/M/m/K vado a limitare la capacità

Processo Markoviano
Che cos’è un processo di markov? O un processo memoryless? C’entra la distribuzione esponenziale. Un processo di
1
markov lo vedo come un processo di solo nascita: essendo basato su distribuzione esponenziale con media ed è
𝜆𝑖
rappresentato dal tasso di arrivo 𝜆 e lo stato mi indica quanti arrivi ci sono stati fino al tempo T.

Con il tasso 𝜆 mi arriva un job e transito nello stato 1, stessa con lo stato “due” mi indica che ci sono stati due arrivi
(processo di sola nascita) in particolare se, i 𝝀 SONO TUTTI UGUALI e non dipendo dagli arrivi, è Detto processo di
Poisson.
Più formalmente si definisce processo di Poisson come un processo in cui il tempo di inter-arrivo è distribuito
esponenzialmente ma il tasso medio non varia in base allo stato.
Ma perché potrebbe variare il tasso? Ad esempio, se sono in una situazione di scoraggiamento (es troppe persone e
io non entro nella posta) a quel punto lo stato del sistema ha avuto un influenza sull’arrivo.
Se ho una popolazione finita con tre utenti ed ogni utente sottomette job con un passo 𝜆. Quando un utente entra nel
sistema, aspetterà la risposta del sistema; quindi, i job che possono arrivare saranno solo quelli che aspettano
all’esterno e quindi 2𝜆.
Adesso io non faccio nessuna di queste assunzioni e prendo il sistema M/M/1 ed intendo il processo degli arrivi come
processo di Poisson = Il numero di eventi compresi tra 0 e il tempo corrente.

Sistema M/M/1
Il sistema M/M/1 ha processi di arrivo “Poissoniani”; quindi, il tempo tra un arrivo e l’altro è distribuito
esponenzialmente con media 𝜆. Il tempo di servizio è distribuito esponenzialmente con tasso 𝜇 e il rapporto tra tasso
medio di arrivi e completamento è detto 𝜌 ed è fondamentale perché indica l’intensità di traffico.
Supponiamo capacità infinita e popolazione infinita.
Qual è la catena di markov corrispondente a tale modello? Quella mostrata di seguito

Vi sono arrivi esponenziali e tempi di servizi esponenziali quindi questo sistema lo modello come una catena di Markov
e più in particolare come processo di nascita morte.
Questi Job prima o poi verranno completati con tasso 𝝁 e quando il sistema completa un job si ha che la richiesta
all’interno del sistema mi porta da un stato 𝑖 ad un stato 𝑖 − 1. Questo modello quindi mi descrive la situazione di
attesa per ottenere una risorsa
Esempio: Si parte dallo stato 0 non vi è alcun job e il servente è in idle. Arriva un job con tasso 𝜆 e il servente viene
attivato (inizia a servire quel job) e si passa allo stato 1. Se arriva un altro job con tasso 𝜆, esso viene messo in attesa
(poiché il servente sta servendo quello precedente) e si passa allo stato 2. Non appena viene completato un job con
tasso 𝜇, allora si ritorna allo stato precedente, in questo caso allo stato 1.
Lo stato del sistema è il numero di utenti al tempo T e come studio questa catena? Posso evitare di studiare
esaustivamente la catena di markov usando il sistema completo ma con un processo di nascita morte ci sono delle
equazioni che sono più semplici da studiare e sono:
- Distribuzione stazionaria è data da una relazione ricorsiva semplice, immaginiamo di separare la coda tra un
generico stato 𝑛 − 1 ed 𝑛; quello che vale per ogni taglio fatto è che il tasso 𝜆 per la probabilità dello stato
 𝑛 − 1 è uguale al tasso 𝜇 per la probabilità dello stato 𝑛, 𝜆𝑝𝑛−1 = 𝜇𝑝𝑛 chiamata anche equazione dettagliata
al bilancio. Questo ci fa esprimere qualsiasi 𝑃𝑛 ,ricorsivamente, in funzione di 𝑃(0).
- Ho risolto il sistema? NO, ho solo trovato tutto in funzione del solo 𝑃(0) ma non so chi sia e dobbiamo
trovarlo. Allora io devo imporre che la somma di tutte le probabilità deve fare 1 perché a regime si troverà
in uno di questi stati.
Ma allora il mio 𝑃(0) è dato da 1 meno la sommatoria delle probabilità. Questo perché è una serie
1
geometrica che converge ad se 𝜌 è minore di uno. Ma 𝜌 è proprio la somma delle probabilità e quindi
1−𝜌
sicuramente è minore di 1. Se 𝜌 fosse maggiore di 1 la serie divergeva e quindi entrano sempre più job nel
sistema e il tempo di attesa diventa infinito
Se il sistema non converge si dice che il sistema non è stabile.
Se il modello divergesse non si potrebbe fare in modo che si ragioni fino ad un certo stato e poi lo si resetta? Non è più
un processo nascita morte così però lo posso modellare. Il fatto che non ammetta un regime (a regime la coda è piena
all’infinito) non vuol dire che non lo studio ma lo studio nel transitorio dove ho equazioni differenziali. Ho poco
interesse a calcolare parametri di performance.
Una volta calcolata la distribuzione di probabilità posso ricavare tutti i parametri di performance del modello

M/M/1 performance indicators

Vediamo il primo (Frazione di tempi in cui il sistema è attivo), vogliamo studiare la probabilità che il servente sia
attivo e quindi un numero di utenti maggiore di 0 quindi posso scriverlo come 1 − 𝑃{𝑁 = 0} = 𝜌.
Per il secondo abbiamo la media degli utenti con a disposizione tutte le probabilità degli stati e possiamo pesarlo per
il numero di utenti in ciascuno stato. Se mi trovo nello stato zero ho 0 utenti, più 2 per la probabilità che sto nello
stato due etc etc. Per risolvere questa serie ancora una volta uso la serie geometrica i 𝜌𝑖 sono 𝜌𝑖 (1 − 𝜌). Se metto a
fattore uno di questi 𝜌 e lo metto fuori ho una sommatoria 𝑖 ∗ 𝜌𝑖 (1 − 𝜌), che è proprio la derivata e poiché la derivata
𝝆
della somma è uguale alla somma delle derivate ottengo come numero medio di utenti.
𝟏−𝝆

Che cosa devo ricordare? Solo questo pezzo all’inizio e come ottengo il numero di utenti dalla distribuzione degli
stati.
𝟏
Ottenuto il numero medio di utenti uso la legge di Little, la quale mi dice che il tempo medio di risposta è .
𝝁−𝝀

Per trovare il tempo medio di servizio o response time applico la legge di Little.
Se ho prima il tempo di risposta medio ottengo il numero di utenti invertendo la legge di Little.
Qual è il tempo medio di attesa? Lo posso scrivere come tempo medio di completamento meno il tempo di servizio. Il
tempo totale da quando un job entra nel sistema, fino a quando esce, è dato da:

Per la media del numero di utenti nella coda ho che posso sempre applicare la legge di Little ottenendo così il
numero medio di utenti dato il tempo di attesa.

Waiting times (tempi d’attesa)

Con che probabilità ho l’accodamento? Ossia arriva il job e il servente è occupato? È la probabilità che il numero di
utenti sia maggiore di zero a tempo di arrivo.
Come capisco che succede negli istanti di arrivo? Il tempo di attesa è uguale al numero di utenti nella coda
moltiplicato per il loro tempo di servizio cioè intuitivamente se mi accodo devo aspettare che vengano serviti tutti
quelli prima di me.

Mediamente aspetto il numero medio di utenti per il loro tempo di servizio, anche in questo caso devo considerare il
numero medio di utenti nel sistema nell’istante di arrivo di un job; che è diversa dal numero medio a qualsiasi tempo.
Questa legge non è valida in generale ma è valida solo quando ho arrivi poissoniani e vale come proprietà PASTA
(Poissano Arrivals See Times Averages).
La proprietà PASTA afferma che se il processo degli arrivi è un processo di Poisson, allora quello che succede in ogni
istante di arrivo coincide con quello che succede nel sistema a regime.
Il comportamento del sistema nei tempi medi coincide con il comportamento del sistema osservato solo negli
istanti di arrivi. Se le barre rosse sono gli istanti in cui un job arriva nel sistema, sommo e faccio la media ed essa
andrà a coincidere con la media di tutta la curva. QUESTO SOLO SE SONO PROCESSI DI POISSON.
Quindi se il processo è Poissoniano il tempo medio di attesa della coda è calcolabile mediante la formula vista sopra:
𝐸[𝑊] = 𝐸[𝑁] ∗ 𝐸[𝑆]
Dove:
• 𝐸[𝑊] è il tempo medio di attesa in coda
• 𝐸[𝑁] è il numero medio di jobs nel sistema
1
• 𝐸[𝑆] = è il tasso medio di servizio di un job
𝜇

Dalla prossima lezione iniziamo a scardinare questa assunzione che però accumuna tutti i sistemi M/M.

Response time Distribution

Finora abbiamo visto il tempo di risposta medio però per analizzare qualcosa più nel dettaglio dobbiamo ipotizzare
una disciplina di scheduling fisso. La disciplina di scheduling non era entrata nel merito dell’analisi, ma per studiare il
tempo di risposta, abbiamo che esso è influenzato dalla politica di scheduling. Se cambio, andrei ad impattare sul
tempo di risposta dei task e se volessi dare priorità ai task più brevi ne sceglierei uno che guardi alla durata dei task.
Il tempo di risposta è influenzato dalla politica di scheduling, anche la FIFO assegna una legge esponenziale con
tempo medio pari a 𝜇 − 𝜆. La dimostrazione di questa cosa è complicata e la accetto per dogma di fede.
NOTA PER CHI VOLESSE: La ottengo con la Trasformata di Laplace di una distribuzione statistica per modellare il fatto
che il prodotto tra queste diverse distribuzione (N+1 utenti) per il tempo di servizio (S), e che N ha una distribuzione
geometrica. S è il tempo di servizio quindi il prodotto è una esponenziale con questa forma:
Posso ora chiedermi com’è il tempo di attesa? Allora il tempo di attesa lo calcolo come riportato sopra, ovvero:
𝑃{𝑊 > 𝑡} = 𝑃{𝑊 > 𝑡|𝑁 < 1}𝑃{𝑁 < 1} + 𝑃{𝑊 > 𝑡|𝑁 ≥ 1}𝑃{𝑁 ≥ 1}
Il tempo di attesa, sapendo che N è minore di uno (e quindi non ci sono job nel sistema), è pari a zero. Mentre il
tempo di attesa, sapendo che ci siano un numero maggiore o uguale ad 1 di utenti ha lo stesso andamento di un
sistema del tempo di servizio. Se so che il sistema è sempre attivo e non è mai scarico allora il sistema coda funziona
come M/M/1.
Il simbolo 𝜌 prende il nome di probabilità di accodamento.

Vediamo un esempio per capire a che può servire un sistema M/M/1. Sicuramente non posso costruirlo ma lo posso
usare per dimensionare un sistema e voglio trovare la capacità giusta.
Supponiamo di avere un web server dove le richieste sono bufferizzate in memoria e sono servite sequenzialmente,
arrivano in maniera esponenziale e i tempi di servizio sono distribuiti esponenzialmente.
Qual è la minima dimensione della coda al fine di non trovarla piena con una probabilità del 99,99%?
Come ragiono a questo sfruttando quello che ho visto in un sistema M/M/1? Lo modello notando che quando il
sistema reale non è pieno funziona come un sistema a capacità illimitate e allora tutte le richieste possano essere
elaborate.
La probabilità che la coda sia piena è la probabilità di avere L+2 users nel sistema. La mia dimensione L , che è la
dimensione della coda, la trovo in questo modo; impongo che la condizione per riempire il sistema sia L+2 questo
perché se ho la coda piena e arriva un job uno sta già nel servizio e quindi non riesce ad entrare.
Allora scrivo come probabilità che sia minore di L+2. La probabilità che sia minore di L+1 è data dalla somma della
probabilità degli stati.

Alla fine, che otteniamo? Un’altra volta la sommatoria della serie geometrica solo che non è infinita ma è troncata e
1−𝜌𝐿+2
quindi converge sempre e converge alla quantità (1−𝜌)
come risultato ho 𝜌𝐿+2 .

La mia domanda è perché 𝑷{𝑵 < 𝑳 + 𝟐} = 𝑷{𝑵 ≤ 𝑳 + 𝟏}? Perché è un numero intero e quindi se L è MINORE
ALLORA L’ALTRO è MINORE UGUALE.
Vediamo come ricavare questo dato, imponendo il fatto che il sistema non sia pieno con la probabilità di blocco
inferiore a 10−4 . Vado a risolvere la disequazione di seguito e ottengo che la L minima per evitare che s’affonn tutto
cos è L pari a 15
Altro esercizio che possiamo provare a fare è il seguente. La coda è modellata come M/M/1 con arrivi poissoniani e
tempo di servizio esponenzialmente distribuiti. Questo è un esercizio al contrario ho info su che modello ho e sullo
stato, voglio quindi capire la percentuale di tempo in cui il servente è in uso.
Consiglio extra: Abbiamo il numero medio di job in attesa = 5, e sappiamo che la formula che dipende dal parametro 𝜌
è:
𝜌2
𝐸[𝑁𝑄 ] = 𝜆𝐸[𝑊] =
1−𝜌

Da questo ricaviamo 𝜌 che rappresenta la percentuale di tempo in cui il servente è in uso.

Altro esercizio che posso provare a fare è uno switch di rete.

Similmente al dimensionamento della coda di prima vado a vedere quanto deve essere grande la memoria dello
switch per far sì che gli utenti in ingresso non trovino la coda piena con probabilità del 99%

Sistema M/M/m
Che succede se al modello aggiungo uno o più serventi? Ho un modello M/M/m dove 𝑚 è il numero di serventi.

Il tempo di servizio è sempre distribuito esponenzialmente il processo di arrivo è di Poisson, capacità e popolazione
sono infinite.
Che cambia rispetto a prima? Il processo di arrivo è uguale, ma cambia il throughput visto che ho più serventi esso è
maggiore.
Qual è la catena di markov corrispondente a tale modello? Lo modello come processo di nascita-morte in cui lo stato
𝑁(𝑡) indica il numero di job totali all’interno del sistema al tempo t.
Cosa cambia rispetto al sistema M\M\1? Il tasso di completamento 𝝁 dipende da quanti serventi sono attivi .
Se ho 𝑚 serventi e ho un solo user all’inizio lavora un solo servente. Il tasso di completamento al secondo stato
raddoppia, ho due esecuzioni in parallelo e questo numero arriva fino al massimo di serventi. Quando ho riempito i
serventi ho un throughput massimo pari a 𝑚𝜇, con 𝑚 numero dei serventi. Se ho attivi tutti i serventi (Ossia il numero
di job nel sistema 𝑁 ≥ 𝑚) il comportamento è identico ad un M/M/1 più veloce.
Come risolvo una catena di nascita-morte di questo tipo? Il ragionamento è lo stesso del modello precedente, quindi
modello come una catena di markov ma devo stare attento al distinguere la condizione di quello che succede per il
numero di stati inferiore al numero dei serventi, e quello che succede dopo. Le equazioni di bilanciamento dettagliate
sono sempre le stesse, ma queste relazioni cambiano se mi trovo prima o dopo di m.

• Se 𝑖 < 𝑚 non tutti i serventi sono attivi, poiché vi è un numero di 𝑖 job minore del numero dei serventi. In
particolare, il tasso 𝜇 cresce con 𝑖
• Se 𝑖 ≥ 𝑚 tutti i serventi sono attivi. Pertanto, il tasso rimane costante a 𝑚 ∗ 𝜇 (il throughput non cresce più
avendo i serventi tutti occupati)
Quindi questo vuol dire che c’è continuità e quando i serventi non sono tutti attivi, occorrerà analizzare le
distribuzioni di probabilità degli stati iniziali.
• Altra cosa importante è distinguere Il parametro 𝝆 da 𝜶, il primo è l’intensità di traffico per servente pari a
𝜆
, e vado a considerare il throughput massimo del sistema. Ed è anche la condizione di stabilità. Quando
𝜇𝑚
voglio supportare un traffico in ingresso maggiore ho che la condizione di stabilità è sempre data da 𝜌 che si
può estendere anche al caso 1 con m = 1
𝜆
• Il secondo parametro è il rapporto ed è per convenzione detto intensità di traffico ed è rappresentata con
𝜇
𝜶.
Andando a fare i conti (simili a quelli visti prima, facciamolo per M/M/2 che è il più semplice) sostanzialmente che
posso ricavare? Posso ricavare 𝜌𝑚 in funzione di 𝜌0 , ovvero il caso prima di processore 2 (in cui ho due serventi attivi)
e il caso da 2 in poi.
Abbiamo quindi imposto le detailed balance equation:
𝜇𝑝1 = 𝜆𝑝0 , 𝑖=1
{
2𝜇𝑝1 = 𝜆𝑝𝑖−1 , 𝑖>1
Da cui ricaviamo le probabilità di regime che sono quelle sulla destra nell’immagine. Imponiamo poi la condizione di
normalizzazione e ricaviamo il valore 𝑝0 , da questo ricaveremo tutti gli altri.

M/M/m performance indicators

Come variano i parametri di performance? Posso usare gli stessi ragionamenti che ho visto per il sistema M/M/1 e
quindi trovare il numero medio di utenti, probabilità di sistema occupato, etc.

Per la prima formula abbiamo la probabilità 𝑷𝒒 che all’arrivo di un job tutti i serventi siano occupati. Dopo la prima
sommatoria sfruttiamo la formula di M/M/1 quando 𝜌 < 1, dopo ho che la serie è geometrica e converge.
Per il numero medio totale di utenti nel sistema abbiamo che esso è dato dal fattore 𝜌 moltiplicato per 2, infatti 𝝆 mi
dà la percentuale di quanto il mio sistema si trova in utilizzo moltiplicato per il numero di serventi. Ottengo quindi
mediamente il numero di serventi attivi; se 𝜌 vale 50% in un sistema con 2 processori sto dicendo che mediamente ne
ho solo 1 attivo. Questo lo sommo al numero medio di utenti in coda per avere il numero totale. Potrei anche
applicare Little e ricavare il tutto come il caso M/M/1. Queste relazioni ci fanno un poco capire come funzionano i
parametri del modello.
Se applico Little a tutto il sistema ho il numero medio di utenti su 𝜆 o il tempo medio di attesa.

Osservazione importante: È vero anche il viceversa, ossia se abbiamo informazioni sui tempi medi di attesa e risposta,
possiamo sfruttare la legge di Little per ottenere informazioni sugli indicatori di performance.
ESEMPIO DI UNA COSA INTERESSANTE: voglio confrontare due tipologie di sistemi e capire qual è meglio. Meglio 2
m/m/1 in parallelo o una unica coda e 2 serventi?

Per quello che ho visto se ho un carico molto molto elevato e i serventi lavorano sempre il comportamento di questi
due sistemi è molto simile, pure perché M/M/2 da una certa si comporta come M/M/1.
Quindi guardando i tempi di risposta voglio caprie quale mi risponderà prima.
• Sistema A
L’intensità di traffico per servente è 𝜌 e lo ragiono solo su una coda quindi: supposto che bilancio il carico in ingresso
𝜆/2
ottengo 𝜌 =
𝜇
𝜌
Il numero medio di utenti totali nel sistema (formula di M/M/1) è 𝐸[𝑁] =
1−𝜌

𝐸[𝑁] 2
Tempo medio di risposta del sistema: 𝐸[𝑇] = =
𝜆/2 2𝜇−𝜆
 • Sistema B
Qui abbiamo due serventi, quindi il tasso di servizio è potenzialmente 2𝜇.
𝜆
L’intensità di traffico per servente è 𝜌 =
2𝜇

2𝜌
Il numero medio di utenti totali nel sistema (formula di M/M/2) è 𝐸[𝑁] =
1−𝜌2

𝐸[𝑁] 4𝜇
Tempo medio di risposta del sistema: 𝐸[𝑇] = =
𝜆 4𝜇2 −𝜆2

Determinato il tempo medio di servizio per entrambi i sistemi, dobbiamo individuare quale sia più piccolo. Posso
moltiplicare e dividere per ottenere un confronto tra le due quantità e ottengo che il sistema A ha un tempo di
risposta maggiore del sistema B.

Perché B? Può essere un problema di bilanciamento di code. (ad esempio, in quella a 2 m/m/1 una coda e piena e
l’altra è vuota).

Modello M/M/m/K a capacità finita

Consideriamo ora il modello M/M/m/K, ossia stesso lo modello visto finora ma con una capacità finita K. Rimuovendo
la capacità infinita adesso la coda ad un certo punto finisce, ho m posti nel servente e K-m posti in coda.
Se un job arriva e il sistema è pieno scarto il JOB. Come funziona la nascita morte di questo sistema e come modello
la catena di markov corrispondente? Ho un numero finito K di stati 𝑁(𝑡). Altre differenze?
È simile al modello M/M/m ma il numero di stati è finito ed è pari ad 𝐾 + 1.

Tale sistema non può mai divergere o mi fregherei quindi il sistema è stabile! Dunque, la differenza dei sistemi a
capacità infinita e quelli a capacità finita sta che sono tutti stabili. Qual è la condizione di stabilità per un sistema a
capacità finita? Lo è sempre per ogni 𝝆
Anche analiticamente, quando ho la condizione di normalizzazione la somma di tutte le probabilità deve fare uno e ho
una somma troncata a K termini, quindi una somma di numeri positivi non può mai divergere. Vediamo qualcosa sulla
probabilità di perdita dei job.
Ho detto che posso perdere job e, la probabilità di avere la coda piena è la probabilità che mi trovo nello stato K. Se
arriva un altro job si frega e non entra.
Il tasso di job bloccati è pari al tasso di arrivo per la probabilità che mi trovi nello stato K, il throughput è pari al tasso
di arrivo 𝜆 per la probabilità che non sto nello stato K (che non vengano bloccati). Questo perché sto sfruttando
implicitamente la proprietà degli eventi di Poisson.
La probabilità di blocco è la probabilità che nel momento dell’arrivo sto nello stato K. Grazie alla PASTA queste due
coincidono e quindi la probabilità di blocco che sto allo stato K nell’arrivo è uguale alla probabilità che sto nello
stato K in un momento qualsiasi.
Come uso Little? Ho possibile perdita di job, ma devo considerare solo la frazione di job accettati dal sistema. Quindi
devo sempre vedere prima la situazione del sistema.

Sistema M/M/m/m Lossy system

Esiste poi un caso molto particolare ed è un sistema di tipo M/M/m/m dove K = m; quindi, non ho una coda ma è un
sistema degenere ed è detto sistema di full block e si usava per le linee telefoniche prima. Dovevo allora capire quante
linee telefoniche fosse possibile avere in una centrale perché una linea era una comunicazione.
Se tutti i server sono occupati il job è perso e non c’è attesa.

Questo è un primo modello che mette in relazione due cose, l’utilizzo delle risorse e l’intensità di traffico. Questo
rientra in toto nella definizione di capacity.
In questo sistema si utilizza la formula di Erlang che ci consente di calcolare la probabilità di blocco del sistema
𝜆
𝑃𝐵 (𝑚, 𝑎) (Probabilità di perdita di job) in funzione del numero di serventi m e dell’intensità di traffico 𝑎 =
𝜇

Tale probabilità 𝑃𝐵 (𝑚, 𝑎) coincide con la probabilità 𝑝𝑘 (di trovarsi nello stato di blocco K) di un sistema M/M/m/K.
Quindi Erlang con tale formula non ha fatto altro che trovare la probabilità di blocco del sistema.
Vediamo un poco di esercizi che possiamo fare su questa parte. Alcuni di questi li trovo anche svolti su docenti unina.
Ha caricato tutto su teams anche. Nel blocco di esercitazione ci stanno una paio di esercizi per argomento e nelle slide
ci sono altri esercizi che dobbiamo farci da soli.

LEZIONE 23 19/11/21
N-modular Redundancy (Slide 36 Lec_IE_DEP2_RELTEC_NEW)
Nei sistemi ad N-modular redundancy ho più sistemi in parallelo e si usano nel contesto di aumento della reliability,
tale tecnica è di tipo di ridondanza spaziale. Per aumentare la reliability io devo aumentare la probabilità che un
sistema non fallisca in un intervallo 0, t.
Ricordiamo che nel caso della duplicazione si ha una fault-detection ma non una fault-masking. Un sistema in parallelo
non ha la capacità di tollerare (mascherare) un guasto quindi introduco un voter, un elemento che raccoglie gli output
da queste repliche e secondo una logica fornisce uno stato.
La maggior parte dei voter sono implementati a livello hardware e realizzano una politica di voting a maggioranza.

Lo schema più semplice è il TMR che sta per Triple Modular Redundancy. Vota con un meccanismo 2OutOf3 se due
danno la stessa risposta allora è quello l’output. Tale sistema tollera il guasto in un sistema, quindi il voter è in grado
di rilevare l’errore e al contempo tollerarlo, inviando all’uscita la risposta esatta. La risposta esatta è quella
“esatta”? Sì, solo nel caso di fallimenti di modo comune (quando sia 1 e 2 falliscono nello stesso modo e quindi
danno risposta sbagliata).
Questo non vale in tutti i contesti, difatti in alcuni sistemi safety critical come l’aereo se viene rilevato durante la
diagnostica che due componenti su tre danno lo stesso output il voter NON maschera il fallimento del terzo
componente. Si utilizza dunque un sistema “tree out of tree”
Calcoliamo la reliability del sistema nella successiva figura, esso non è un sistema in parallelo (i quali hanno che la
condizioni di fallimento consiste nel fatti che tutti debbano fallire), in questo caso abbiamo che almeno due sistemi su
tre devono fallire.
Se voglio esplicitare l’espressione della reliability, per un sistema di questo genere, ho che:

• 𝑅𝑇𝑀𝑅 è la probabilità che il sistema nell’intervallo 0-t non fallisca. Questo vuol dire che o tutti e tre
funzionano o che funzionano almeno 2.
• 𝑅𝑚 è la reliability del singolo componente per cui:
3
o 𝑅𝑚 indica il caso in cui tutte e tre le componenti stiano lavorando
o Il resto dell’equazione indica che solo 2 su 3 lavorino.

Quindi ho 𝑅𝑚3
(tutte e tre funzionano) più il coefficiente binomiale (32) di cui due funzionano 𝑅𝑚
2
per quello che non
funziona. CLASSICA DOMANDA DA ESAME: posso esprimere questo comportamento con un RBD? Pensateci e
rispondete (il prof non l’ha detto), ma poi scusat io già sbobino almeno mettete qualcosa voi o no? Cioè bho. Cmq si, si
devono esplicitare tutti i success path.
Devo esplicitare tutti i success path che sono in serie con il voter e quindi esce un prodottone.
IL VOTER DEVE ESSERE MOLTO PIU’ AFFIDABILE, DI ALMENO UN ORDINE DI GRANDEZZA SENNO IL TUTTO NON HA
SENSO. Questo è bello però quando mi dicono fallo diventa brutto.
Per un sistema generale M out of N vale quanto riportato nella slide.
Quindi lo faccio a livello hardware perché i sistemi hardware, per almeno altri 15/20 anni saranno molto più affidabili
dei software.
Tipicamente nei sistemi posso avere un effetto cascata del voter che è peggiore di quello in situazioni normali. Per
esempio, vediamo questo sistema a stage dove ogni componente è replicato e messo il voter in parallelo.

Potremmo pensare che sostituire un insieme di N componenti in serie con un insieme di N TMR renda il sistema finale
più reliable, FALSO: La reliability della serie dei TMR viene completamente degradata.
L’effetto finale è che anche se ho un voter di due ordini di grandezza superiore, il sistema in cascata neutralizza questo
effetto perché ho 𝑅𝑉 elevato al numero di stage e quindi (𝑅𝑉 )𝑛 < 𝑅𝑉 . Poiché R è un numero minore di 1 avremo che
questa reliability della cascata diminuisce sempre. In alcuni casi, non entro nel merito, si usa la replicazione dei voter e
si fa uno schema completamente replicato (nel MOSE è così).
Per ovviare all’enorme effetto collaterale dato dalla serie la soluzione è quella di utilizzare per ogni TMR 3 voter a cui
andranno in ingresso gli output di tutte e tre la componente. Lo svantaggio di tale soluzione sta nel costo poiché si
vanno a replicare ulteriormente le componenti.

Tutte le repliche hanno uscite che vanno in ingresso al voter e hanno un effetto parallelo. Non ho un effetto seriale.
Nei Boing l’ultimo voter sta a valle e in un posto sicuro e con un hardware sicuro e dove si fa tanta manutenzione con
reliability a quasi sette nove. Un errore di questo genere è capitato nel deragliamento del treno ad alta velocità
Barcellona-Madrid, il treno non ha captato la corretta velocità e il treno ha deragliato in curva.
Quando si posizionano questi sistemi si deve stare attenti a dove si mettono.

Da questi schemi vediamo i vantaggi:

1. Vantaggio 1: In questo modo non deve essere verificata la stringente ipotesi che la reliability dei voter
intermedi debba essere molto maggiore di quella dei componenti poiché dovrà essere verificata solo per il
voter finale.
2. Vantaggio 2: Non si ha l’effetto negativo della serie perché la reliability del sistema si ottiene considerando la
serie componente-voter come un modulo e poi applicando la formula della reliability di un TMR (Penso
𝑅𝑇𝑀𝑅𝑉 se considero anche il voter finale)
Questi tipi di sistemi, fino a dieci anni fa tipo, erano campo degli ingegneri elettronici, oggi sono compito anche degli
informatici perché anche un segnale oggi è una struttura dati e quindi c’è molto software.

LIMITI DI UN MODELLO SINGOLO

Cerchiamo di capire come configurare il modello e per fare ciò faccio una assunzione, una delle più semplici, i tempi al
fallimento di tipo esponenziale. Dove esprimo la 𝑅𝑠𝑖𝑚𝑝𝑙𝑒𝑥 (𝑡) = 𝑒 −𝜆𝑡 con un esponenziale. Simplex perché è lo schema
semplificato dove c’è un solo componente
Calcolo MTTF con l’integrale di 𝑅𝑠𝑖𝑚𝑝𝑙𝑒𝑥 e sostituisco a R nell’ 𝑅𝑇𝑀𝑅 che cosa ottengo? La seguente espressione e se
5
faccio l’integrale per MTTF del TMR ho , otteniamo quindi che la MTTF di un simplex è maggiore del sistema
6𝜆
𝑀𝑇𝑇𝐹𝑇𝑀𝑅 quindi ridondato! Questa cosa già l’avevo vista, ovvero che la ridondanza porta alla diminuzione
dell’MMTF.

Dimostrazione del valore della slide.

Allora, come lo configuriamo il sistema? Per farlo dobbiamo capire quale è la curva di reliability del simplex? E quale
quella del TMR? Il vantaggio che ho non è su MTTF, il vantaggio che ho è soprattutto in questa parte qua (inizio della
curva dove ho i due rettangolini). Ho ad esempio una reliability di 0.8, il mission time TMR è 2212 mentre il simplex è
1133, quindi a parità di reliability ho un mission time maggiore.
Il vero senso di questa figura è che se fisso un mission time, ad esempio su dov’è indicata la pallina rossa(𝑀𝑇𝑅𝑀 )
vediamo che la reliability, dato un mission time del TMR, è molto maggiore del simplex questo per un mission time
minore di un certo punto, una specie di break point 𝑡0 .
CI SARA’ un esercizio su questa roba.
0.7
C’è un punto dove la reliability del simplex diventa maggiore del TMR 𝑡0 = . In sistemi critici, come un elicottero,
𝜆
dove il mission time non è specificato o ha grosse tolleranze si possono accettare stalli anche di 48 ore, invece che solo
2/3 ore di esecuzione.
Per mantenere la reliability ad un certo livello si effettua un reset, quando si è in sistemi molto critici si fa in modo di
avere una seconda linea per poter effettuare la manutenzione sulla prima del TMR.
Vediamo brevemente un'altra problematica che è l’effetto della coverage (copertura dei guasti).

Effect of Coverage
Fino ad ora ho fatto l’assunzione che il nostro sistema sia in grado di rilevare il 100% dei guasti. Però non è sempre
così e l’effetto di una detection reale avrà un effetto deteriorativo sulla reliability e si modella con un parametro 𝑐𝑖 <
1 che può portare anche ad un deterioramento della coverage.

Il software con try-catch contengo l’errore, in hardware ho altri sistemi per fare error detection.
Come stimare la coverage? La stima della coverage non è un operazione semplice poiché è necessario considerare i
requisiti non funzionali o i cosiddetti requisiti negativi del sistema.
Mostriamo adesso una tabella che ci permette di capire per un determinato valore di reliability come viene modificato
dall’effetto della coverage:

Esempio: Se la reliability del sottosistema è 0.9, con un fattore di coverage di due nine e una replicazione di due,
otteniamo una reliability di 0.989; con una reliability del 0.7 abbiamo 0.908, con 0.5 0.748.
Prima di passare agli esercizi vediamo un modello duale di RBD. Ossia i fault tree.

Fault Trees
Perché si usano i fault tree? Perché se gli RBD descrivono come funziona un sistema in altri sono interessato a capire
perché fallisce. Sempre rappresentazione grafica di un sistema che lega tra loro i fallimenti dei singoli componenti con
i fallimenti di più alto livello per capire le modalità di fallimento di un sistema. Con RBD ho i success path qua devo
capire la catena al fallimento di un sistema e sono importanti quando faremo la FMEA (Failure Mode and Effect
Analisys)
Di sotto l’immagine racchiude i concetti base dei Fault trees.

Vediamo un esempio semplice.

In un RBD A in serie con B descriviamo info sul funzionamento del sistema e mi informa che deve funzionare A e B.
Che cosa mi dà un fault tree? Voglio capire quando non funziona, allora il sistema non funziona quando o non funziona
A o non funziona B, dunque, A e B sono in OR.
Quale uso? Quando sono interessato ai fallimenti uso fault tree sennò suo RBD. Dipende anche dall’azienda dove
vado.
Ci sono tool di fault tree che costano un sacco di soldi, sono pure tool dove nell’operatore posso mettere codice.
Quale è l’idea dei fault tree? Di capire sostanzialmente, un cut set ovvero gli elementi di basso livello che se
falliscono insieme portano al fallimento del sistema. Si utilizzano anche estensioni di fault tree che includono una
varietà di porte not/xor etc differenti che permettono di creare sequenze complesse.

Fault trees analysis

Mentre negli RBD si dovevano individuare tutti i success path per calcolare la reliability, nei fault tree è necessario
trovare tutte le combinazioni di guasti elementari, che prendono il nome di “cutset”, che possono portare al
fallimento del sistema . Tra queste combinazioni quella più importante è definita come minimal cut set ovvero la
minima combinazione di guasti che può portare al fallimento del sistema.

Ad esempio, se un auto se si rompe una candela la macchina si ferma? No, non è un cut set. Se non c’è olio? Si.
I minimal cut set sono le minime condizioni per cui fallisce il sistema.
Detto questo passiamo a sistemi più seri. Uso i fault tree per i fallimenti dell’aereo, e i piloti conoscono i minimal
cutset.
Riepilogando costruiamo un fault tree che ha un basic event che sono i fallimenti più elementari , poi ho un
intermediate che porta al fallimento di una componente e infine se risale tutto l’albero ho un top level event che fa
fallire tutto.
NOTA Del redattore: A risk assessment si fa questo nella parte finale del corso, infatti è spiegato molto bene come
funziona la fault tree analysis. Se avete bisogno ci sono gli appunti su teams.
Riepilogando, costruiamo un fault tree con un top level event (TLE) (fallimento del sistema) e basic event (foglie
dell’albero) (fallimento dei componenti) con la catena dei fallimenti.

Quello che noi cerchiamo è il minimal cut set, ovvero il cut set di cardinalità minimo che porta al fallimento di sistema.
Se le porte utilizzate per relazionare gli eventi sono di tipo logico (come nell’esempio), i minimal cut set non sono altro
che le forme canoniche di 1° tipo o 2° tipo (prodotto di somme o somme di prodotti). Da questo si può ricavare che
due fault ree sono equivalenti se sono equivalenti le loro forme logiche.
Come si sviluppano i fault tree? Gli operatori logici so semplici, si fanno le operazioni di minimizzazione come le reti
logiche
Il problema entra in due casi, quando ci sono eventi ripetuti ed è come le serie in parallelo (nel senso di cammini)

Qui superiamo il problema usando la regola di Bayes.

Esercizi che ci assegna e li mette pure sul sito (risentitelo che non scriverò tutto perché appunto è da sentire).
In questo primo esercizio non si vede subito una serie o un parallelo e vuole che troviamo R(t) e la MMTF

Ci dà l’MMTF e dobbiamo comparare i due sistemi e poi quale componente ha maggiore reliability. (Il file si chiama
Homework_rbd) Fisso R del sistema e vedo come varia la reliability di 1 e 2 al variare di R, ho due curve al variare di R
che mi dice quanto deve valere la reliability. SPESSO ALL’ESAME non vediamo come varia rispetto al mission time. È
vero che è importante come varia la reliability del componente, ma fissata al reliability del componente devo dire
come varia al variare del mission time o se non c’è nessun mission time in cui uno è migliore dell’altra.
Altro esercizio è il 3 e sono le skip-ring network, ad esempio le reti bancarie che hanno delle specifiche di affidabilità.
Ogni nodo ha un link riletto con il successivo e così via, la rete funziona se in un certo stato, anche con nodi falliti, ogni
nodo è in grado di comunicare con il successivo per poter sincronizzare. La rete fallisce se un modulo non comunica
con il successivo. Se fallisce due la rete è fallita? Per vedere se è fallita devo vedere se ogni nodo può comunicare con
il successivo?
RETE NON FUNZIONA SE UN NODO NON PUO COMUNICARE CON IL SUCCESSIVO IN CONDIZIONI DI FUNZIONAMENTO
DELLA RETE. CASO PARTICOLARE DUE NODI SUCCESSIVI NON FUNZIONANO QUINDI FALLISCE.
Enumerate tutte le possibilità di funzionamento, va bene ma dobbiamo provarlo a fare in maniera analitica e se
possiamo farne un modello.
Funziona se funziona questa condizione.
Se 3 e 5 non funzionano, ogni nodo riesce a comunicare con il successivo?
Esercizio 4

Se ci dà mttf di 3 componenti A, B, C e devo poi confrontare la reliability di 4 schemi differenti. Questo perché in alcuni
casi, si usa l’equivalenza in alcuni casi industriali. Si tende a semplificare con schemi equivalenti. Comparo gli mttf e
faccio delle relazioni di equivalenza.

L’esercizio 4 (in realtà 5) è il sistema di un elicottero e ce lo porta per farci capire un caso pratico.
Il sistema ha due processori ridondanti e due interfacce ridondanti.
Con INS (inertial navigation system) costruisco la posizione degli aerei in maniera inerziale. Questi sistemi costano
assai. Spesso anche i militari non possono permettersi redundancy di questa cosa, quindi che fanno? Usano un sistema
più economico che è AHRS che funziona con Doppler. Questo è un esempio di ridondanza funzionale nel caso INS
fallisce.
Ha bisogno sempre di istanza di bus A e bus B per funzionare. Che devo fare? Devo disegnare RBD, il fault tree e i
minimal cutset. Infine, calcolo la reliability per un’ora di volo usando gli MTTF che mi vengono forniti.
Posso ripetere poi il calcolo C per ottenere la fault coverage. Che problemi ha questo esercizio? Nessuno solo che è
molto più realistico.
Se avete difficoltà con un qualche esercizio, ricevimento e via.
Da ora iniziano lezioni sulla parte di safety e poi andiamo verso la parte del cloud. Per ora abbiamo coperto il 70% del
corso, il restante 30% prossime lezioni. Ci vediamo con lui l’altro venerdì.

Lista degli homework:

1. Benchmark
2. Pca e clustering (fatto anche in aula)
3. Esercitazione di pietro workload charact di alto e basso livello per la validazione
4. DoE
5. Questi esercizi di oggi
6. MANCA UN’ALTRA Che vediamo in questi gg. FTTA?

LEZIONE 24 22/11/2021
Introduction to queueing theory (03-queuing_theory_p2_2021)
Su Teams il prof ha caricato delle slide e delle prove di esame sulle quali possiamo esercitarci
La scorsa volta abbiamo visto i primi modelli a coda e abbiamo visto i modelli Markoviani, quelli classificati per
M/M/m; abbiamo visto il più semplice: M/M/1 e abbiamo fatto l’ipotesi che il processo di arrivo fosse poissoniano
ovvero, è un processo stocastico che simula il manifestarsi di eventi che siano indipendenti l'uno dall'altro e che
accadano continuamente nel tempo. Quindi non dipende dallo stato del sistema ma il tasso medio è costante per ogni
istante.
Abbiamo anche visto che il tasso di arrivo di un job è distribuito come un esponenziale e avevamo assunto una
memoria idealmente illimitata. Abbiamo visto cosa succede se in quei modelli non posso fare quest’assunzione e
arrivo a modelli con capacità finita; altra cosa più importante abbiamo detto che per capire quando avviene un blocco,
dobbiamo studiare il sistema negli istanti di arrivo di un job. Il blocco si verifica quando il mio sistema è pieno e mi
arriva un job.
Ci viene in contro la proprietà PASTA dei processi poissoniani che ci dice: “quando un processo in arrivo è poissoniano
sostanzialmente quello che succede negli istanti di arrivo è lo stesso del regime”.
Oggi vediamo altre due macro-tipologie dei modelli a coda dove rilassiamo alcune assunzioni:

• Un primo modello che vediamo è il modello a popolazione finita, già solo il nome mi fa capire che non posso
considerare un processo di arrivo di Poisson. Quando i mei job arrivano da una sorgente finita di possibili
utenti abbiamo che la loro distribuzione dei tempi di arrivo dipende dal numero stesso degli utenti.
• Poi nella seconda parte rimuoveremo il tempo di servizio esponenziale e vedremo un caso in cui avremo un
M/G/1 (G = Tempo di servizio generici), quindi qualunque sia la distribuzione dei tempi di servizio purché io
conosca la sua media e varianza posso sfruttare queste informazioni per ottenere lo stesso modelli di
performance

Sistemi a popolazione finita (M/M/m/k/p)

In questo modello si ha una popolazione finita di 𝑵 utenti, ognuno dei quali può:

• Sottomettere un job al sistema con tasso 𝜆 (sempre esponenziale)

 • Una volta che un utente ha sottometto un job, esso rimane in attesa della risposta e in tale attesa non
sottomette ulteriori job.

Modello simile a quello visto l’ultima volta ma abbiamo aggiunto a questa coda una sorgente finita di job. Cosa
modelliamo?
Abbiamo uno o più serventi, una politica di scheduling ed un tempo di servizio che stiamo ancora supponendo
1
esponenziale. Ogni utente dopo un certo thinking time effettua una richiesta con il tasso 𝜆 e quindi ogni 𝑠𝑒𝑐𝑜𝑛𝑑𝑖
𝜆
ed aspetta una risposta, il fatto di aspettare significa che non può effettuare altre richieste e questo fatto limita il
numero di possibili richieste al secondo che arrivano al sistema. Se tutti gli utenti hanno sottoposto un job al sistema
il tempo di attesa si annulla.
Se ho una coda a capacità finita e la dimensione è minore della popolazione può esserci un blocco. Vediamo come
possiamo modellare un comportamento del singolo utente.
Abbiamo ancora dei tempo di arrivi markoviani e quindi ogni singolo utente può essere visto come una catena di
markov in cui abbiamo due stati:
• Thinking time, in cui non ha ancora effettuato una richiesta
• Service state, in cui aspetta una risposta.

Quando ottiene una risposta il servente risponde con un tasso 𝜇

Questo processo è sempre di nascita-morte, ma solo più complicato perché è generico e abbiamo rilassato delle
assunzioni, la capacità K può essere finita/infinita.
Quando parliamo di popolazione finita non ha molto senso considerare il sistema come con capacità infinita, poiché
potranno entrare al più N utenti, la coda si riempirà al più di N. Il sistema non sarà mai in uno stato N+1, per questo
motivo i sistemi a popolazione finita sono stabili e hanno un numero finito di stati.
La capacità la specifico quando è minore della popolazione, e quindi ci può essere un blocco, altrimenti la considero
uguale alla popolazione o dico che non è influente.
Il processo degli arrivi è particolare, non è più un processo di Poisson; infatti, negli stati il processo degli arrivi
cambia. Nello stato “0” i job possono arrivare da tutti gli N utenti, il tasso di arrivo complessivo è 𝑁𝜆; nello stato “1” il
tasso di arrivo complessivo è (𝑁 − 1)𝜆 e così via.
Questo fatto mi abolisce l’assunzione che siano di Poisson poiché il tasso medio di arrivo cambia in base al numero di
utenti però è sempre un processo Markoviano.
Quindi per il tasso di servizio (il comportamento è quello classico) se il sistema ha capacità K allora:
• Se stiamo nello stato “1” allora il tasso di servizio è 𝜇 (un job è nel sistema e viene servito da 1 servente)
• Se stiamo nello stato “2” allora il tasso di servizio è 2𝜇
• E così via fino allo stato 𝑚 con poi 𝑚𝜇 poiché ricordiamo che a partire da quest’ultimo tutti i serventi saranno
occupati e quindi il tasso di servizio rimane costante.
La proprietà PASTA non è più valida e quindi la probabilità di trovare N utenti nel sistema nel momento di un arrivo
non è la probabilità di trovare N utenti nel sistema in un momento qualsiasi.

Proprietà Osservatore esterno

Come posso fare per studiare il sistema in questo caso? Uso la proprietà dell’osservatore esterno, che vale solo per i
sistemi a popolazione finita:
𝑝𝑗𝑁 = 𝑃{il sistema è nello stato j, di un sistema con N utenti, ad un istante di tempo qualsiasi a regime}

𝑝𝑁∗𝑗 = 𝑃{il sistema, con N utenti, è nello stato j in un momento di arrivo di un job}

Questa proprietà ci dice che la probabilità di stare nello stato j in un sistema con N utenti nel momento dell’arrivo è
pari alla probabilità di stare nello stato j in un sistema con 𝑁 − 1 utenti in un momento qualsiasi.
Questo significa che posso studiare in qualche modo la catena di Markov come processo di nascita-morte però, come
se fosse con 𝑁 − 1 utenti totali. I risultati che ottengo sono la distribuzione di probabilità che accade nel mio sistema
con N utenti, è come se l’utente fosse un utente esterno che vede il sistema da fuori.
Vediamo quindi dei casi interessanti per i modelli single server con un gruppo di N clienti:

• M/M/1/N/N

Quando abbiamo un numero di utenti pari alla capacità significa che non può esserci blocco, questo potrebbe
essere un buon web server.

• M/M/m/m/N con (N > m)

In questo caso è un sistema con blocco, abbiamo quindi un numero di utenti maggiore della capacità.
L’esempio può essere un concentratore di linee telefoniche.
Vediamo l’esempio di un sistema M/M/1/N/N (senza blocchi) singolo server http.

Possiamo considerarlo come un gruppo di N client, ognuno dei quali con un thinking time pari a 15 secondi distribuiti
esponenzialmente con richiesta al sistema che viene accodata. Supponiamo un singolo server con un tasso di servizio
pari ad 1 secondo.
Il modello è un M/M/1/N/N, come varia il tempo di risposta in base al numero di utenti N?

Per quello detto lo modello come un processo nascita-morte con tasso di completamento costante, se vado a fare i
calcoli usando sempre lo stesso metodo: spezzo la catena in ogni punto e per ogni coppia di stati mi calcolo
l’equazione di bilanciamento totale, ottengo:
𝑁!
𝑝𝑛 = 𝑝𝑛 ∗ 𝑝0
(𝑁 − 𝑛)!
La probabilità che il sistema sia in idle, la vado a trovare imponendo che la somma di tutte le probabilità di ciascuno
stato sia 1 a regime:
𝑁 −1
𝑁!
𝑝0 = (∑ 𝑝𝑛 )
(𝑁 − 𝑛)!
𝑛=0

Ovviamente le formule possono essere utili quando vogliamo studiarlo parametricamente, nel momento in cui però
usiamo gli esercizi p è dato e conviene trovare la distribuzione a mano.
• Il throughput medio del sistema è pari a:

𝐸[𝑅] = 𝜇(1 − 𝑝0 )
Abbiamo detto che il sistema ha 1 solo servente con throughput medio pari a 𝜇 ma quando il sistema è attivo. Quindi
se 𝑝0 è la probabilità che il servente sia in idle, allora 1 − 𝑝0 è la probabilità che il servente sia attivo e quindi il
throughput medio è quanto riportato sopra.

• In media un client fa richiesta ogni: tempo di risposta + thinking time

1
𝐸[𝑇] +
𝜆
Quindi il numero di richieste complessivo tra tutti i client di sistema è questo tasso per N utenti:
𝑁
1
𝐸[𝑇] +
𝜆
• A regime, siccome non ho un blocco, il tasso di richieste che entra è mediamente pari al tasso di
𝑁
richieste che esce. Allora 1 = 𝜇(1 − 𝑝0 ) e questa informazione mi permette di ricavare il tempo
𝐸[𝑇]+
𝜆
𝑁 1
medio di risosta 𝐸[𝑇] = −
𝐸[𝑅] 𝜆
Altra formula che è un coltellino svizzero:

Questa relazione ci può essere utile per quando lavoriamo sul capacity test del web server e vogliamo trovare la
knee capacity; infatti, dall’immagine ho una legge del throughput medio e quando ho una popolazione piccola (1
solo utente) non aspetterà e quindi il tempo di completamento dipende dalla velocità del servente.

Questa condizione di basso carico mi permette di tracciare una linea sul grafico (la verde), viceversa quando sto in
condizione di alto carico (linea rossa) ho basse probabilità che il sistema sia scarico e quindi il tempo medio di risposta
𝑁 1
è 𝐸[𝑇] = − .
𝜇 𝜆

L’intersezione delle due rette è un numero che può essere un parametro ottimale per il funzionamento del sistema ed
è il N* saturation number e vale come riportato nella slide.
Osservazione: N* dipende proprio dal carico del sistema (dipenda da 𝜌, che ricordiamo è il rapporto tra tasso di arrivo
e tasso di servizio).
Vediamo ora all’esempio dell’altro modello sistema M/M/s/s/n (con blocchi): concentratore di linee telefoniche.
In questo modello la capacità è inferiore al numero della popolazione, ho 𝑛 telefoni attaccati e un sott’insieme di
linee fisiche. Se le linee sono tutte occupate il cliente non può chiamare e deve aspettare. Tale sistema può essere
modellato come un M/M/s/s/n.
Quindi qual è la probabilità che una chiamata in arrivo venga bloccata trovando tutte le 𝑠 occupate?
Modelliamo sempre in base al processo di nascita-morte, la parte di nascita è identica a quello di prima solo che qui
lo stato arriva fino ad s. Il processo di morte, invece, cambia in base a numero di linee attive e quindi il tasso di
chiamate completate, se sto in una linea attiva è 𝜇, per due linee è 2𝜇 e così via.
Anche qui, se applico lo stesso procedimento ottengo la stessa distribuzione di probabilità di ogni stato in funzione di
𝑝0 e poi applico la condizione di normalizzazione come riportato in figura

Abbiamo detto che siccome non vale la proprietà PASTA, perché il processo degli arrivi non è di Poisson, non vale più
l’uguaglianza:
𝑃𝐵 = 𝑝𝑠∗ 𝑝𝑟𝑜𝑏𝑎𝑏𝑖𝑙𝑖𝑡à 𝑑𝑖 𝑠𝑡𝑎𝑡𝑜 𝑠 (𝑑𝑢𝑟𝑎𝑛𝑡𝑒 𝑢𝑛 𝑎𝑟𝑟𝑖𝑣𝑜)
Mi riscrivo quindi il modello applicando la proprietà dell’osservatore esterno dove al posto di n uso n-1 e risolvo
quello. La probabilità di blocco è riportata sotto.

Esercizio, tratto da un esame di qualche anno fa

Partiamo dal blocco M/D/1/2/2, per quello detto fin ora non può essere modellato come catena di Markov ma
tuttavia sappiamo che:
• Ha capacità di 2 posti
• Il numero di utenti del sistema è 2
• La probabilità di blocco è nulla.

Se vediamo il primo blocco M/M/1/2, con un posto in coda e un posto nel servente. Il tasso di arrivo pari a 4𝜆 con
popolazione infinta ed è quindi di Poisson. Un singolo servente quindi un tasso di morte pari a 𝜇. Ha un modellino di
questo tipo qui:

Il blocco si ha quando, all’arrivo di un utente, il sistema si trova nello stato due. Poiché il processo è di Poisson posso
applicare la proprietà PASTA e quindi la proprietà dell’arrivo è uguale alla probabilità che il sistema si trovi nello stato
2 a regime.
𝑃𝐵𝐿𝑂𝐶𝐾 = 𝑝2∗ = 𝑝2
Come risolvo l’esercizio? Mi devo trovare p2, mi scrivo l’equazione di bilanciamento totale e taglio volta per volta più
la condizione di normalizzazione. Sistema di 3 equazioni in 3 incognite.
Vediamo ora quando siamo in un modello a propagazione finita, sempre con tre stati ma cambia il tasso di arrivo. Il
blocco era quello segnato come M/M/1/2/4.
Adesso non abbiamo il processo di Poisson e quindi non è vero che la probabilità di blocco sia quella di trovarmi nello
stato due, applico la proprietà dell’osservatore esterno.

Il modello segnato in rosso è valido solo negli istanti di arrivo, ed è rappresentato con un utente in meno. Risolvo
adesso questo nuovo sistema esattamente come fatto prima:

Generic Distribution Service Time (M/G/1)

Rimoviamo l’assunzione di tempo di servizio Markoviani e che abbiamo una distribuzione generica dei tempi. Il tipo
di modello è M/G/1, cosa possiamo dire? Assumiamo che il processo degli arrivi sia ancora di Poisson mentre il
numero degli utenti nel sistema non è più un processo di Markov e quindi non posso modellarlo come nascita-morte.
Ricordiamo che a TC l’unica distribuzione che soddisfa la proprietà di Markov, cioè essere senza memoria, è
l’esponenziale.
Il fatto che ho un processo con memoria cosa mi comporta? Che la probabilità di passare da uno stato N ad N-1 non
dipende solo dallo stato corrente, ma anche da quanto tempo l’utente in servizio ha già trascorso nel sistema. Per fare
questo voglio andare a studiare qual è il tempo di attesa 𝑬[𝑾] tenendo conto del tempo rimanente.
Per quello che abbiamo detto il tempo di attesa lo scrivo come: numero degli utenti in attesa + attesa che il job nel
servente termini la propria esecuzione + tempo di attesa medio
Poiché i processi in arrivo sono Poissoniani la distribuzione vista dall’utente in arrivo può essere valutata con la legge
di Little. Se si applica la Legge di little al solo sottosistema della coda si ha che il numero medio di job in coda è pari al
tasso di arrivo moltiplicato il tempo medio di attesa:

𝐸[𝑁𝑞 ] = 𝜆𝐸[𝑊]

𝜆𝐸[𝑆] è quello che chiamavamo 𝜇 nei sistemi Markoviani.

Otteniamo quest’espressione che lega: quanto tempo devo aspettare con il tempo rimanente del servente all’arrivo.
Per molti anni la teoria delle code si è fermata a questa formula, andando spesso a sfruttare la simulazione. Si è poi
passato ad una decina di anni fa alla formula PK per calcolare il tempo medio rimanente 𝐸[𝑅]

Pollaczek-Khinchin formula (PK)

Abbiamo il tempo da un lato e dall’altro il tempo rimanente, ottengo l’andamento con questi triangoli isosceli nella
figura successiva. Che cosa rappresentano? Quando arriva un job ho che il tempo rimanente è pari proprio al tempo di
servizio del job 𝑆0 , man mano che va in esecuzione nel servente il tempo diminuisce linearmente e passa proprio un
tempo 𝑆1 .
Nei triangoli isosceli l’altezza è uguale alla base, quello che hanno calcolato Pollaczek-Khinchin è che la media
dell’aria di questi triangoli è pari alla media del tempo rimanente per ogni job. Andiamo a calcolarla come nella slide,
facciamo la media di ½ base per altezza.

Quindi se seguiamo l’immagine avremo:

1. Supponiamo che arrivi un job J1 all’istante di tempo T1: in tale istante, il tempo rimanente R(t) coincide
proprio con il tempo di servizio 𝑆1 del job. (Sono uguali perché è appena arrivato. Da un punto di vista grafico
l’uguaglianza ci permette di ottenere che Il lato del triangolo lungo la y (R(t)) è uguale al lato lungo la x (S(t))
del triangolo).
2. Arriva un job J2 J1 all’istante di tempo T2 con un suo tempo di servizio 𝑆2 e un suo tempo rimanente.
3. Il sistema va in idle (dopo T3)
4. Arriva un nuovo job J, e così via…
Se nell’intervallo (0,t) si hanno 𝑛 arrivi si ha che la media del tempo rimanente è la media temporale delle aree dei
1
triangoli e quindi ( ∗ 𝑆𝑖2 è l’area del triangolo rettangolo):
2
𝑛
1 1
𝐸[𝑅] = ∑ 𝑆𝑖2
𝑡 2
𝑖=1

Moltiplicando e dividendo per 𝑛 otteniamo:

𝑛
𝑛 1 1
𝐸[𝑅] = ∗ ∑ 𝑆𝑖2
𝑡 𝑛 2
𝑖=1

Dove:
𝑛
• = 𝜆 è proprio il numero degli arrivi nell’unita di tempo, quindi proprio il tasso degli arrivo 𝜆 (Ricorda che è
𝑡
di poisson)
𝑛
1 1
• ∑ 𝑆𝑖2 è la media dei quadrati dei tempi di servizio.
𝑛 𝑖=1 2

𝜆
La formula converge quindi a 𝐸[𝑅] = 𝐸[𝑠 2 ] e la posso sostituire nella formula del tempo di attesa visto prima.
2
Indicatori di performance di M/G/1

Vediamo un esempio di questo tipo: Abbiamo un MUX per una linea di tipo ATM, che cos’è ATM? È un protocollo di
rete di livello di dati che implementa un modo di trasferimento a commutazione di circuito virtuale e trasmissione di
cella, incapsulando i dati in unità, dette celle, di lunghezza fissa (53 byte) anziché in pacchetti a lunghezza variabile
come avviene invece nelle reti a commutazione di pacchetto (ad esempio con IPv4).

Voglio sapere il numero medie di celle nel mux, perché voglio dimensionare la memoria del dispositivo, e voglio
studiare il tempo di risposta di una cella.
Lo posso modellare come un sistema M/D/1 perché il tempo di servizio è costante. Il tasso di utilizzo è quello di
utilizzo di uscita
Quindi la mia memoria deve essere di almeno 3 celle.

Se avessimo modellato, non con un tempo di servizio deterministico, ma come con un sistema M/M/1 avremmo avuto
un numero di celle pari a 4 e il tempo di servizio pari a 13.5.
La situazione sarebbe stata un po’ più sfavorevole, solitamente si fa anche M/M/1 perché è più semplice studiare e ci
dà un upper bound dei nostri valori.
Esercizio, in questo caso si trova svolto nel blocco che ha caricato nel corso e parla di un ufficio.

Il tempo di una copia è deterministico, però il numero di copie varia tra 1 e 10 in maniera uniforme anche il tempo
dell’impiegato è uniforme.
LEZIONE 25 25/11/2021
Queueing Networks (reti di code) (04-queuing_networks_2021)
Sostanzialmente tutti i modelli visti finora: M/M/1, M/M/2, M/M/capacità finite, etc. sono dei modelli a singola coda,
quello che vedremo oggi è come modellare situazioni più complesse dove abbiamo più di una coda e con connessione
di più modelli.
Le tipologie di rete dipendono da come connettiamo i vari blocchi, possiamo avere le cosiddette aperte dove ho che i
JOB vengono dall’esterno e una volta elaborate escono; l’opposto è la chiusa dove il numero di JOB è costante e
vengono costantemente processate.
Di queste due macro-tipologie vedremo quelle che possono essere espresse come in forma prodotto e tra queste ci
sono le reti di Jackson e di Gordon-Newell.
Ma che cosa sono le reti di code? Abbiamo detto un’interconnessione di diversi code, magari in un pc quella che
rappresenta l’unione tra le code di gestione CPU e contemporaneamente di disco.

Da notare sia la retroazione che la biforcazione, questo perché le connessioni sono definite dalle probabilità.
Il sistema è caratterizzato da:
• Un numero di utenti, lo stato del sistema è sempre rappresentato dal numero di utenti nel sistema soltanto
che qui dobbiamo vedere anche dove si trovano
• Processo degli arrivi dei JOB
• Processo di servizio per ogni servente
• Classi di utenti o JOB differenti, es CPU bounded, I/O bounded.

Reti aperte
Le reti aperte sono caratterizzate da una popolazione non costante e da un flusso di JOB in ingresso e in uscita.
Esempio: con probabilità p1 entrerà nella stazione 1, con probabilità p2 entrerà nella stazione 2, etc. Inoltre, una volta
completata l’elaborazione dei job nelle stazioni, esse convoglieranno nella stazione 4. Infine, i job escono

Reti chiuse
Le reti chiuse non hanno sorgenti esterne di job quindi la popolazione è costante, questo vuol dire che non vi sono
nodi di input o output nella rete.

Esempio: le stazioni possono rappresentare dei terminali/postazioni di un ufficio che sottomettono job continuamente
alla stazione 4. In seguito, tale stazione produrrà delle risposte che andranno nuovamente in input agli utenti.

Topologia di rete
La topologia descrive il modo in cui interconnetto le stazioni, può essere stocastica e quindi su ogni interconnessione
definisco la probabilità p, la probabilità 1-p rappresenta la probabilità che esco dalla stazione e prendo un altro
percorso.

Per questo motivo posso definire la topologia come una matrice 𝑸 = [𝒒𝒊𝒋 ] dove ogni elemento rappresenta la
probabilità che un utente servito dal server i si sposti verso il server j.

Two node tandem – rete aperta

La rete più semplice che possiamo immaginare è il two-node tandem, in questo caso di tipo M/M/1 e a rete aperta.
I tempi di servizio saranno indipendenti ed esponenzialmente distribuiti, il processo in arrivo dall’esterno è un
processo di Poisson con un tasso medio 𝜆. Lo stato del sistema è rappresentato dalla coppia 𝑁 = {𝑁1 , 𝑁2 } dove il
primo è il numero di utenti nella prima coda e il secondo nella seconda coda.
Può essere descritta come una catena di Markov con 𝑁1 + 𝑁2 stati, ed è poco agevole, lo vediamo dalla slide.
In totale il sistema avrà ∞ ∗ ∞ stati; quindi, modellare la rete di code con catene di Markov è poco agevole (Anche
perché non possiamo descriverli come un processo di nascita-morte)
Come procediamo ad effettuare l’analisi? Quello che ci viene in aiuto è il teorema di Burke

Teorema di Burke
Si nota che se l’output della prima coda è ancora un processo di Poisson allora posso analizzare il secondo
sottosistema come un normale M/M/1. Quando abbiamo quindi una serie di code M/M/1 o M/M/N abbiamo che
tutte le quantità in gioco sono sempre di Poisson; se questo è vero possiamo dire che il sistema si può trovare in un
particolare stato come la probabilità delle singole stazioni:
𝑃(𝑁 = {𝑛1 , 𝑛2 }) = 𝑃(𝑁1 = 𝑛1 )𝑃(𝑁2 = 𝑛2 )
Questo mi è utile perché riesco a separare lo studio delle singole code.

Ma quali sono le assunzioni in cui vale questo teorema? Devono essere tutte code di tipo M/M/N e non ci devono
essere retroazioni, ma ci possono essere biforcazioni, semplicemente deve andare sempre avanti e le politiche di
scheduling tutte di tipo FIFO.
Da quello visto l’altra volta la distribuzione di probabilità di una coda M/M/1 era: 𝜌𝑛 (1 − 𝜌) se vado a fare il prodotto
della rete attraverso il teorema di Burke ottengo:
𝑛 𝑛
𝑝(𝑛1 , 𝑛2 ) = 𝑝(𝑛1 )𝑝(𝑛2 ) = 𝜌1 1 (1 − 𝜌1 )𝜌2 2 (1 − 𝜌2 )
Nota: Attenzione che alcuni sono P e quindi probabilità e altri sono rho.
Altre considerazioni banali, il numero medio degli utenti 𝑬[𝑵] e il tempo di servizio 𝑬[𝑻] sono pari alla somma delle
due code.

Abbiamo fatto però un bel po’ di assunzioni per avere una rete in forma prodotto, ricapitoliamole:
• I processi in arrivo Poissoniani
• I tempi di servizio sono distribuiti in maniera esponenziali
• La politica di scheduling FIFO
• Non ci può essere blocco di code
• Solo reti aperte
• Nessun loop
• La topologia deve essere omogenea (quelle probabilità con le quali definiamo la topologia non varia nel
tempo o negli stati)

Reti di Jackson
In generale se la topologia include loop (retroazioni), i tassi di arrivo alle code non sono processi di Poisson
indipendenti (infatti, il carico sottoposto alla stazione 1 dipende anche dal carico sottoposto alla stazione 2).
Tuttavia, Jackson ha notato che, con dovute accortezze il risultato del Teorema di Burke (Forma prodotto) continua a
valere anche in presenza loop nella rete (retroazioni) su una classe più ampia di reti, chiamata Reti di Jackson.
Il ragionamento è simile a quello fatto con le reti di prima, ma si è aggiunto il concetto di loop. In particolare, una rete
di Jackson è una rete generica aperta in cui sott’intendiamo l’esistenza di un nodo da cui provengono tutti i JOB e lo
chiamiamo source node (s) ed un nodo destinazione sink (d).
Posso avere arrivi poissoniani dall’esterno, all’interno non lo saranno poiché i processi all’interno dipendono da come
evolvono gli stati. I tempi di servizio sono sempre esponenzialmente distribuiti all’interno delle singole stazioni e la
tipologia può essere stocastica.
Osservando la slide successiva possiamo osservare che, se analizzassimo solo la topologia, in questa rete non c’è
perdita di JOB e c’è la cosiddetta conservazione del flusso. Questa relazione così rappresentata vuol dire che il flusso
𝜆1 che entra nella prima stazione è data dalla stazione 𝑞2,1 , dalla 𝑞31 e dal nodo sorgente 𝜆1 ; ovviamente il flusso in
uscita 𝜆 è lo stesso in uscita perché non c’è perdita di JOB.
Ma formalizziamo meglio l’esempio, abbiamo il nodo 1 e valutiamo il tasso di arrivo 𝜆1 :
1. Dalla sorgente S il tasso medio di arrivo è pari a 𝜆
2. 𝑞𝑠1 = 1 perché dal nodo sorgente posso andare solo nel nodo 1. Otteniamo quindi la prima parte
dell’espressione nella slide 𝜆𝑞𝑠,𝑖
3. La sommatoria, in questo caso, include 𝜆2 e 𝜆3 che saranno moltiplicati rispettivamente: per le probabilità di
passare dalla stazione 2 alla 1 e per la probabilità di passare dalla stazione 3 alla 1. Avremo quindi 𝜆2 𝑞21 +
𝜆3 𝑞31
Il tasso uscente dalla rete (dunque di arrivo nel nodo destinazione), siccome i job non vengono persi (vi è una
“conservazione del flusso dei job”), dev’essere pari alla somma (per ogni nodo) dei tassi di ingresso 𝜆𝑗 per la
probabilità di andare dalla stazione 𝑗 al nodo di destinazione 𝑑. (Quanto del tasso di arrivo al nodo j va nel nodo
destinazione).

Una volta trovati tutti i flussi che entrano nelle singole stazioni quello che possiamo fare è studiare singolarmente le
singole code, e possiamo definire le probabilità dell’intera rete in forma prodotto.
È come se il teorema di Burke valesse con queste condizioni
Metriche di performance sulle reti di Jackson

Per il tempo medio di risposta dell’intera rete, sfruttando la legge di Little sappiamo che 𝐸[𝑁] = 𝜆𝐸[𝑇]. In particolare,
𝐸[𝑁] è il numero medio di utenti totale nel sistema.
Vediamo un esempio, abbiamo un sistema simile a quello visto prima con probabilità 1 − 𝑞 di finire il job in
esecuzione sulla CPU e con probabilità 𝑞 richiede l’utilizzo del disco. Dopo aver avuto i dati dal disco il job si riaccoda
all’interno della coda 1. Vogliamo trovare il tempo di risposta per un task che entra in questo sistema.

Si tratta quindi di una rete costituita da 2 nodi, con topologia stocastica, con presenza di loop (retroazione tra cpu e
i/o).Possiamo modellare quindi il sistema come una rete di Jackson.
1. Troviamo il tasso di arrivo in ogni sottosistema

In questo caso il tasso entrante nella prima stazione è la somma delle due componenti mentre il tasso
uscente da 𝜆2 è il tasso che viene dall’esterno.
 Una volta trovati i due tassi 𝜆 posso trovare i due fattori di utilizzo 𝜌. Una volta fatto questo devo verificare la
stabilità delle stazioni e quindi 𝜌 < 1.
Osservazione: Abbiamo detto che tale modello delle reti di Jackson funziona solo se non ci sono perdite di
job (tutto quello che entra è pari a quello che esce). A tal fine, le code dovrebbero avere capacità infinita.
Problema: le code potrebbero non ammette un regime (entrano sempre più job, con una crescita indefinita
della coda), quindi il modello di coda così ottenuto si dice instabile.
Come ce ne accorgiamo? Affinché la coda 𝑖 − 𝑒𝑠𝑖𝑚𝑎 M/M/1 sia stabile occorre che il fattore 𝜌𝑖 < 𝟏. In
generale, affinché l’intera rete sia stabile, c’è bisogno che tutti i 𝜌𝑖 < 1 (se pure uno dei 𝜌𝑖 ≥ 1, si otterrebbe
un punto della rete in cui entrano sempre più job ma che vengono completati in un tempo ∞, senza mai
uscire).
2. Una volta verificata la stabilità si studiano il numero medio di utenti nelle singole stazioni, così da
determinare il numero medio totale nel sistema

3. Usando la legge di Little troviamo il tempo medio di risposta

Reti chiuse
Nelle reti chiuse non abbiamo una sorgente ed una destinazione, abbiamo quindi K job costanti. Per questo motivo il
numero di stati è finito
Le code ammettono sempre un regime e sono sempre stabili, non abbiamo dei processi poissoniani e quindi non vale
la proprietà PASTA.
Come calcoliamo il numero di stati del sistema? Usiamo il coefficiente binomiale pari a quello in figura.

Anche qui possiamo descrivere il flusso entrante nelle singole stazioni, la formula è analoga a quella di prima solo che
qui l’insieme di equazioni che otteniamo non consentono di risolvere il sistema perché una sarà combinazione
lineare delle altre. Questo sistema ha quindi infinite soluzioni e non è possibile calcolare il tasso effettivo di ingresso
delle stazioni.

Di queste infinite soluzioni ne posso scegliere una, a meno di una costante. La costante dipende dal numero di utenti
totali nella rete.
Lambda cappello è chiamato flow ratio e mi dicono quant’è grande il flusso entrante in una certa stazione rispetto alle
altre, ma no rispetto al numero di utenti.
Vediamo un esempio, simile a quello precedente dove però modelliamo K processi in un computer embedded. Con
questa rappresentazione (retroazione della CPU) modelliamo il reskeduling delle task.
I tempi di servizio sono sempre distribuiti esponenzialmente, vediamo come si studia:

Devo trovare questi tassi mostrati in figura

Quindi in 𝜆2 avrò la frazione q di quello che esce dal primo e quindi 1/3 , mentre in 𝜆1 entrano tutti i job uscenti dalla
stazione due e rientrano, con probabilità 1 − 𝑞, tutti quelli uscenti dalla stazione uno. Queste due frazioni mi dicono la
stessa cosa perché è un sistema chiuso, scelgo la più semplice per trovare la soluzione lambda cappello.
Finora non stiamo ricavando i flussi effettivi, bensì solamente la relazione presente tra i flussi stessi. Pertanto, per
andare più a fondo, bisogna sfruttare i risultati di Gordon-Newell
Gordon-Newell
Quando abbiamo delle reti chiuse che rispettano le assunzioni di tipo M/M/n interconnesse tra loro senza una
sorgente ed una destinazione, possiamo esprimerli ancora in una forma prodotto perché le probabilità dello stato
non dipendono dai tassi effettivi (le alfa viste prima) ma solo dai flow ratio.

1
Che cosa ci dice questo teorema? La formula è orribile ma mi rappresenta questa forma prodotto. è una costante e
𝐺
la prima parte del sistema vale in tutte le configurazioni degli utenti ammissibili, ovvero:
Se analizzo una coda M/M/1 singolarmente ho infinti stati ma non tutti hanno senso se li interconnetto. Stato
ammissibile significa che quando la somma di tutti gli utenti essa è pari alla mia popolazione, per farlo devo
enumerare tutti i possibili stati ed esplicitarli in forma prodotto.
1
Per risolvere questo sistema devo nuovamente calcolare la costante, in questo caso , e la trovo imponendo che la
𝐺
somma di tutte queste probabilità sia 1.
𝛴𝑖 𝑛𝑖 = 𝐾 significa per tutti gli stati ammissibili della rete. Questo vuol dire che che se nella rete totale la popolazione
è di 3 utenti , lo stato di avere 4 utenti nella prima coda è inammissibile poiché n1 = 4 ma è diverso da K = 3
Vediamo un modo più agevole per studiare questa tipologia di reti, poiché possiamo scriverle in forma prodotto ma
non è proprio molto agevole ed in più mi costringe ad enumerare tutti i possibili stati.

External observer property (tecnica di Mean Value Analysis)

Un’altra tecnica è sfruttare le relazioni che ci sono per le reti a popolazione finita, se ricordiamo potevamo applicare la
proprietà dell’osservatore esterno invece che quella PASTA.

Indichiamo con la lettera 𝑁𝑖 il numero di utenti della i-esima stazione con K utenti, con 𝑇𝑖 il tempo medio di risposta e
𝜆𝑖 il flussi entranti effettivi.

Mean value analysis

Ci viene in aiuto la Mean Value Analysis (analisi al valor medio), ossia una tecnica che consente di analizzare le
performance di una rete chiusa senza calcolare le probabilità a regime. In una rete chiusa con K utenti, tale analisi ci
consente di ottenere:
• Il numero medio di utenti all’interno di ogni stazione 𝑁𝑖 [𝐾]
• Il tempo medio di risposta di ogni stazione 𝑇𝑖 [𝐾]
• Il valore assoluto dei flussi per ogni stazione 𝜆𝑖 [𝐾], quindi il valore effettivo e non un rapporto come prima.

Ma come funziona questa proprietà? Calcolo una relazione sul tempo di risposta, e mi aspetterò che ci metterò un
certo tempo di servizio + vengano serviti i servizi prima del mio arrivo.
Il valore 𝑁𝑖∗ ,per la proprietà dell’osservatore esterno, lo possiamo riscrivere come una rete con K-1 utenti.
Sono così riuscito ad ottenere una formula valida per una rete con K utenti attraverso una con K-1 utenti e posso
quindi procedere ricorsivamente i valori. Notiamo che qui ho ancora il parametro T in funzione di N devo cercare di
legarli ancora.
Posso esprimere il numero medio di utenti, in una rete di K utenti come:

ma perché faccio questo? Applicando la legge di Little, al numeratore e al denominatore posso esprimere il numero
medio di utenti come:

Faccio questo perché così i 𝜆𝑖 che non conosco sia al numeratore che al denominatore, li posso esprimere a meno di
una costante alfa che semplificherò e sostituirò con il tasso di visita:

Una volta che ho trovato tutto applico nuovamente la legge di Little e ottengo i tassi effettivi.

Questo procedimento qui è in realtà l’algoritmo espresso in questa maniera:

• Parto dal caso base con una rete vuota con zero utenti
• Man mano aumento il numero di utenti fino al K desiderato
Questo procedimento mi evita di descrivere tutti gli stati.

Ora c’è un homework che assegnava gli altri anni, adesso essendoci l’esame scritto si può pure non fare ma aiuta a
capire bene come funziona la queue analysis.
Creiamo una rete semplice con valori precisi
In pratica si richiedeva di applicare in matlab l’algoritmo mostrato prima e di vedere come evolveva e capire qual era il
collo di bottiglia.
Adesso a 1:01:40 il prof fa vedere il blocchetto delle esercitazioni che ha caricato in teams.

LEZIONE 26 26/11/21
FMEA Standard (Lec_IE_DEP3_FMEA_Standards_new)
Saranno due lezioni con cenni su sistemi safety critical, i quali sono critici per tempo ed affidabilità e i cui fallimenti
possono avere conseguenze catastrofiche. C’è un grossissimo indotto industriale ovviamente e i 4 grossi centri europei
che trattano safety assessment sono:

• Italia
• Germania
• Francia
• Inghilterra

La linea che useremo per trattare quest’argomenti è molto leggera, non si andrà nello specifico .
NOTA: Per queste cose c’è il corso di Risk assessment tenuto dal Prof. Poziello Alessandro ;D

Le tecniche ingegneristiche che si usano per lavorare su questo tipo di sistemi sono declinate negli standard sopra
mostrati, nello specifico il primo (IEC61508) serve per i sistemi elettronici programmabili, il secondo per l’avionico ed il
terzo per il ferroviario.
L’obiettivo sarà capire dove e, perché ci sono, quali problemi vogliono risolvere e come questi standard influiscono sul
processo. NON SONO STANDARD DI PRODOTTO MA DI PROCESSO.
Da dove ha inizio tutto? Da quando su investimenti di miliardi di dollari post-guerra fredda ci sono stati fallimenti nelle
missioni spaziali.
Nel caso del primo missile fu messo in piedi proprio uno studio per capire quale fu il problema del sistema software
che ha portato a questo tipo di problema, a seguito alla definizione di nuove regole sella progettazione missilistica. Si
capì quindi che il software non era inquadrato in un processo ingegneristico.

Da un punto di vista di un sistema che funziona abbiamo detto qual è la differenza tra un sistema reliable e safety. Va
beh oggi so 50 minuti di esperienze del professore, non le sbobino ma so interessanti perché capite che lavoro orribile
ci aspetta.
Alla fine degli anni 90 e dopo tutta questa serie di cose si è arrivati a determinate conclusioni, i problemi erano causati
da:
• Inadeguata ingegneria del software e controllo qualità
 • Reliability, Availability, Maintainability e Safety (RAMS) ingegneristico inefficiente. I RAM (senza S) sono quelli
che stanno nel reparto commerciale e preparano il sistema alla vendita.
• Troppa self confidence e compiacenza delle attività.

Quindi quello che si è imparato è che gli errori nel design del software possono causare fallimenti nei sistemi che,
sembrano si casuali e difficili da analizzare/capire, ma con le giuste tecniche si possono evitare del tutto o gestire gli
errori.
Un'altra cosa importante, che purtroppo non vediamo, è il negative testing poiché è specifico ed è come testare il
sistema per input non validi.

L’unica cosa da guardare in questo corso, se non si fanno esami di sicurezza, è la differenza tra fault e vulnerability.

L’importanza del Software RAMS (Reliability Availability Mantainability Safety)

Il RAMS è un processo che adotta delle raccomandazioni e che in qualche modo le fa rispettare all’interno dell’azienda
sia in termini organizzativi, che produttori. Ad esempio, la NASA da una serie di suggerimenti e con standard diversi
che però si basano su quest’ultimi.
La maggior parte dei requisiti RAMS e vincoli di progetto sono descritti utilizzando specifiche nominali e non nominali.
Il problema è che trovare i requisiti nomali è molto più semplice rispetto all’individuazione dei requisiti non nominali
che però hanno la medesima importanza dei primi. (Per elencare tutti i possibili requisiti non nominali ci vorrebbe un
sacco di tempo).
Esempio Requisito NON nominale: se non si chiudono le porte del treno, esso non può lasciare la stazione; sembra
banale, ma è un’anomalia che va specificata e gestita. Tutti questi requisiti non funzionali si traducono
nell’applicazione con la gestione delle eccezioni.
RMAS abbiamo detto essere un attività ingegneristica che sta per:

• Reliability: Continuità di servizio

• Availability: Disponibilità all’uso

• Mantainability: Facilità di manutenzione

• Safety: Sicurezza degli operatori e degli strumenti

Queste raccomandation che vediamo di seguito sono la genesi di tutti gli standard dei sistemi safety critical

Una raccomandazione che si usa in tutti i complessi critici è il ISVV (indipendent software verification and
validation). Quindi chi fa i controlli deve essere colui che non sviluppa.
Hazard Assessment
Questo processo è il primo step di sviluppo safety critical, l’hazard è un situazione nella quale c’è un effettivo o
potenziale pericolo per le persone o le cose. Gli hazard possono essere:

• Naturali
• Umani
• Basate su conflitto, che sono sempre umani.

Come si identifica un hazard? Non è facile ma è giusto sapere che non esiste un posto sulla terra senza hazard e
qualsiasi hazard può avere un impatto più o meno direttamente su qualcosa. Per questo motivo per effettuare hazard
analysis si passa per processi iterativi.
Tali attività costituiscono il processo di hazard analysis (in figura):
Il processo di hazard analysis è costituito da diversi cicli, ognuno con 4 step in cui si devono:
1. Definire i requisiti di analisi (es. la porta del treno si deve chiudere)
2. Identificare e classificare gli hazard (Se la porta non si chiude? Se il treno parte e la porta si sblocca?)
3. Decidere su quali hazard agire (Si sceglie ovviamente quelli con un rapporto costo benefici inferiore)
4. Tracciare e accertare gli hazard scelti

Rilevare quali sono gli hazard è un processo molto lungo (possono durare anni) e costoso. Esso viene fatto in parallelo
allo sviluppo del sistema safaty critical e anzi sono presenti alcuni punti di sincronizzazione in cui il progetto non può
andare avanti se non ho definito i rischi.

LEZIONE 27 29/11/21
NOTA: Sta lezione è stata una buttata di sangue, la linea unina saltava ogni 3x2 e quindi non si è sentito benissimo.
Sostanzialmente la lezione è piena di esempi come la scorsa ma la parte più importante è quella legata alla
spiegazione hazard -> rischio. Consiglio di fare ricevimento nel caso non abbiate capito.
Eravamo rimasti alla spiegazione dei sistemi safety critical e di come si progettano quest’ultimi. Ovviamente sono diversi
dai sistemi reliable, soprattutto in costi perché dobbiamo identificare i fallimenti catastrofici; per farlo devo capire come
il sistema può fallire e il suo impatto nell’ambiente.
Quello che si fa, nella prima fase, è identificare le situazioni di pericolo e questi pericoli si chiamano Hazard e si effettua
quindi l’hazard analysis, la quale è un processo complesso e lungo. L’obiettivo è capire quali sono i potenziali pericoli
del sistema e assegnarne un rischio, questo per capire quanto un hazard è pericoloso per il nostro sistema.
Es. Qui all’università un hazard potrebbero essere: un maremoto, un terremoto o un eruzione di un vulcano. Ovviamente
le ultime due qui sono più probabili della prima e quindi è più probabile che valutiamo i problemi che derivano dagli
altri due casi.
Per l’hazard analysis non esiste una metodologia vera e propria, ma si basa su delle tecniche che devono rispondere in
base a quale parte del ciclo andiamo ad espletare. Ma questo sapete dove lo potete vedere? A risk assessment ;D
Una delle tecniche base è il brainstorming dove appunto ci si raccoglie in team e si discutono i possibili hazard,
catalogandoli. Ma in che modo? Spesso si usano delle vere e proprie tabelle:
In riferimento all’esempio della lezione precedente, dove si trattava dell’auto che non frenava

Da questa tabella si inizia a strutturare una chain of failures che permettono di avere sempre una visione ad alto livello
di quelle che sono le conseguenze degli hazard. Qui però non c’è la vera e propria strutturazione della mitigazione al
problema, siamo ancora ad altissimo livello e stiamo solo scremando l’hazard. Il vero passaggio lo abbiamo quando
passiamo da hazard a risk.
Da Hazard a Risk

L’idea è che il rischio è una combinazione della frequenza o la probabilità o l’occorrenza di uno specifico hazardous
event, e la sua conseguenza. Una domanda che potrebbe fare all’esame è: Quali sono gli inpunt/output dell’hazard
analysis? E come viene la fase di risk ? Gli input di una fase di hazard analysis sono gli input stessi del sistema, l’ambiente
dove viene deployato e il sistema stesso; gli Output sono i rischi e a noi interessano quelli con rischio maggiore.
Come calcolo quindi il rischio è pari al prodotto della severità (il costo) e l’occorrenza.
Quali sono le tecniche per identificare i rischi?
I rischi si possono identificare con metodologie che abbiamo già visto, come i FTA (soprattutto per eventi controllabili e
non, con le loro criticità). Abbiamo poi l’HAZOP, lo scopo è quello di identificare le potenziali deviazioni del sistema
rispetto alle operazioni nominali. Tale analisi è ovviamente applicabile in qualsiasi dominio ed utilizza ancora
brainstorming, ma per l’identificazione si basa su parametri di sistema e di guide words. Quello invece più utilizzato, e
che vedremo meglio, è la FMEA e SFMEA (software).

Di seguito vi è l’esempio di alcuni sensori di un aereo, i colori indicano il livello di rischio in base a come indicato
nell’immagine.
FMEA
Failure modes and effects analysis è una tecnica semi-quantitativa per l’individuazione dei rischi, molto completa ed
usata ed è declinata in diversi aspetti. È una tecnica bottom-up di previsione e questo tipo di scelta è per gestire la
complessità.
Perché proprio di tipo bottom-up? Perché tipicamente, un sistema è realizzato come composizione di più componenti (
Talvolta acquistati da fornitori esterni), dunque è chiaro che devo considera gli eventuali fallimenti dei componenti per
poi valutarne l’impatto sul sistema (Le informazioni sul componente date dal fornitore sono utilizzare per capire come
il fallimento di tale componente possa influire sul sistema.)
Ma a che serve la FMEA? Serve a determinare:

• Possibili cause di fallimento di un sistema

• Gli effetti dei fallimenti
• Mezzi di mitigazioni
• Azioni correttive

Gli effetti vengono classificati valutando il rischio.

Ovviamente le fasi sono quelle mostrate di seguito:

Il processo parte dal lato alto dell’immagine, nello step due si iniziano a presentare le variazioni al flusso di sviluppo. Di
solito ci sono due gruppi: un gruppo che qualifica ed uno che propone.
Se parliamo di costi ovviamente abbiamo a che fare con qualcosa di costoso, poiché fare i test richiede tempo e
competenze.
La FMEA è un metodo di risk analysis poiché:

• Step 1-6: Valutazione di capire quali rischi mitigare e quali no. Inoltre, è anche una tecnica di risk management
poiché dopo aver mandato in funzione il sistema poi ad un certo punto prosegue con lo step 7

• Step 7: Ri-valuta i rischi (Questo non è altro che un “return to step 1”)

Da qui si capisce anche perché tale tipo di tecnica ha un effort (costo) molto elevato sul sistema. Se fosse solo risk
analysis valuterei i rischi una sola volta per il mio sistema e quello sarebbe il loro valore per sempre. In questo caso è
anche di risk management poiché a un certo punto vado a “gestire “ il valore del rischio ricalcolandolo. (Può essere
cambiato qualcosa nel sistema per cui un rischio basso diventa altissimo).
Passo 0: Fintantoché non sono stati analizzati tutti i componenti del sistema
Passo 1:
• Si seleziona un componente del sistema [Es. Un sensore]
• Si individuano e definiscono i failure modes (modalità di fallimento) (Es. il sensore non funziona più)
Passo 2:
• Si individuano le cause dei failure modes del componente [Es. Si è bruciata la memoria del sensore] e l’effetto
sul sistema.

• Si verifica se il componente è critico o meno, ossia se il fallimento del componente può provocare il
fallimento dell’intero sistema:

o Se la risposta è no, allora si parte daccapo selezionando un altro componente (vado al passo 0)
o Se la risposta è sì, allora si procede analizzando se è possibile prevenire tale fallimento, se è possibile
tollerare tale fallimento, se è possibile ridurre la probabilità del fallimenti, etc. Vado al passo 3
Passo 3:
A questo punto si verifica se i meccanismi definiti per prevenire/tollerare/etc. il fallimento del componente sono
sufficienti:
o Se sì, allora si integra il tutto nel progetto del sistema e si ritorna al passo 0.
o Se no, allora occorre compensare e correggere tali meccanismi e si ritorna al passo 0.
La FMEA è un processo a supporto delle due fasi cerchiate per lo sviluppo di un sistema.
La prima fase di studio dei Failure modes è quella di identificare le componenti di un sistema e di analizzare i failure
modes. Ma cosa sono i failure modes? Sono il modo in cui una funzione/componente fallisce, in termini di deviazione
dal suo comportamento aspettato.

Failure Modes Identification

Il concetto fondamentale della FMEA è il Failure Mode. Un Failure Mode descrive come una funzione o componente
può fallire, in termini di deviazione rispetto alle proprie specifiche (quanto si comporta diversamente dal
comportamento atteso).
FMEA non fornisce un unico metodo per identificare i failure modes poiché il metodo da adottare dipende:
• Dalla fase di sviluppo in cui è applicata la FMEA
• Granularità a livello di design o analisi
• Esperienze precedenti con sistemi simili.
Ad esempio, esistono dei picchetti da mettere nel terreno che misurano la variazione della distanza del terreno stesso,
la loro utilità è collegata a terreni franosi.

Fare una failure mode analysis significa capire come fallisce un componente e lo vediamo nell’immagine.
Ad esempio, per il sensore a bordo un potenziale valore fermo a zero è un errore; lo stesso dicasi per un null reading/
bloccato ad un valore N.

Quello che si cerca di fare quando si elencano i possibili problemi è elencare solo i fallimenti più importanti, questo
perché se io faccio più controlli aumento i suoi costi. In questo caso il budget era di 15K ma fu fatto abbastanza bene.
Un ulteriore esempio di FMEA è sui dati di volo:
Quando elenco tutti questi fallimenti quello che voglio fare è creare un modello di propagazione, ad esempio voglio
studiare gli effetti di un fallimento nel componente C1 e per capire gli effetti dell’operational envirorment devo vedere
la propagation trace.
Posso utilizzare una catena di Markov, oppure un diagramma UML

Analyzing Failure Modes

Ogni failure-mode identificato è analizzato tramite dei meeting di brainstorming e/o workshop al fine di identificare le
criticità in termini di:
• Gli effetti del failure mode e la relativa severity
• La probabilità di occorrenza del failure mode
• La capacità di detection del failure mode.

Effects
Vediamo adesso la parte di valutazione del rischio. L’effetto è la conseguenza di un failure mode e deve essere
catalogato per capire la severità dello stesso, lo facciamo in termini di:
 • Sicurezza personale e/o degli utenti
• Dependability del sistema
• Danno all’infrastruttura
• Danno ambientale

Un rating fondamentale che utilizziamo nella FMEA è la severity (Gravità dell’effetto). Gli effetti si dividono in base al
colore ed in base alla criticità degli stessi, ovviamente il rosso è il peggiore fino al verde che è il meno critico.
Si associa un ranking (valore) alla severity dell’effetto come mostrato in figura: [ (tipo effetto),(severity),(score)]

Si hanno diversi livelli:

• None (senza effetti), Very Minor (es. si rompe una lampadina nel cockpit di un aereo, ma non si hanno gravi
effetti)
• Minor, Very Low, Low e Moderate iniziano ad impattare sul sistema
• High, Very High, Hazardous with warining e Hazardous without warining (es. Boeing 737 MAX, in cui il Sistema
non rilevava proprio il failure), i quali hanno un grado di severity molto elevato.
Probabilità di occorrenza
La probabilità di occorrenza è la probabilità/frequenza con la quale avviene un failure mode. In un sistema safety critical
è difficile da stimare e per farlo si valutano le potenziali cause di un fallimento, quali:
• Errore umano
• Fallimenti di componenti/sottocomponenti
• Errori ambientali
• Eventi esterni
Anche l’occorrenza viene classificata sempre con i tre colori. Ricordiamo che noi dobbiamo arrivare a quantificare il
rischio.

Detection
La detection è la parte più importante di un sistema safety-critical, anche per la detection si fa la stessa divisione di
colori, ed è considerata come la capacità che il controllo trovi(detect)/contenga il failure mode prima che esso
influisca sul sistema/persona/infrastruttura/ambiente.
Risk Evaluation
Quindi riassumendo si hanno le tre tabelle, queste vanno moltiplicate tra loro e tale passaggio va fatto per qualsiasi
modello. Così facendo quantifichiamo il rischio e da tale passaggio quello immediatamente successivo è ottenere la
matrice di criticità oppure calcolare il Risk priority Numebr (RPN).
Perché è importante valutare i rischi?
• Assegnare una priorità alle problematiche identificate dall’analisi
• Assegnare/Guidare azioni correttive a tali problemi.
• Ri-valutare i rischi.
Questa matrice è numerata per valori decrescenti del prodotto di occorrenza x detection, mentre le colonne sono con
un valore decrescente di severità. I valori più critici sono nel primo quadretto.
Essa viene “popolata” tramite informazioni di Severity, Occurence e Detection per ognuno dei failure mode dei
componenti del sistema (Ogni failure-mode è un punto nella matrice). In particolare, è immediato osservare che
spostandosi in direzione della freccia rossa si incrementa la criticità del failure mode.
La tecnica di RPN invece ci informa che il rischio è dato dal prodotto tra severity (SEV), probabilità di occorrenza (OCC)
e detection (DET):
𝑅𝑃𝑁 = 𝑆𝐸𝑉 ∗ 𝑂𝐶𝐶 ∗ 𝐷𝐸𝑇
Si dà in questo modo una priorità ai rischi per poter applicare, se necessario, azioni correttive

(S)FMEA
Nel caso di software abbiamo che i failure modes sono da intendersi come comportamento incorretto del software.
Dagli output possiamo ottenere indicazioni sullo sviluppo complessivo, infatti otteniamo:
• Mitigazione di fallimenti software a livello di design.
• Valutazioni dei livelli di criticità.
• Allocazione di attività di Verifica&Validazione.

Quando facciamo la FMEA dobbiamo dividere i requisiti Hardware da quelli Software perché seguono due processi
diversi.
Ma dov’è localizzata la FMEA in un processo RAMS? Abbiamo sicuramente un gruppo che fa Hazard analysis e quando
c’è software ci deve essere chi si occupa dell’interazione HW e SW (HS Interaction Analysis), ad esempio il quadro degli
strumenti di un monitor usato nei treni.
Il gruppo CCFA studia i common cause failure analysis, i cc sono quei fallimenti condivisi e richiedono un’analisi a
parte. FTA si occupa di decidere quali sono i problemi HW e quali i SW.
APPROFONDIMENTO CC (sempre da risk assessment): Non sempre possiamo considerare gli eventi di failure come
indipendenti e quindi studiamo gli eventi che condividono una causa comune. Partiamo dal concetto di dipendenza
Per dipendenza intendiamo un collegamento o una connessione tra due oggetti, tale che lo stato di una influenzi o
derivi dallo stato dall’altro. Una dipendenza può essere direzionale o bidirezionale, sempre in base a quale tipo di
relazione c’è trai due oggetti.
Abbiamo due tipi di dipendenza:

• Dipendenza deterministica,
• Dipendenza statistica
L’output della RAMS analysis a livello di sistema è dato in input alla RAMS Analysis a livello software

Certificazione
Che cos’è la certificazione? È un processo conforme ad uno o più standard, questo perché la qualità di un prodotto è
soggettiva non oggettiva. Mentre quello che è possibile fare è valutare oggettivamente un processo.

Una volta si certificavano solo i sistemi safety critical, ma ad oggi si è espanso a tutti i campi. Si parte da un applicant,
che è il richiedente, e deve fornire un certification package (sono dei documenti/prototipi/casi di test che devono
dimostrare l’aderenza del processo e il prodotto finale all’ente esterno).
Un assessor che valuta il package e in base alle sue risposte l’authority rilascia il certificato.
Esistono vari tipi di standard, che hanno radici comuni, ad esempio il IEC61508 è quello per i sistemi elettronici
programmabili.

Esistono delle basi comuni tra i vari standard e sono chiamate commonalities e sono riassunte nell’immagine successiva:
Vediamo ad esempio adesso il FLOW dello standard avionico DO178B e perché l’ingegnere di sistema è importante.
Quando arrivano i requisiti ne sono più di 1800 e c’è bisogno di separarli uno ad uno manualmente.
Ovviamente anche qui c’è sempre il ciclo di sviluppo a V
LEZIONE 28 02/12/21
Software fault tolerance (Lec_IE_DEP4_SWFT_new2020)
Ovviamente non sarà facile contestualizzare tutti gli argomenti in due lezioni, soprattutto per il nostro ramo proprio
perché gli argomenti sono vasti e disparati.
Vedremo principalmente cosa succede in ambito industriale e di come tutto discenda dalla direttiva NASA TM 2000-
210616. Ma mettiamo subito in chiaro una cosa, se adottiamo tecniche di ingegneria del software ed un processo
buono allora il software sarà sicuro ed affidabile.
Quindi prima effettuiamo un buon processo e in maniera sistematica e poi applichiamo le tecniche, soprattutto perché
quest’ultime costano.
Ma perché esiste questo problema nel software? Perché prima di tutto è difficile da provare che un software sia corretto
e anche perché è una disciplica software. Quando effettuiamo delle analisi non facciamoci prendere la mano
dall’utilizzare modelli complessi perché sbagliare un modello è molto più grave di sbagliare un software.
Ma cosa vuol dire guasto software? Il solo tipo di possibile guasto in un software è quello “di design” introdotto
durante lo sviluppo del software stesso. Comunemente sono chiamati bugs e le conseguenze di questi fallimenti
dipende dall’applicazione e dalla particolare caratteristica del guasto.
Le tecniche di software fault tolerance(SFT) sono quelle tecniche utilizzate per far fronte ai guasti residui (Residual
fault), cioè guasti che eludono tutte le fasi di testing.

Approcci alla software fault tolerance

Gli approcci sono sempre quelli classici visti durante anche la parte di affidabilità:
• Fault prevention
o Dipende dall’uso e dalla progettazione di metodologie, tecniche e tecnologie finalizzate alla
prevenzione di introduzione di guasti all’interno del design
• Fault removal
o Si considera l’uso di tecniche come review, analisi e testing per confermare l’implementazione e
rimuovere solo fault che vengono esposti in tal modo.
• Fault tolerance
o È l’uso di tecniche che permettono il continuo rilascio di servizi con un certo livello accettabile
di performance e safety dopo che un guasto di progetto diventi attivo.

Non dobbiamo dimenticarci dell’importanza della software engineering, queste cose che vedremo non sono delle
alternative ai concetti che abbiamo studiato durante i corsi ma è un rafforzativo. Le tipiche fasi di test che facciamo a
valle di una produzione di un artefatto software sono molto buone per scovare i deterministic fault (quelli che non
dipendono dallo stato del sistema). Ad esempio, se facciamo una find sul nostro file system frammentato essa fallirà;
se invece non è frammentato troverà il risultato. Il bug in questo caso risulta dallo stato del sistema.
Un grande numero di fault sono definiti state-dependent faults e sono attivate da particolari sequenze di input.
Lo scopo dei metodi per la fault tolerance è quello di includere le richieste di safety nel design del software o nel
codice sorgente al fine di ottenere risposte corrette, da parte del software, ad input errati e prevenire output o
controlli errati. Il bisogno di error prevention o fault tolerance è determinato dai requisiti di sistema e dal processo di
safety assessment.

Misure della qualità di un software

Dal punto di vista di un sistema software due sono le misure di qualità più importanti:
• Reliability, ripetiamolo è la probabilità di non avere errori nelle operazioni in un ambiente specifico per uno
specifico di tempo
• Safety, ripetiamolo è la probabilità che il software funzioni all’interno di un contesto senza contributi di
hazards.
Ma come misuro la reliability di un programma? Supponiamo di avere R requisiti e verificare che siano tutti corretti,
divido poi il mio gruppo di lavoro in due parti: Parte A e parte B, ognuno mi deve sviluppare un componente eseguibile
distinto.
• A ha una metrica che mi dice i difetti che ha 100 difetti
• In B ho 5 difetti.
Qual è più affidabile? Dipende dal profilo operazionale ovvero dallo spazio degli input e delle variabili d’ambiente.
Se il profilo operazionale è tale che tutti gli input attivino questi cinque bug allora il software fallisce sempre ed A è
migliore di B.
Quando ci spostiamo a lato software anche la nozione di reliability diventa tremolante poiché non è più di facile
definizione. Gli ingegneri del software la valutano come il numero medio di bug, quelli di sistema invece non accettano
questo tipo di definizione perché dipende dal profilo operazionale.

Tra i due il terzo gode e puntiamo quindi alla safety.

Le tecniche di fault tolerance sono divise in due gruppi:

 • Single version techniques, in cui non esplodo la ridondanza del sistema ma mi concentro sulla detection,
containment ed error manipulation
• Multi version techniques, realizzo più versioni del software ognuno con strumenti e metodologie diverse.

Dipende sempre dalla disponibilità economica.

Single version fault tolerance robust data structures che vuol dire? Significa rendere le strutture dati più robuste alle
perturbazioni dei guasti. Esistono due metodologie ma ci focalizzeremo solo su una:

• Semantic integrity, come preservare l’integrità semantica ovvero come codificare i dati.
• Structural integrity, usata per preservare la corretta rappresentazione dei dati. (Useremo questa)

Robust Data Structures

L’obiettivo è di trovare strutture dati che siano robuste agli errori e ai fallimenti. Vediamo un esempio della robustezza
strutturale di una lista lineare a puntatori; quindi, non pensiamo agli errori sui dati ma solo sui puntatori. Supponiamo
che venga perturbato un puntatore, in questa lista lo rileviamo? No a nessun tipo di perturbazione e quindi non rileva
ne corregge un errore.
Una robusta struttura dati contiene dati ridondanti che consentono di rilevare i cambiamenti errati (erroneous
changes)e danno la possibilità di correggerli. Rendere robusta una struttura significa migliorare la capacità di rilevare e
correggere gli errori (Improve the error correction and error detection)
Ma quindi la domanda è, quali dati ridondare? Dipende dalla struttura dati che si utilizza (Per la lista a puntatori si
ridondano i puntatori).

Consideriamo la struttura dati della lista a puntatori. Ogni nodo ha un puntatore al nodo successivo in lista, ad eccezione
dell’ultimo che ha un null pointer. Questa struttura è robusta (quindi ci chiediamo se l’errore è rilevabile e correggibile)?
Si osserva che tale struttura è 0 detectable e 0 correctable poiché se un puntatore si corrompe si perde l’informazione
nella lista (Ad esempio se per errore header.next diventa NULL perdo tutta la lista)
Ok, allora supponiamo di fare una lista toroidale dove l’ultimo elemento lo collego al primo e ovviamente aggiungo
che il primo elemento mi dice il numero di componenti nella lista. Se si rompe un puntatore posso rilevarlo ? Sì, perché
lo comparo con il numero di nodi che trovo.
Si dice che tale struttura è 1 detectable e 0 correctable

Esiste poi la lista doppiamente concatenata che per migliorare la robustezza aggiunge ad ogni nodo un puntatore al
nodo precedente così da creare una lista doppiamente puntata. Questa struttura è robusta ?
Si osserva che tale struttura è 2 detectable e 1 correctable.
Tecniche di fault software tolerance: Recovery Block/ N-version Programming
La tecnica di tolleranza più usata è lo stut e appicc o per gli amici checkpoint and restart. L’obiettivo è cercare di rendere
i fallimenti di un software più indipendenti possibili.
In molti casi la manifestazione di un software defect aveva le stesse caratteristiche di un guasto transitorio. Esistono
delle librerie per effettuare il checkpoint dove definiamo delle variabili che compongono lo stato del sistema, o una
struttura dati, e il checkpoint si occupa di salvarli per recuperarli al riavvio. In industria usiamo il process pair che non è
una replicazione attiva ma passiva, dove abbiamo una copia master che si sintonizza con una di back up.

Il process pair è strutturato come in figura dove quello che succede è che ogni volta che si effettua un’operazione su
primary, il quale modifica lo stato del SO, si modifica anche lo stato di backup tramite propagazione.
Dopo di che c’è un meccanismo di feeling dell’altro sistema per capire se è vivo. Tipicamente si passano dei checkpoint
prima di avviare i processi di sincronizzazione, quando però primary non risponde più ai messaggi di feeling il backup si
attiva per prenderne il posto e risponde alle richieste.
Dove viene usato un sistema del genere? Sicuramente in quelli transazionali e conviene non cambiare questo modello
in caso di sistemi non transazionali.
Il suo funzionamento sembra banale, ma non lo è; infatti, non è molto robusto poiché potrebbero esserci dei ritardi e
potrebbe entrare in servizio per sbaglio. In più lo schema funziona su diversi livelli di astrazione.
In letteratura non si usa un solo messaggio ma si usano dei treni di messaggi, oppure si usa un messaggio a crescita
temporale esponenziale.

Andiamo ora su considerazioni più astratte e passiamo ai sistemi critici, non solo gli aerei ma anche quelli economici.
Due sono le osservazioni rilevanti fatte negli anni e li vediamo a costi crescenti.
Il primo è recovery block, una tecnica che cerca di replicare, con diversità, solo le funzioni fondamentali che
impattano direttamente sugli hazard. È una tecnica in cui il concetto di diversity non è applicato all’intero sistema
(penso software) ma solamente ad alcune funzioni, inoltre l’integrazione non è fatta in parallelo, ma in serie.

Il recovery block funziona replicando, con gruppi diversi diverse versioni, le funzionalità e il celeste indica la logica extra
per gestire i recovery block. Ma come funziona? Svolgo il primo algoritmo e vado verso l’acceptance test, il quale dice:
o ha ragione o ha torto.
Nel primo caso vado avanti, nel secondo caso richiede consiglio ad un altro algoritmo e questo può andare avanti
all’infinito (anche se di solito si hanno al massimo 3 blocchi).
Vantaggio: Questo tipo di approccio è economico perché non la applico a tutto il sistema ma solamente ad alcune
funzioni di interesse.
Svantaggio: Il module di acceptance test non è un oracolo, è difficile da realizzare e si deve tenere in considerazione il
compromesso costo / complessità.

Cosa succede in ambienti in cui non è tanto più una singola funzione da controllare ma diverse? Quello che facciamo è
l’N-version programming ovvero n-versioni diverse dello stesso programma.
Il concetto di diversity è applicato all’intero sistema software poiché si spera che le diverse versioni abbiamo fault
differenti.
Ma quali sono i problemi di questo tipo di approccio? I common mode failure poiché se nell’esempio tutte e tre
falliscono nello stesso modo siamo fregati. Ma da dove provengono?
• Dai requisiti sbagliati, e quindi in questi sistemi devono essere corretti e precisi
• Dagli errori di programmazione umani che sono comuni nelle conoscenze sbagliate.

L’inventore del NVP ha posto l’attenzione sul fatto che non si è assunta l’indipendenza dei fallimenti. Questo non
significa che è una tecnica inutile, ma che la reliability del sistema non può essere alta come nel caso in cui i fallimenti
delle varie versioni software siano indipendenti.

Perché non vale l’indipendenza dei fallimenti? Le persone tipicamente tendono a fare gli stessi errori, difatti
statisticamente gli sviluppatori ragionano allo stesso modo sui problemi complessi.

Un altro problema è che non sappiamo quanto migliori in affidabilità, io dovrei avere che la probabilità che fallisca
questo N-version system sia pari a 𝑃(𝑓𝑎𝑙𝑙𝑖𝑚𝑒𝑛𝑡𝑜 𝑑𝑖 𝑢𝑛𝑎 𝑣𝑒𝑟𝑠𝑖𝑜𝑛𝑒)𝑁 ; il problema è che c’è una parte di dipendenza e
se non ci fosse dovrei comunque aggiungerla. Quindi è molto importante che i failure siano indipendenti.

Le tecniche che sono state spiegate possono essere mischiate, in base al contesto operativo, e se siamo capaci di metterli
insieme e a farli funzionare otteniamo configurazioni con alti risultati. Ad esempio, nel N-Self checking programming ho
un unione di alcune tecniche dove: non solo riesco a comparare ma ho anche una stime di quanto sia giusta una risposta.
Il più completo e difficile è il seguente:

LEZIONE 29 03/12/21
Cloud Computing Systems con Pietro Liguori (Lec_IE_Cloud)
Vedremo oggi dei concetti base sulla parte di cloud che servono per capire effettivamente come funziona il cloud. Non
è possibile fare il load balancing senza aver visto come funziona il cloud.
Ma che cos’è il cloud? Noi faremo riferimento specifico al Cloud come rete o internet. Infatti, la famosa nuvoletta che
vediamo corrisponde ad una serie di servizi messi a disposizione per tutti in rete. In altre parole, possiamo dire che il
Cloud è un qualcosa che è presente su una locazione remota, ma che servizi possono essere forniti? Vedremo che a
seconda dei servizi forniti facciamo distinzione tra i tipi di cloud.
Tra i vari servizi ci possono essere applicazioni con E-Mail, Google calendar è un servizio di cloud computing, storage,
databases, networking, software, analytics. Non installo sul dispositivo ma con internet accedo all’app, che si trova in
una locazione remota, e usufruisco dei suoi servizi.
Se passiamo ad una definizione più formale abbiamo che il cloud computing è il fornire un insieme di servizi offerti
attraverso internet per fornire innovazione, flessibilità delle risorse e scalabilità economica.
Il cloud computing fornisce una serie di servizi:
• Database
• Storage (Dropbox/Google drive)
 • Servizi di cloud di VM come Google Colab.

Quando capita che questi servizi non siano gratuiti ma sono a pagamento abbiamo che la cosa interessante è che ciò
che pago è solo quello che utilizzo; non pago quindi un abbonamento. Più utilizzo più pago, se non faccio uso non
pago nulla, dunque il paradigma di utilizzo è proprio questo.
Il cloud computing è combinazione sia di una parte software sia di una parte hardware, anche quando creo una
macchina virtuale.
Alcune delle caratteristiche del cloud-computing sono:

• Trasparenza: Le risorse del cloud sono utilizzate come se fossero risorse locali.
• Scalabilità
• Dependability: Servizi sempre disponibili
• Sicurezza* (Si mette l’asterisco perché è un qualcosa di difficile in ambito cloud).
• Facile da mantenere
La definizione più usata del CLOUD COMPUTING è quella del NIST (slide 6):

Il NIST descrive anche cinque caratteristiche essenziali per un servizio di cloud computing. Prima di fare un elenco di
ciò, ricordiamo che il cloud è combinazione di hardware e software e sappiamo che è possibile vedere il tutto come
composizione di:
• un layer fisico (Consiste in risorse hardware necessarie per supportare il funzionamento dei servizi cloud)
• un abstraction layer (Consiste nel software deployato lungo i layer fisici che manifestano le caratteristiche
essenziali del cloud). Posso usufruire del software, se e solo se, si poggia su un hardware.
Quali sono le cinque caratteristiche descritte dal NIST?
1. On demand self-service: l’utente decide lui da solo cosa vuole e quando lo vuole. Non ha bisogno di un
qualcuno che interagisca con i vari fornitori di servizi.
2. Broadcast network access: le risorse del cloud devono essere accessibili tramite la rete e quindi l’unica cosa
che serve per avere on demand self-service è la rete internet.
3. Resource pooling: fa riferimento ad una caratteristica del cloud che è la multi-tenency, ovvero il poter
consentire ad utenti diversi, o organizzazioni diverse, di accedere alla stessa istanza e alle stesse risorse. Ad
esempio, se ho una macchina in California e su di essa ho tot macchine virtuali, posso far sì che un
organizzazione usufruisca di una VM, un’altra organizzazione usi un’altra VM e così via. Quindi la stessa
macchina fisica venga condivisa da più organizzazioni che manco si conoscono questo consente di avere
anche un risparmio energetico. Vedremo che l’uso di una macchina hardware non è mai al 100%, se però
sullo stesso processore metto più VM vedo che il processore viene sfruttato di più e quindi ho un efficiente
utilizzo delle risorse hardware. Per questo le strutture di cloud computing sono sempre presenti nella ricerca
 di tipo green. Per quanto sia ovvio vederla dal punto di vista ambientale, diventa molto più difficile nel
contesto dell’informatica soprattutto nell’ambito della cyber sec di tipo green. Tra le varie cose che è facile
inserire c’è il cloud che ci fa risparmiare sia dal punto di vista energetico che dal punto di vista dei costi per
ottenere l’hardware.
4. Rapid Elasticity: quando creo una VM decido quali sono le caratteristiche fisiche di questa macchina a livello
di processori, memoria etc. Supponiamo di iniziare con una macchina base che soddisfa i miei task, se poi mi
serve una macchina più prestante? Allora chiedo al mio erogatore di risorse, più risorse e mi vengono fornite.
Posso sia richiedere una riduzione delle risorse.
5. Measured service: i sistemi di cloud automaticamente controllano e ottimizzano le risorse usando delle
metriche e dei monitoring tools che permettono di capire quanto una macchina stia consumando. Questo
assicura la trasparenza tra provider e consumatore. Permette anche di tenere sott’occhio i costi poiché
vediamo la previsione del carico del lavoro.

CONCETTI BASE
Non tutti i cloud sono identici e questa classificazione viene fatta in base al modello di lavoro per il cloud computing:

• Deployment models, definisce il tipo di accesso al cloud (Pubblico, community, private, hybrid)
• Service models, definisce il tipo di servizio offerto agli utenti (IaaS, PaaS, SaaS)

Un’ulteriore tassonomia è interna ai due principali modelli scritti sopra. Quindi per i DEPLOYMENT MODELS ho
quattro modelli dati dal NIST (spesso se ne considerano tre dove il private e community sono uniti):

• Private cloud: L’infrastruttura cloud è fornita ad uso esclusivo di una singola organizzazione che fornisce dei
serviti a multipli utenti. Ma allora perché privato? Perché non tutti ci possono accedere, ma solo chi fa parte
di questa organizzazione. Ad esempio, l’università.
• Community Cloud: non si vede molto questa definizione oggi ma si fa riferimento a quei servizi che vengono
forniti a degli utenti, sempre facenti parti di un organizzazione, da parte di una organizzazione e anche ad
altre che hanno scopi comuni. Ad esempio, un servizio di cloud computing per tutta la comunità scientifica
italiana.
• Public cloud: come Amazon, Google etc che forniscono accesso a tutti. Basta avere internet e pagare per
accedere.
• Hybrid cloud: un mix, una combinazione di almeno due delle precedenti. Un esempio può essere una
organizzazione, che fornisce l’accesso solo ai membri di quell’organizzazione, usa un private cloud ma esso si
poggia su un public cloud più grande. Ad esempio, noi dell’università possiamo accedere ai servizi Microsoft.

Passiamo ora ai SERVICE MODEL ed essi sono tre e posso vederli su una piramide sono:

• Infrastructure as a service (IaaS), sono alla base perché forniscono i servizi essenziali.
• Platform as a service (PaaS), oltre a inglobare i servizi offerti dal livello superiore, offre anche applicazioni e
tool di sviluppo per facilitare il ciclo di vita completo di produzione e distribuzione di applicazioni e servizi
web. (Un esempio è aws e Azure).
• Application as a service (SaaS), quest’ultimi essendo sopra alla piramide accedono ai servizi sottostanti, un
applicazione software come servizio è office 365.
Iniziamo con infrastracture as a service, è la base della piramide e sono i servizi che vengono forniti al consumatore e
permettono di sfruttare storage, networking e altre risorse di computing. Pensiamo ad una infrastruttura, se creo una
VM ho che questa mi permette di:
1. gestire lo storage (devo riservare spazio e un volume),
2. computing perché la VM mi permette di usare le risorse di calcolo,
3. networking per poter accedere in rete.

Questi tre servizi di base sono forniti dalle infrastrutture di cloud computing. Una delle piattaforme di cloud
computing più famose come Infrastructure as a service è OpenStack.
Se ad esempio vado su OpenStack, che è gratuito, esso mi crea una VM ma non mi chiede che SO ci voglio sopra.
Questa macchina virtuale poi la posso usare come voglio e ci posso mettere quello che voglio avendo semplicemente
tutto ciò che serve per fare Networking, Storage e Computing. Questo perché l’utente non gestisce o controlla
l’infrastruttura di base del cloud ma ha il controllo sul sistema operante.
Nel platform as a serivice, oltre ad avere tutto quello del livello precedente, posso anche avere dei tool che mi
permettono di costruire delle applicazioni. Se uso Azure e creo una macchina virtuale esso mi chiede che voglio come
OS su sta VM? Che ci voglio fare? IA? O altro? E quindi in base alle mie esigenze ho una macchina più customizzata e
mi ingloba i servizi del livello precedente. Mi permette di lavorare e programmare. AZURE E Aws.
Infine, ho SOFTWARE AS A SERVICE SaaS ed è tutto il software poiché posso accedere senza installare niente sul mio
sistema. Ad esempio, OFFICE365 o Google Calendar e quindi il servizio che mi viene offerto è il software. Lo trovo in
cima alla piramide.
Possiamo vedere nell’immagine sopra un po’ il tutto in sintesi.

Composizione cloud system

Dal punto di vista fisico come può essere visto un sistema di Cloud computing?
1. Primo componente è il controller, ovvero colui che fornisce l’interfaccia che gestisce le richieste che vengono
dall’utente e le inoltra.
2. Lo switch inoltra la richiesta che proviene dal controller verso uno dei nodi compute, i quali elaborano la
richiesta.
3. Il terzo componente è lo storage, il quale permette di salvare i propri dati e può essere visto come la parte
hardware del cloud computing

Quello che la slide successiva vuole trasmetterci è che il controller ed il compute posseggono 1 TB mentre lo storage
24000 GB, il senso è che ogni componente avrà gli elementi più importanti per le proprie prestazioni più performanti.
Il Cloud storage, a differenza dello storage precedente, permette di salvare i propri dati e anche di tenerli
sincronizzati. Se mi sta bene la parte free okay, se voglio più storage pago e faccio pay per use.
Come funziona il cloud storage?
1. Un client invia copie dei dati a data server tramite l’internet i quali si occupano della memorizzazione
dell’informazione
2. Quando il client vuole recuperare l’informazione, accede al data server tramite un interfaccia web
3. Il server a questo punto invia i dati al client o dà la possibilità di accedere o modificare i dati direttamente al
suo interno.

Tecnologie e metodologie abilitanti

Le tecniche e le tecnologie che sono abilitate dal cloud computing quali sono?
1. la prima è la virtualizzazione dove ho un ambiente virtualizzato che astrae le caratteristiche di una parte
hardware che sta sotto. Il cloud si basa sulla virtualizzazione perché quando creo le VM sto creando uno
strato virtuale che astrae la parte hardware.

2. La multitenancy l’abbiamo vista prima dove avevo più VM sullo stesso hardware e lo stesso può valere per
un software che viene fornito a più organizzazioni.
3. WEB 2.0, si realizzano pagine web standardizzate, flessibili ed interattive. Questo vuol dire che posso
accedere in modo standard a quelle che sono le risorse e permette l’accesso agli utenti in maniera più
semplice ed agevole consentendo l’uso attraverso cellulari etc etc.
4. La gestione delle richieste. I servizi di cloud computing comunicano con un meccanismo basato su code, tale
meccanismo viene detto AMQP che è un protocollo che permette la comunicazione tra servizi interni.
Quando parliamo di cloud computing stiamo parlando di un sistema distribuito e quindi sono più nodi che
comunicano tra di loro con questo protocollo. Quando arriva una richiesta dall’esterno, che è principalmente
una richiesta http, arriva a chi gestisce la risorsa in cloud e viene poi inviata verso i nodi interni, i quali
comunicano con il protocollo AMQP per gestire le risorse.
5. Scheduling dei task, si parla dell’allocazione delle risorse in modo opportuno al fine di minimizzare i costi sia
dal punto di vista energetico che di capitale.

I processori reali e fisici sono utilizzati tra il 20 e il 40 percento, con il picco tra 0 e 10% di utilizzo, e non vengono mai
sfruttati tra il 60 e il 70 percento allora se metto più VM su un processore ho un aumento dell’utilizzo delle risorse
(ritorna alle tematiche green introdotte prima).
Quindi ho un utilizzo efficiente delle risorse utilizzando la virtualizzazione.

Reliability e security in cloud

Andiamo ora parlare di Reliability e Security con la virtualizzazione. Se sul mio PC ho più macchine virtuali, esse non
si vedono l’una con l’altra e sono ambienti chiusi. Le macchine virtuali tra loro sono completamente divise, tranne che
per lo strato di Hypervisor, se faccio un attacco ad una delle due macchine virtuali non posso accedere all’altra e
questo permette di fornire meccanismi di reliability migliori, così cerco di fornire più reliability e sicurezza.

Per quanto riguarda la reliability ci vuole un asterisco gigante perché questi servizi possono fornire un downtime
annuale di circa cinque minuti all’anno (idealmente, ma nella realtà siamo molto lontani da questa specifica).
Forse abbiamo sentito altri paradigmi oltre al cloud computing come il GRID COMPUTING e UTILITY COMPUTING,
questi non vanno confusi con il cloud. Sebbene il cloud includa ciò che trovo nel Grid e nell’utility non è vero il
viceversa.
• Il Grid collega tra loro più computer uniti attraverso la rete e lavorano per svolgere un determinato task in
maniera distribuita.
• Le utility sono pay per use e forniscono storage, computing power etc. non è cloud computing perché non
c’è l’accesso ad Internet.

OPEN STACK
OPEN STACK SERVICES:
Abbiamo detto che OpenStack è un’architettura di cloud computing di tipo Infrastructure as a Service ed è tutta scritta
in python. I nodi forniscono computing, storage e networking e sono i servizi base per IaaS e vi posso accedere tramite
linea di comando oppure una dashboard.
I vari componenti di OpenStack sono detti o servizi o sottosistemi o componenti o progetti, ci sono diversi modi per
chiamare cosa c’è dentro. I più importanti sono:
• NOVA che fa computing. Nova mi permette di creare le VM e altre risorse di computazione.
• Il networking che mi viene data da Neutron o anche quantum, esso permette di creare reti sottoreti, floating
address IP, etc. Mi permette di collegare la VM creata con NOVA alla rete.
• Il block storage mi viene fornito da CINDER. Esso mi dà la creazione di volumi e creando una VM devo
associare ad essa uno spazio ed è un block storage. Questo block storage fa sì che la macchina virtuale abbia
uno spazio su cui lavorare. Quando lavoro con open stack ci basiamo sulla parte di linea di comando che
permette di automatizzare gli script che vogliamo realizzare.
• Dashboard Horizon, fornisce una UI web per I servizi di OpenStack
• Altri servizi includono Identity, Image e Orchestation

Slide 42 schema di OpenStack, super complesso, che ha tanti sottosistemi che comunicano tra di loro. La
comunicazione avviene con un sistema basato su code basato su AMPQ e qual è il senso? L’utente nella parte in alto
fa richieste con una dashboard o linee di comando. Queste richieste arrivano nel sistema di cloud e a seconda della
richiesta partono una serie di comunicazione tra tutti questi moduli o sottocomponenti.
Questa qua (slide 44) mi fa capire quanto è complessa una singola richiesta fatta ad un sistema di cloud computing I
numeri sono i messaggi che si scambiano i componenti.

E fa riferimento ad una sola richiesta utente che è CREA ISTANZA. Per istanza intendo un Server o VM. Quindi che
faccio? Mi devo autenticare, poi faccio la richiesta che è OpenStack server create e poi devo specificare una serie di
parametri. Devo specificare l’immagine, la rete e il volume (quindi passo per Glance, Quantum e Cinder). Nova, che
gestisce l’istanza, controlla la richiesta e inizia a comunicare con i suoi servizi interni e poi va da Glance per l’immagine
attraverso l’ID, poi da Quantum per il particolare tipo di rete e infine da Cinder per il volume di storage.
Alla fine di questa orchestrazione di più componenti, viene portata a termine la creazione dell’istanza che da building
passa in stato attivo. Questo ci fa capire quanto sono complessi questi sistemi e i numeri non è detto che siano sempre
gli stessi IN ORDINE IL LORO COMPORTAMENTO NON è DETERMINISTICO.

LEZIONE 30 6/12/21
Nell’ultima lezione abbiamo visto il concetto di Cloud computing focalizzandoci su quello che sono i principali vantaggi.
Per portare app su Cloud devo sviluppare con librerie ad hoc e non è vantaggioso portare delle legacy application su
Cloud perché non possono beneficiare dei vantaggi che offre il cloud. Oggi che facciamo? Cercheremo di capire,
basandosi sulla parte di capacity management e planning dei sistemi tradizionali, quali sono le problematiche e perché
si vede la transizione sulle piattaforme Cloud; in più cosa cambia quando faccio performance tuning o performance
assessment su cloud
Che scopriremo oggi bimbə miei?

• Tutto quello che riguarda failure, fault, error o problemi di resource contention in questi sistemi impatta le
prestazioni e il vero problema è un problema di overload control. Quando parleremo di cloud computing
difficilmente troveremo meccanismi di alto livello di recovery ma solo di meccanismi di prevenzione
dell’overload.

Capacity Planning and management of cloud infrastractures.

Vediamo di capire bene quali sono i fattori importanti e le tre condizioni per le quali sviluppare in cloud è vantaggioso.
Finora abbiamo visto che nel processo di capacity test si applica un workload ad un sistema al fine di individuare i punti
di knee capacity (punto di lavoro ideale) e usable capacity (punto massimo di lavoro). Questi due punti si configurano
con due parametri dipendenti che sono tempo di risposta e throughput.

Ad esempio, come possiamo vedere dal grafico in figura, il server in analisi risulta scarico di notte e molto carico di
giorno. Pertanto, la usable capacity sarà influenzata molto dai picchi massimi (dovuto al carico diurno).
Nella vita quotidiana è difficile perché non ho un carico costante in 24h. Per un web server ci sono dalle 9 alle 21 un
carico alto, e la notte c’è un carico basso. Ciò che accade nei sistemi reali è che il carico non è costante sulle 24, questo
vuol dire che anche se faccio una configurazione in “media” perdiamo delle risorse.
Non abbiamo parlato di un aspetto sui sistemi tradizionali ovvero, della server consolidation. Questo termine va di
moda nel cloud ma non nei sistemi tradizionali ma che vuol dire? Cercare di spostare servizi o server per aumentare
l’uso delle risorse. In un sistema tradizionale non ha senso perché è molto oneroso in termini di configurazione.
Un altro evento che non abbiamo considerato ma che avviene sono gli extraordinary event considerations (Ad esempio
quello che è successo all’INPS durante il primo lockdown).

Se uso servizi terzi per le autenticazioni, non lo includo nel calcolo delle prestazioni. Questo fa sì che ci siano delle
parti non configurate e che impattano sull’affidabilità dell’intero sistema.
Questo effetto che si ha è lo slashdot effect e ad oggi è abbastanza conosciuto e c’è sempre. È difficile trovare un sistema
informativo che non faccia riferimento a sistemi di terze parti.

Slashdot Effect
In cosa consiste l’effetto slashdot? Consideriamo il sito web di repubblica.it e supponiamo che esso presenti un
collegamento a un sito web esterno di piccole dimensioni (non consolidato a ricevere grossi carichi come repubblica).
Supponiamo che ci sia dunque un evento straordinario (un picco di carico vedi figura):
• Repubblica risulta essere consolidato per ricevere grossi carichi di lavoro,
• Si ha un incremento del traffico sul collegamento esterno (sito di piccole dimensioni), causandone un
sovraccarico e un possibile fallimento

Cosa comporta? Ciò determina una perdita delle prestazioni del sito di Repubblica, difatti i threads aperti su
repubblica (Che repubblica riesce a gestire) attendono una risposta dal web server più piccolo, il quale potrebbe
essere fallito a causa del sovraccarico, causando rallentamenti generali.
Non essendo facilmente prevedibili tali effetti, succede che si ha un picco di carico e che i tempi di risposta del sistema
crescano in maniera vertiginosa e il tempo di ripristino delle funzionalità del sistema non è istantaneo.
Quindi, in generale, l’effetto Slashdot si ha quando un sito web di grandi dimensioni (consolidato per grossi carichi) crea
un collegamento a un sito web più piccolo (consolidato per piccoli carichi).
Altro aspetto dei sistemi tradizionali che abbiamo già visto è che noi configuriamo il sistema in maniera abbastanza
statica, attraverso l’intervallo che va dalla knee capacity fino alla usable capacity, e configuro per farlo funzionare in un
certo intervallo. L’intervallo è scelto per fare in modo che il servizio funzioni in maniera affidabile e robusta.

Come si configura un sistema? Analizziamo la relazione tra workload, reliability e availability:

• Se facciamo lavorare un sistema con un workload in prossimità della knee capacity (configured capacity),
allora il sistema lavora bene riuscendo a servire tutte le richieste. Si avrà reliability e availability molto alta.
• Se facciamo lavorare un sistema con un workload in prossimità tra la knee capacity e usable capacity (tra
configured capacity e overload capacity), esso lavorerà bene fino a quando il carico non eccede
significativamente la configured capacity e si avranno richieste che possono fallire. Si avrà availability molto
alta ma non sempre la reliability è garantita.
• Se facciamo lavorare un sistema con un workload oltre la usable capacity si andrà in sovraccarico, ed è chiaro
che il servizio sarà non disponibile e avrà reliability nulla.
In generale, nei sistemi Cloud e nei datacenter, non si può mai andare oltre la usable capacity in quanto tali sistemi
avranno sempre dei meccanismi di controllo del sovraccarico (overload).

Traditional Capacity Planning

Oggi si fa ancora capacity planning dei sistemi tradizionali come abbiamo visto, e sappiamo che è difficile fare
consolidation e non possiamo considerare slashdot effects. Si cerca quindi di acquistare quante più risorse per gestire
la variazione di carico ed essere “elastici”.
Da una decina di anni è nata l’esigenza, di portare alcuni sistemi su infrastrutture Cloud. Ma perché? Perché ha la
caratteristica di elasticità. Ovvero la caratteristica di queste piattaforme di adeguarsi al carico e di gestire e adattarsi
alla richiesta.
La vera novità che ne ha portato all’uso massiccio è che l’utente paga solo per le risorse che userà. Non pago tutto in
base a usable e knee capacity, ma configuro il sistema e alloco le risorse minime. Se il carico cresce prendo più risorse e
in automatico pago di più, se me ne servono meno rilascio e pago meno.
Come fa il sistema ad aumentare le risorse? E come fa a prendere più risorse? Lo vediamo proprio oggi, non siate
impazienti
La rapid elasticity è la caratteristica essenziale di un servizio di cloud computing di attivare risorse addizionali al fine di
fornire tutto il supporto al carico di lavoro e di ritirarlo quando non vi è più la necessità. L’elasticità può essere declinata
in tre modi, data una macchina virtuale posso prendere risorse in che modo?
1. Vertical growth: mantengo le attuali istanze di VM e aumento le risorse e potenzio con più memoria o più disco
2. Horizonatal growth: non potenzio ma istanzio più macchine virtuali
3. Outgrowth: alloco più istanze indipendenti su piattaforme geograficamente distribuite. Come netflix, per
diminuire latenza e jitter dello streaming distribuisco e replico a livello geografico il mio client.

Portare una Legacy sul Cloud non conviene perché al più faccio vertical growth ma comunque è finita sta richiesta di
risorse extra.
Allora mi conviene sviluppare nativamente in cloud, o app multi tenency in cui più organizzazioni condividono la stessa
piattaforma applicativa. Per innescare meccanismi di Horizontal e Outgrowth devo per forza preconfigurare e allora
sviluppo ad hoc per queste piattaforme.
Come si fa a scegliere una capacità nominale in queste piattaforme? E come funzionano in genere?
Nominal Cloud Capacity Model
Comincio a definire inizialmente un punto di capacità, e come faccio? Con le tecniche viste ad inizio corso (in figura il
punto iniziale dov’è scritto “Offered Load). Devo predisporre una capacità addizionale che non pago, ma che il sistema
mi riserva per eventuali crescite di carico (in figura il tratto verticale segnato di rosso). In altri termini io devo progettare
e configurare due tipi di capacità:
1. Engaged online capacity: capacità che uso per il workload che arriva
2. Spare online capacity: è una capacità che viene messa a disposizione solo quando serve. Non pago, ma sta là
quando mi serve. È tutta qui l’elasticità del Cloud

Come si muove e come si adattano le risorse con il carico? Con le tecniche di growth, faccio crescere le istanze o istanzio
VM in altri luoghi.
Iniziamo a vedere questo modello per capirne i pro e i contro. Funziona bene, è elastico ma se tiro troppo si rompe
l’elastico.
Ome avviene fisicamente la gestione di tali risorse? Al di là del tipo di growth che uso, e ricordando che la vertical ha
una saturazione (quindi è molto limitante), tipicamente al crescere di carico alloco nuove istanze. Se ad esempio trovo
che ad un certo punto (quello segnato a destra della figura) ha bisogno di tre istanze di VM, uso la spare capacity che
non è una allocazione continua nel tempo ma discreta, si misura a VM che istanzio.
La capacità, quindi, cresce a gradino e ogni salto è una nuova istanza di VM. Quando ho problemi su latenza e
affidabilità? Quando vado oltre la mia spare online capacity e quindi l’allocazione di un’altra istanza può portare dei
problemi.
Se prevediamo la possibilità di andare fuori dalla spare capacity e se c’è un contratto che me lo permette, quello che
attuerà la piattaforma è di adattarsi all’incremento del carico. Se mi serve altro carico mi dà dell’extra per il tempo che
mi serve e dipende sempre dal tipo di contratto che firmo con la piattaforma.

Il problema fondamentale da affrontare è quindi la possibilità o meno della riconfigurazione della spare capacity.
In generale è sempre possibile di riconfigurare la spare capacity e di assegnarla all’utente che ne fa richiesta, in modo
tale da far fronte anche a picchi di workload anomali.
Domanda esame: Cosa è l’elasticità?
L’elasticità di un cloud è la capacità di far funzionare un server (su cloud) sempre in un punto di lavoro ottimale (ossia
con un trade-off ottimale tra throughput e tempo di risposta). Per permettere ciò si deve avere conoscenza della:
• Risorse assegnate e che vengono effettivamente utilizzate (Engaged)
• Risorse disponibili all’utilizzo (Spare) ossia allocabili mediante tecniche di growth per far fronte a carichi
variabili.
Inoltre, il cloud permette anche di eccedere la spare capacity (Riconfigurazione) per far fronte a eventi e fenomeni
anomali (es. slashdot, etc.).

Spare Capacity
Cosa succede quando andiamo oltre la spare capacity in generale? Il problema reale che percepiamo è quello
dell’overload della piattaforma e allora si devono implementare delle strategie di overload control. L’unico modo che
abbiamo per difendermi, a livello applicativo da fenomeni di anomalie/fallimenti/attacchi DoS, è di integrare nella
nostra applicazione strategie di controllo dell’overload.
Ad esempio, in un sistema VoIP se cresce il carico delle telefonate non accetto chiamate per non corrompere quelle
attive. Oppure in un altro server in cui si vendono biglietti, posso dire che una certa parte faccio drop, quelli che stanno
attendendo da troppo per il pagamento faccio drop e mi tengo le altre.
In tutti gli altri casi l’elasticità funziona bene e non ho alcun tipo di problema. Vedremo che l’elasticità non è proprio la
panacea.
Le aspettative quali sono? Cresce il carico, mi devo adeguare. In elettronica esiste lo slew rate ed è l’abilità di un circuito
di seguire un’onda in ingresso. Se applico un gradino al circuito la risposta non sarà un gradino ma una retta inclinata
perché c’è una latenza nel circuito per seguire l’onda in ingresso. Noi abbiamo la stessa cosa per l’elasticità nel cloud
computing.

Quando noi chiediamo un cambio di risorse abbiamo che il sistema si riconfigurerà, in figura l’ipotenusa è la richiesta
dell’applicazione mentre la freccia tratteggiata è il tempo di configurazione della piattaforma, il cateto “time axis” è il
tempo di latenza della piattaforma per adeguarsi al carico.

C’è lo slew rate ma è un parametro che deve essere portato in conto nell’elasticità. Questo perché quando c’è una
richiesta del carico la piattaforma deve adattarsi più velocemente della richiesta di cambiamento. Se c’è un cambio di
workload repentino e lo slew rate è maggiore di quello che offre la piattaforma andràò in difficoltà.
Sostanzialmente lo slew rate è importante ed è la velocità con qui la piattaforma cerca di adattarsi al nostro carico.
Devo avere uno slew rate veloce e come lo ottengo? Dipende da quanto pago. Mostriamo i 4 livelli di contratto con
ODCA, nonostante sia vecchiotto anche se bene o male sono simili al giorno d’oggi. I livelli sono Bronze, Silver, Gold e
Platinum.
Bronze è economico e mi dà una pillola di elasticità e uno slew rate molto lento perché da una crescite del 10% in 24h
oppure 25% in un mese.
Il Platinum che mi dà? La capacità è la più alta e riesce ad adeguarsi al 100% in massimo in due ore e al 1000% cresce in
un mese, con una serie di penalities se non disponibile quando richiesto.

Managing Online Capacity

Con quale logica viene gestita la online capacity? Il processo è quella mostrata in figura, non c’è cloud senza monitoring
dell’uso delle risorse e del carico, dopodiché dalle misure effettuate cerco di capire se aumentare o no la capacità
tramite grow o degrow. Abbiamo quindi:
• Un servizio di monitoring che permetta di avere informazioni sul workload e sull’utilizzo delle risorse (capacità)
• Inoltre, c’è bisogno anche di un algoritmo di gestione (come in figura) che sulla base deidati monitorati verifica
se:
o Non c’è abbastanza capacità, si utilizza tecniche di Growth e se necessario riconfigurazione della spare-
capacity
o C’è troppa capacità. Si diminuiscie la capacità a disposizione
o Se non c’è bisogno di cambiare la capacità. Non fare nulla (Pause)
La novità sta nel ramo di degrow, infatti se dobbiamo farlo in un sistema tradizionale non possiamo perché è difficile e
forse non fisicamente realizzabile. Mentre sui sistemi ad-hoc è tutta qua l’elasticità.
Cosa deve essere chiaro? Che bisogna scrivere applicazione che supportano le strategie di crescita e devono supportare
la migrazione di istanze o in altre strutture. Ad esempio, già i database, ad oggi non si usano più i relazionali perché se
devo avere istanze su vari sistemi mi conviene non trasportare pure lo stato del sistema.

Capacity-related Service risks

Andiamo a vedere quali sono i RISCHI e i PUNTI DEBOLI su cui dobbiamo pensare e PRENDERE DECISIONI IN
PIANIFICAZIONE.
L’overload è il principale rischio legato alla capacità delle applicazioni tradizionali, rendendoli vulnerabili quando vi è
un carico di lavoro superiore alla engineered capacity. Nelle applicazioni che supportando la rapid elasticity abbiamo
che teoricamente non sono vulnerabili all’overload tradizionale. Nei casi in cui lo slew rate è elevato o vengono perse e
mal misurate delle risorse ho dei rischi, conseguentemente ho vulnerabilità e posso avere dei fallimenti.
Non si parla di fallimenti e di performance penalty ma di overload e quello che vuole farci capire è quali sono i rischi
associati. Chi fa l’applicazione deve capire che strategia attuare a seconda del tipo di overload che posso avere.
Anche l’elasticità teoricamente è grandiosa, se ho elasticità perfetta mi adeguo sempre al carico e al fallimento. Se
fallisce una VM il tutto porta a perdita di capacità ma che ripristino con spare capacity. Ma il meccanismo non è perfetto.
I cambi di workload sono molto repentini e ho un elasticity failure quello che posso perdere con questo fallimento è la
capacità o incrementare una latenza del servizio.
Quando accade un fallimento? Vediamo la figura.
Se il carico cresce (indicato da “offered Load” nell’immagine di sinistra), e non c’è fallimento, l’infrastruttura con nuove
VM fa una funzione a gradini e segue il carico. Questo è il comportamento NOMINALE. A meno che non abbia fenomeni
di slashdot vale quello detto a comportamento nominale
Il problema è quello a destra dove se il carico cresce ho fallimento. Il carico cresce in maniera repentina, la struttura non
segue (vediamo la parte tratteggiata sulla destra) e ho un fallimento. Che vuol dire? Impatto la latenza o vado in Out
Of Service. Diciamo anche che tutto si può esprimere con overload, ma queste situazioni in cui la variazione di carico è
così repentina che la mia piattaforma non riesce a seguire, si ha quando ho dei fallimenti. Sostanzialmente quando
accade ciò ho un vuoto di capacità e ho una parte di carico scoperta.
Devo stare attento che le variazioni di carico non siano così veloci da compromettere il mio sistema.
Il modello di fallimento di questa elasticità è di overload o di reliability e avilability.
Ci sono molti casi come Amazon etc dove il problema fondamentale è l’overload.

Vi ho detto che questo caso qua (dell’immagine precedente) tipicamente lo tengo quando ho un fallimento. Che succede
quando ho un fallimento (caso con carico costante)?
Che perdo una certa capacità e fallisce una istanza e che succede? Che fallisce in un tempo molto piccolo e in un certo
momento ho capacità e lo slew rate segue il fallimento tutto a posto, ma di solito non lo è. Ma se lo slew non segue
subito ho un periodo in cui attivo dello VM nuove e il sistema va in overload.
Questo comportamento si ha nei casi di fallimento delle VM.

LEZIONE 31 09/12/21
Oggi parleremo di Field Failure Data Analysis cioè dati di fallimento sul campo, e vedremo le tecniche di misura diretta
basata sulla storia passata del sistema, sono molto usate anche a livello industriale. Ad esempio, quando ho un problema
all’auto l’operatore si collega alla centralina della macchina e ne scarica i dati, poi dai log con l’aiuto di un DB centrale
cerca di capire quale potrebbe essere il problema facendo un matching tra i log e i dati nel DB.
Sono tecniche molto usate in automotive e anche nel contesto dei datacenter e anzi lì si usano tool ancora più complessi.
L’esercitazione di domani è un passo fondamentale per i sistemi di monitoraggio e trattamento dei log, ma
approfondiremo i sistemi di intrution detection i quali correlano dei log per rilevare minacce ed attacchi.
Le tecniche che vedo oggi sono usate in un sacco di contesti, soprattutto in quelli di security. Vediamo che cos’è l’FFDA
(Field Failure Data Analysis)

FFDA (Lec_IE_DEP5_FFDA)
L’FFDA (Field Failure Data Analysis) è una tecnica di data analysis relativi ai fallimenti degli impianti di elaborazione. In
particolare, l’obiettivo della FFDA è quello di misurare gli attributi di dependability del sistema quando sottoposto a
workload reali.
Cosa vuol dire fare una misura diretta di un sistema? Vuol dire monitorare il sistema, registrare degli errori così come
accadono durante il workload e poi fare data analysis. Questa è una tecnica di misura molto precisa e si raccomandano
utilizzi di safety monitor nel sistema, questo è il miglior modo per capire l’esatta reliability del mio sistema. lo vedremo
dopo che queste sono tecniche che si applicano ad uno specifico sistema e sono difficili da generalizzare.
Sono molto usate in campo automotive come F1 e sono un grande campo di ricerca applicata di soluzioni che vengono
poi messi in commercio.
L’affidabilità delle vetture di F1 è migliorata grazie ai dati di telemetria e solo nel 2015 circa 30.000 parametri hanno
iniziato ad essere monitorati.
Perché si fanno analisi dei dati sui fallimenti e perché queste misure dirette? Perché trovare e identificare in un sistema
tutti gli errori e i fallimenti con una certa severità è difficile. Abbiamo visto quant’è difficile l’hazard analysis.
Il modello dei fallimenti cresce nel tempo, si studiano si analizzano e si rimodellano; quindi, l’FFDA in primis è una tecnica
molto utile per identificare nuovi errori e fallimenti del sistema al fine di classificare ed arricchire i modelli già esistenti.
Ad esempio, se una macchina arriva dal meccanico e nella repository non vi è quel guasto quello che fa, una volta
scoperto il guasto, è risolverlo e aggiornare la repository.
Un modello che quindi si arricchisce nel tempo. Ovviamente, se possibile, si effettua un modello statistico di questi
problemi e si cerca di inferire un modello empirico di reliability.
La FFDA è fondamentale per trovare la correlazioni tra fallimenti e workload del sistema, infatti, se un workload è
molto stressante può aumentare, verosimilmente, il numero di fallimenti e quindi studio eventuali correlazioni tra
workload e fallimenti.
Oltre a quanto detto prima l’FFDA consente di modellare meccanismi di ripristino e trovare Root causes of outages,
ovvero trovare le cause di un eventuale fallimento e che possano essere usate per capire i depenability bottle neck
(ovvero quei componenti che portano ad avere una affidabilità minore in un sistema complesso), in questo modo
possiamo determinare l’affidabilità di tutti gli altri componenti. Nei componenti in serie abbiamo visto che se un
componente aveva reliability minore allora tutto il sistema aveva reliability minore a causa sua.
Infine, se ci ricordiamo ad inizio corso, dicemmo che sia se uso modelli analitici sia che uso misure dirette devo fare
sempre cross validation. Un metodo per fare cross validation, o avere modelli più attendibili, è comparare parametri di
questo modello con parametri che ho preso sul campo.
Se le probabilità di transizione di una catena di Markov le stimo attraverso misure dirette sul campo ottengo un modello
più realistico. Come anticipato ad inizio lezione le tecniche sono potenti e spesso ci si fa prendere la mano e non sono
facilmente generalizzabili e quindi è difficile mostrare una significatività statistica in generale.

1. Il primo obiettivo della FFDA è quello di classificare errori e fallimenti che si manifestano nel sistema,
identificandone la severity (gravità) e la correlazione tra essi. In altri termini, la FFDA è utile per ricavare un
modello che descrive le modalità di fallimento e i meccanismi di recovery del sistema.
L’FFDA cerca però di arricchire tale modello grazie ad un processo di refinement:
• Si registrano le tracce di fallimento
• Si identificano le cause dei fallimenti
• Grazie a feedback successivi si trovano ulteriori tracce
2. Analizzare la distribuzione dei fallimenti e dei relativi recovery time sviluppando modelli di fault prediction
per effettuare manutenzioni predittive.
3. Analizzare la correlazione tra fallimenti e workload del sistema
4. Modellare il comportamento che porta al fallimento e i meccanismi di recovery
5. Identificazione delle Root causes of outages e indicazioni delle dependability bottlenecks
6. Fornire immagini utili per la validazione o per popolare failure models simulati
Nonostante i numerosi vantaggi, l’FFDA presenta anche diversi limiti, come:
1. Le tecniche di FFDA sono sempre “customizzate”, ossia sviluppate ad-hoc per il sistema che si sta misurando
(es. i risultati ottenuti applicando l’FFDA ad una Ferrari non può essere utilizzata per una Mercedes, in quanto
sono sistemi molto diversi). Per questo motivo, è sbagliato cercare di generalizzare i risultati ottenuti da una
FFDA su un determinato sistema ad altri sistemi.
2. Inoltre, le condizioni sotto cui il sistema è osservato con la FFDA possono variare anche da una installazione
all’altra dello stesso sistema (vi sono innumerevoli fattori che possono incidere), inficiando così sulla validità
statistica dei risultati ottenuti. Per questo motivo, per ottenere risultati statisticamente significativi, le analisi
svolte in una campagna di FFDA devono necessariamente avere un lungo periodo di osservazione (tipicamente
anni) e dovrebbero essere condotte su più sistemi, ciascuno in lavoro sotto diverse condizioni ambientali.
3. L’ambito di studio della FFDA è limitato ai soli fallimenti che si sono manifestati, e quindi quelli che possono
essere effettivamente tracciati.
Attenzione che vuol dire che le misure non sono facilmente generalizzabili? Che certe volte per le misure è difficile
dimostrare che ci sia significatività statistica in generale.
Ha fatto un esempio spartano con una lancia Y che mi sono perso per un micro lag.

FFDA metodologia generale

Il processo di FFDA è il seguente: Cosa vuol dire fare una misura diretta di un sistema? Vuol dire monitorare il
sistema, registrare degli errori così come accadono.
1. Data logging & collection
2. Data filtering and manipulation
3. Data analysis

Partiamo da dei dati grezzi (raw data), si parte da essi e si cerca di effettuare delle analisi statistiche che siano
ovviamente significative (quindi con P-value bassi). Mi servono le statistiche per capire quali attacchi siano veri o quale
fallimento sia vero. Questa freccia, che porta da raw data ad analysis result, è complessa e consiste di un processo
d’analisi e il mining dei dati.
Ma che tipo di dati possiedo? Tanti dati, posso avere anche dati ridondanti o parti non di interesse. Nei log non ho
solo errori ma posso anche avere info verbose o altre cose; quindi, devo filtrare dai dati solo quello che è di nostro
interesse. E questo non è facile. Spesso sono giga e giga al giorno e per un normale filtering non bastava un portatile
potente ma serviva un supercalcolatore.
Si usano tecniche di filtraggio che si basano su de parametrizzazione dei dati che possono essere:

• black list, dove elimino dai miei dati quello che non mi interessa.
• white list, più usate e prendo solo quello che mi interessa.
• Term weighting, prendo i dati che posseggono un certo termine
• Etc

Che ottengo a valle del filtraggio? L’output è un blocco di dati che mi interessa (errori e fallimenti) e ho filtrato via
tutto quello che non mi interessa. Ad esempio, su 20 GB lui filtrava via 19,5GB e otteneva un file utile di 500MB.
Questo file ha ancora un problema, sono entry si legate a fallimenti ma possono essere ridondanti. Se in una rete ho
un errore sul time server o sul DNS esso si propaga in più nodi e anche all’interno di un nodo, se c’è Il kernel panic, ad
esempio, verranno inviati dei messaggi di kill a tutti i processi e noteremo nei file di log tipo 200 msg di errore di
processi; ma questi sono derivanti da una sola manifestazione, quindi filtro i ridondanti e manipolo per ottenere file
ancora più snelli.
Le stesse tecniche sono applicate a security measure.
Se devo parlare della reliability, ricordo che si misura empiricamente dando un fitting del mean time to failure. Se ho
più entry e ho tante entry relative ad un solo fallimento ho la necessità di compattarle in un solo fallimento.
Dopo di che, ci concentriamo sulle tecniche di de-parametrizzazione white listing, passiamo poi a tecniche Time Based
per fare analisi empiriche legate ad affidabilità ed TTF e quindi compattare dati con algoritmi di coalescenza per fare
misure di reliability e security.
Decliniamo il tutto nel nostro caso e vediamo di stimare l’affidabilità del nostro sistema.

Data logging & Collection

La prima cosa è raccogliere i dati ma da dove li raccolgo? Lo stabilisco io. Dove metto le sonde? In un sistema ci sono
già le sonde e siamo noi che dobbiamo decidere come e cosa collezionare.
Dobbiamo studiare il sistema e capire cosa voglio raccogliere. In questo caso sono adottate due tipi di tecniche:
• Failure reports, generati dai system amministrator quindi generalmente umani e contengono:
o Tempo e data di fallimento
o Descrizione del comportamento di fallimento osservato
o Il componente hardware/software deputato come responsabile
o L’azione di recovery intrapresa
o Se possibile, la causa root del fallimento
• Event logs, sono i log prodotti in automatico dal sistema (inteso come SO e tutte le sotto parti sw e di rete)
I failure reports, così definiti, dipendono dagli operatori i quali in un sistema complesso devono essere molti. Un
sistema complesso produce tanti fallimenti quindi gli operatori o sono sovraccarichi o in molti casi i failure reports
sono incompleti.
Per fare un paragone con la security ho che questo tipo di azioni, dove ho intervento umano che verifica il manifestarsi
di un evento anonimo, si chiamano SOC security operation centers. Ci sono persone che aiutate da tool automatici
cercano come risolvere eventuali incidenti.

Alcuni sistemi non complessi, per evitare il problema dell’intervento umano, generano failure report automatici! Sono
quasi sempre generati dai SO e gran parte dei SW. Un approccio che forse oggi va per la maggiore, soprattutto con le
tecniche di security, sono gli event logs ovvero log prodotti direttamente dai componenti.
Un log è una linea in un file con timestamp + descrizione evento + tipo di componente che l’ha segnalato e la tipologia
di evento. Qual è il loro limite? Che si produce  si è rilevato qualcosa o si è effettuato qualcosa.
Il log deve avere una certa coverage che non sempre è alta al 100%, questo perché mi sto affidando al sistema che
deve rilevare un certo fallimento.
Un esempio di log è quello che si chiama “syslogd”. Queste sono std in UNIX ed esistono altri tipi come std per il
reporting di eventi. Per quanto riguarda un log normale (ancor) c’è il time stamp, da dove proviene, che cosa è
successo (descrizione evento). Cosa loggare lo configuro io!

Configuro in “SYSLOGD” un file dove nelle varie cose gli dico anche che verbosità deve avere! E che messaggi loggare.
Siamo noi a decidere la severità con cui loggare.
Data Filtering
Abbiamo visto come raccolgo i log ora devo capire come fare filtraggio dei dati. Prima abbiamo visto che posso usare
black e white list; con black scarto quello che non mi interessa perché assumo di già sapere cosa non mi interessa, con
il white mi prendo dal file solo quello che mi interessa.

Se so cosa più mi interessa rispetto a quello che non mi interessa, uso white list. Attenzione che non è così semplice
fare white listing, nella pratica si realizza una de-parametrizzazione per cercare di ridurre la dimensione del mio log
al fine di costruire un dizionario di possibili errori nel mio log. Guardiamo la figura:

Quindi Deparametrizzazione (Costruisce un dizionario → white list → log filtrato)

L’operazione di de-parametrizzazione consiste nell’individuare, in maniera iterata, quali sono le variabili in questa riga
e sostituirli con una riga generale. Costruire un dizionario vuol dire costruire un file con queste righe che sono pattern
del log, i quali servono per effettuare il file di white listing.
Un punto fermo è che la white list è più usata e non si può costruire un dizionario in maniera precisa se non c’è
intervento umano.
A cosa serve il dizionario? Il dizionario può essere quindi analizzato dall’esperto del dominio (Obiettivo del filtering
raggiunto: Si concentra l’attenzione su un numero ridotto di informazioni) il quale cerca di capire il significato di ogni
riga e stabilisce quali sono gli eventi di interesse.

Dopo che ottengo il log finale posso veramente iniziare a lavorare.

Manipolazione - COALESCENCE
Ho in input un log filtrato con tutte le entries che ci interessano ma come si riduce la dimensione del log? Ci sono
tante tecniche che tendono a ridurre la dimensione dei log, le abbiamo viste ad inizio corso in altri contesti, come il
clustering e la PCA. In questo contesto ha rilievo la coalescenza che cerca correlazioni:
• Temporali
• Spaziali (stesso termine)
• Basate su termine
Tutte le correlazioni sono da cercare all’interno di un file, quest’ultimo ha un timestamp e la ridondanza delle entry
dovuta al fallimento è costituita da più entry per lo stesso fallimento. Questo può derivare sia a causa della vicinanza
temporale o dalla propagazione tra nodi.
La coalescenza temporale, o tupling, è un euristica che ha l’obiettivo di rilevare dati con relazioni temporali. Si
riferisce a più entries di una sola manifestazione, vado quindi a costruire una TUPLA legata al fallimento e quel
fallimento lo trovo in quelle entry. Uso la tupla per contare una sola volta il fallimento e avere un conteggio più
realistico dell’affidabilità

Come funziona il tupling? Ho un guasto ed esso può essere propagato in più parti del sistema, questi errori sono
rilevati da parti di sistema differenti che lo scrivono nei log e questi errori vanno in un log file. In un log file ho
elementi multipli legati alla stessa manifestazione.
Un po’ di terminologia, alcuni errori possono essere latenti perché non rilevati, unreported se rilevati ma non
riportati
Come si fa a compattare i dati? Se due entry adiacenti hanno una distanza temporale minore di W aggiungo le due alla
tupla, oppure ne creo una nuova. La formula è semplice.

Questo algoritmo non è perfetto perché se W è troppo grande ho delle collisioni e in una tupla metto fallimenti
diversi! Se W è troppo piccola un fallimento sarà compreso in diverse tuple e quindi le più entry verranno spalmate su
più tuple, questo effetto è chiamato troncamento (truncations)
Non voglio né collisione né truncations, perché qual è il loro effetto sulla reliability ? Se ho una collisione e quindi più
fallimenti messi in una stessa tupla la reliability sarà maggiore di quella reale perché sto vedendo la situazione
ottimistica, dunque le collisioni sono pericolose. Mentre le truncations sono pessimistiche e da previsione di reliability
minore.
Allora come trovo un buon valore di W per minimizzare i due “errori”? Si effettua un analisi di sensibilità, plotto il
numero di tuple sull’asse delle Y in funzione della coalescenza della finestra temporale.

La curva è tipicamente ad L, nella parte a destra della curva ho che a grandi aumenti di W ho piccoli abbassamenti
del numero di tuple; questo vuol dire che sto facendo molte collisioni. Se vado su finestre temporali piccole ad un
piccolo aumento ho una grossa diminuzione del numero di W.
Il punto di equilibrio è intorno al ginocchio e fornisce un minimo di errori di collisioni e di truncation. Vedremo come
fare per trovare questo punto.
Posso declinare la coalescenza temporale su sistemi composti da più nodi e così facendo si parla di coalescenza
spaziale che è utile per sistemi distribuiti. Sostanzialmente si tratta di applicare un algoritmo di coalescenza temporale
a log che provengono da più nodi, questo serve per identificare tracce di propagazione dei fallimenti tra un nodo e
l’altro.
DOMANI FACCIAMO QUESTO NELL’ESERCITAZIONE.
La coalescenza basata sul termine è quella che cerca correlazioni tra le entries di un log con analisi di similitudine
delle righe e si chiama content based coalescence.
Una volta finita questa si può passare ad effettuare l’analisi dei dati.

Data analysis - FAILURE CLASSIFICATION

Dopo aver filtrato e manipolato i dati, si ottiene una directory di file, dove ogni file è una tupla. Si può ora passare alla
analisi dei dati, la quale consiste in analisi statistiche sui dati manipolati al fine di identificare dei trend e valutare
misure quantitative. Lo scopo è categorizzare tutti i fallimenti osservati sulla base della loro natura e/o posizione.
Cercare di fare fitting dei tempi a fallimento può essere molto interessante non solo per avere un modello di quella
che è la reliability ma anche per vedere la tipologia dei fallimenti
Nota per gli homework: L’obiettivo della FFDA è trovare una distribuzione teorica (e i valori dei suoi parametri) che
descriva bene la reliability empirica.
Tipicamente ad ogni distribuzione esponenziale, normale o di Weibull posso fare delle osservazioni rispetto al tipo di
fallimento.

• Distribuzione esponenziale

La distribuzione esponenziale ha due caratteristiche, la prima è memory-less (senza memoria) e ha un failure rate
(hazard rate) costante. Tipicamente si ha tale distribuzione in caso di fallimenti semplici (di componenti elettronici, di
una interfaccia). Tuttavia, si vede che spesso non fitta ai dati reali, soprattutto quando i dati implicano molteplici
cause. Ciò è dovuto alle caratteristiche di senza memoria e al failure rate costante.

• Distribuzione Lognormale

Quando ho fallimenti log Normali tipicamente è indice di un fallimento software. Il comportamento lognormale sorge
quando il valore di una variabile è determinato dalla moltiplicazione di molti fattori aleatori.
In letteratura, tale tipologia di distribuzione è stata associata ai fallimenti software in quanto si è verificato che, la
maggior parte delle volte, essi hanno un andamento del genere. Infatti, i guasti del software sono complessi poiché
determinati da processi e da cause differenti (per cui non andrebbe bene quella esponenziale)
• Distribuzione di Weibull

Nel caso di distribuzione di WEIBULL si possono descrivere fallimenti con memoria di componenti elettronici, ed è
quella più usata perché tratta fallimenti complessi. Ovviamente anche qui a prescindere dal fattore di forma
(fallimento di HDD si fa con Weibull. Un HDD si scassa un poco alla volta fino alla morte).Sul fitting non si dilunga, sono
i soliti test che abbiamo fatto e vediamo meglio domani.
Distribution estimation and GOF test (Goodness of Fit)
La famiglia di distribuzione da utilizzare e i suoi parametri devono essere stimati sulla base dei dati raccolti.
Dunque, vengono condotti test statistici di Goodness-of-Fit (GOF) al fine di verificare se la famiglia di distribuzione
scelta “ fitta “ bene i dati. Esempi di test di GOF sono:
• Kolmogorov-Smirnov (Anticipo: è un test non parametrico che indica se due distribuzioni provengono dalla
medesima popolazione o no.)
• Cramer-von Mises
• Anderson-Darling
Sono test piuttosto robusti all’overfitting ma comunque è un problema che si deve tenere in considerazione.
Ultimo obiettivo di quest’analisi è trovare parametri per popolare modelli simulativi.
In molti contesti (soprattutto nei sistemi critici) si hanno a disposizione modelli simulativi formali che descrivono il
comportamento della dependability del sistema. I modelli più adottati sono macchine a stati finiti, fault trees, catene
di Markov, reti di Petri.
Tipicamente essi sono modelli parametrici (es. si ha il failure rate, la probabilità di locazione del fallimento, etc.), dove
i parametri sono tipicamente stimati sulla base dei dati reali.
Vediamo un esempio

A partire dall’osservazione dei dati reali, il sistema ha mostrato quattro stati:

1) stato in cui è UP
2) stato in cui fallisce con fallimento F1
3) stato in cui fallisce con fallimento F2
4) stato in cui è manualmente ripristinato (MR)
In particolare, entrambi i fallimenti possono essere ripristinati automaticamente con probabilità 𝑝𝑅 .
Se il ripristino dal fallimento F1 o F2 fallisce, allora il sistema va in MR (con probabilità 1 − 𝑝𝑅 ).
Quindi si deriva la catena di Markov in figura, la quale modella i fallimenti e il modello di ripristino. Realizzare un
modello del genere è piuttosto banale, mentre è difficile stimarne i parametri attraverso una misurazione sul campo.
VEDIAMO UN CASO DI STUDIO REALE
Stack bluetooth dove ho un livello baseband che fa il time divison multiplexing per un primo controllo sulal
trasmissione, tipicamente si fa un controllo FEC ed altri check di integrità. Poi ho un protocollo che fa livello di
management che fa inquiry e scan. Come se fosse Datalink di ISO/OSI
C’è poi un livello di “rete” che fa segmentation e riassembly con multiplexing sui canali ed è L2CAP
Poi ho un service discovery e un BNEP che fa una simulazione ethernet. E poi ho le applicazioni.
Che raccolgo qua? Log di applicazioni e log dei moduli dello stack protocollare bluetooth e poi log del sistema di rete.
Quindi ho tre tipi di logs per capire per bene dove sono possibili degli errori.
Il testband si effettua con dei client bluetooth e un server per i log.

Quando c’è un infrastruttura del genere i log viaggiano su una rete diversa rispetto a quella su cui gira il sistema.
Anche se questo non è sempre vero.
Sui workload automatizzati se ne sono fatti diversi, come quello random o realistico.
Ma vediamo i risultati per capire come sono stati classificati:
• Failure classification:
o Su ogni log di livello utente, di livello sistema e canale si riportano tutti i fallimenti ed una volta
classificati si chiede se c’è propagazione
la correlazione la si ottiene attraverso la coalescenza, si prendono i due log e li si ordina in base ad un algoritmo di
ordinamento merge sort poi si effettua una sensitivity analysis ed in finse si effettua il tupling.

La tupla non è banale, consente anche di ricostruire i modelli di propagazione

Gli ultimi cinque minuti di lezione finisce di riportare la spiegazione dell’esempio del bluetooth.

LEZIONE 32 10/12/21
Oggi presenteremo l’ultimo homework ma non è il meno importante. Il contesto di oggi è quello in cui esaminiamo il
funzionamento di super calcolatori e applichiamo le tecniche viste ieri di logging e audit.
Vedremo diversi tool ma non sempre l’effort che usiamo per configurarli vale il tempo e il risultato dei risultati fatti a
mano.

Data Driven Analysis (FFDA_Training)

Log testuali e dati numerici prodotti dalle applicazioni, sistemi e IDS sono delle risorse fondamentali per:
• Caratterizzare i fallimenti
• Predire i problemi
• Focalizzarsi su degli attacchi alla sicurezza
• Migliorare il sistema

Ma non tutti i dati sono gli stessi, e lo vediamo con la data cost / value matrix che purtroppo tutti trascurano ma è di
fondamentale importanza.

Da una parte abbiamo i costi per prendersi dei dati (l’effort) e in azienda si paga con lo stipendio, mentre per l’asse
delle ordinate c’è il valore dei dati ovvero l’efficienza del loro utilizzo. Quando usiamo strumenti molto complessi
dobbiamo puntare alla massima efficienza, quindi trovarsi sul lato alto a sinistra.
L’audit è quando rilevo un fallimento e faccio uno studio sui dati ma a scatola nera, questo perché ci fidiamo dei dati
che vengono forniti e non possono essere ripudiati. Il processo di audit serve per certificare quanto successo e quando
ci spostiamo nel campo della security c’è il passo in più della security audit che mi garantisce lo stato delle informazioni.
Se vediamo lo studio seguente possiamo osservare tutte le tracce, di cinque minuti, di un datacenter Mercury.

Lo studio fu effettuato per capire chi fosse e chi attuava credential stealing.
La nostra esercitazione consisterà nel condurre un log-based FFDA di un sistema complesso e su larga scala, i dati sono
reali e raccolti da:
• Mercury
• BlueGene/L
All’esame se ce lo chiede i dati sono già filtrati e vi è stata già fatta una whitelist.
Quali sono gli obiettivi? Li abbiamo visti ieri ma ripetiamoli:

Ovviamente sono parecchi dati e bisogna controllare il processo. Vediamo un attimo un overview dei dati e poi partiamo
con gli esempi.
In Mercury tg-master abbiamo il punto di ingresso e poi sono presenti tre diversi nodi: login, computation e storage. Il
simbolo 𝑋 indicava il numero di nodi.

Ma come sono realizzati gli event log?

Gli errori mostrati nei log sono quelli mostrati di seguito.

L’altro super calcolatore è BG/L il quale risulta essere già un buon sistema, è formato da 600mila processori e ogni
processore è numerato all’interno di un rack.
I log che ci vengono forniti sono circa 125.624 e l’abbattimento è mostruoso visto che inizialmente erano 20 GB.
Tools usage and sample analysis
Che cosa ci serve per fare un minimo di esercitazione? Uno script bash

Quanti fallimenti ci vengono forniti? Tutti i fallimenti dei due sistemi, ma ci farà vedere adesso un sample su un file più
corto “MercuryErrorLogTEST”. Lo stesso problema è riportato diverse volte nel log e le entries che sono potrebbero
essere associate dallo stesso problema devono essere raggruppati o coalescenti

Ricordiamo che il problema è quello di avere un guasto che porta a diversi errori e gli errori possono essere riportati
dai log. Dobbiamo quindi capire, in questo caso, che tutti gli errori provengono dalla stessa manifestazione.

Determinare la finestra di coalescenza

La prima cosa da fare è determinare la finestra di coalescenza e la conoscenza temporale, questo lo facciamo
attraverso un’analisi di sensitività ovvero vedere la curva del numero di tuple al crescere della finestra temporale. È
una curva tipicamente a forma di “L” e bisogna prendere il punto di knee.
Lo script, se applicato ad un test ci mostra le finestre temporali delle tuple. Più è lento a calcolarle più tuple ci saranno,
se è veloce il contrario e poi vorrà sapere la distribuzione delle entry sulle tuple e perché ci sono degli errori che si
propagano e altri no.
Il problema di aver scelto una finestra temporale rispetto ad un’altra qual è? Questo di seguito è l’output delle tuple
con tre valori, ovvero dello script precedente:
• tuple lengths,
• interarrivals , sarebbero i tempi a fallimento
• timestamps of the init point of tuples

La finestra temporale è importante perché mitiga le truncations e le collision.

Le truncations indicano che entry , relative allo stesso fallimento , sono state divise in due tuple diverse. Questo causa
una misurazione della reliability pessimistica.
La collision invece raggruppa entry che sono relative a fallimenti diversi nella stessa tupla, è quindi una previsione
ottimistica.
Vediamo l’esempio, la tupla 4 ha lo stesso codice “tg-c238” con la tupla 5 e differiscono solo per una distanza
temporale. Se la finestra temporale è comparabile non ha senso dividere le due tuple e quindi potrebbe avere senso
considerarne una sola.

Per le collision ho dei problemi diversi, immaginiamo di avere il log con delle entry e supponiamo di avere 3 nodi; nel
nostro log (parte alta dell’immagine) abbiamo che questi eventi sono raggruppati un una sola tupla. Ci chiediamo, ma
sono delle collisioni? Possono esserlo se (in riferimento all’immagine) nel fulmine sul nodo 3 si è verificato un errore e
anche sul nodo 1 ed abbiamo raggruppato in alto due entry che sono derivanti da errori diversi.

L’assunzione fatta è che siano due errori diversi, ma non è detto. Infatti, potrebbe tranquillamente essere che l’errore
nel nodo 1 si è propagato fino al nodo 3 e quindi la tupla è corretta. Il mio compito è verificare la reale esistenza di
questa collisione attraverso lo studio delle tuple del sistema.
In particolare, per l’esame a lui interessa che abbiamo trovato e notato qualche truncation e collision sulle due
macchine. Nell’esempio della tupla 61 abbiamo molti eventi che potrebbero essere correlati e che generano collisione
o truncation.

Reliability modelling
Come facciamo a fare una curva empirica TTF? Non ci vuole molto, sostanzialmente ce l’abbiamo
Per la parte di analisi da fare ci dobbiamo rifare a questo:

Supponiamo di osservare un fallimento di memoria ed uno di I/O, le finestre temporali per la coalescenza sono
diverse? Si, soprattutto se le dinamiche di errore sono diverse, infatti, un errore hardware è molto più lento di uno
elettronico.
Questo serve per vedere tutte le finestre temporali con dinamiche diverse.

Homework finale
L’esercizio alla fine consiste in questo:
LEZIONE 33 10/12/21
Oggi ci sarà una lezione che è un po’ un’introduzione alla sicurezza ma per chi fa il corso di cybersecurity sarà ripetizione
tranne che per l’esempio sui sistemi SCADA.
Finora nel corso abbiamo parlato di sicurezza associata alla dependability, ovviamente nel tempo questo tipo di
definizione si è espansa da sola.

Introduzione alla sicurezza

Per definizione di computer security prendiamo quella del NIST (NATIONAL Institute of Standards and Technology) che
è un ente americano che si occupa di standard. Si differenzia dall’ISO solo perché è gratuito.
La definizione data è: “L’impiego di protezione per un automated information system al fine ti ottenere la preservazione
dell’integrità, availability ed confidenzialità delle risorse di un sistema informativo”
Quindi tutti quegli sforzi che facciamo in un sistema informatico per preservare le proprietà CIA (confidentiality,
integrity, availability) o meglio dette computer security triad.
Confidentiality
“Chi è autorizzato ad usare I dati?”
Preservare l’accesso ad informazioni attraverso la restrizione degli accessi e non divulgazione. Questo significa
proteggere la privacy personale e la proprietà intellettuale delle informazioni, una bassa confidenciality può
degenerare in una divulgazione non autorizzata di informazioni.
Ad esempio, la lettura di un contatore Enel o la lettura di alcuni parametri di un sistema deve essere possibile solo da
personale specializzato ed autorizzato, attraverso un access control list.

Integrity
“I dati sono validi?”
Preservare lo stato delle informazioni da una modifica impropria o distruzione, questo include l’autenticazione delle
informazioni e il non ripudio. Una perdita di integrità è la modifica di informazioni o la distruzione in maniera non
autorizzata

Availability
“Posso accedere ai dati ogni volta che ne ho bisogno?”
È il concetto che abbiamo già visto nell’affidabilità di un sistema. In questo caso è la disponibilità dei servizi ad utenti
autorizzati.

Ulteriori concetti
Vi sono poi due ulteriori concetti aggiuntivi oltre ai tre visti, questi due sono:
• Autenticità: la proprietà dei dati di essere genuini e quindi non essere alterati da qualcuno che non li ha
realizzati.
• Accountability: è mandatoria nei sistemi medici ed indica la possibilità di tracciare le azioni effettuate su un
sistema da una specifica entità del sistema.
Vulnerabilities, Threats and Controls
Un concetto importante per la sicurezza sono gli assets ovvero quei valori importanti per l’azienda che se
compromessi o persi ho dei danni economici, e che ovviamente vogliamo proteggere.

La sicurezza è come l’affidabilità e anche qui dobbiamo capire la differenza tra guasti e vulnerabilità. Ovviamente in
sicurezza chi effettua un attacco procurando dei guasti, è più intelligente di un guasto che può avvenire in maniera
accidentale su un sistema ma sostanzialmente è questo il contesto. La gestione degli assets è una questione di
investimento, perché bisogna sempre valutare in che modo e cosa proteggere e se l’investimento vale la spesa.
Infatti, la prima cosa che fa un esperto di sicurezza è la valutazione degli assets, tutti gli standard lo richiedono.
Quali sono i valori di un assets?
Gli assets possono essere:

• off the shelf, recuperabili ad un certo costo

• unique e non riparabili.

Ora cerchiamo di capire i termini base per poter affrontare questa tematica:
• Vulnerabilità
• Threat
 • Attack
• Contromisure o controlli di sicurezza.

Una vulnerability è una debolezza del sistema, come ad esempio una procedura o un’implementazione, oppure di
configurazione. Questa debolezza verrà poi sfruttata per fare danni, un bug può essere una vulnerability? Sì, se può
essere sfruttato per fare danni. Non è detto che un errore sia direttamente sfruttabile.
Le vulnerabilità a delle volte possono anche derivare da un insieme di difetti, attenzione però che se anche
progettiamo un sistema seguendo tutte le metodologie ingegneristiche studiate non saremo esenti da errori ma ne
diminuiremo la probabilità.
Il processo di usare una vulnerability per creare danni al sistema è chiamato attacco, ma quindi che cos’è? È l’exploit
di una vulnerability per compiere azioni non ortodosse al sistema.
Una minaccia è un insieme di circostanze che possono favorire un attacco.

Ma quindi come possiamo fronteggiare delle situazioni del genere? Si attuano delle misure protettive come i security
control che tentano di rimuovere o ridurre una vulnerabilità. Quindi una minaccia è bloccata attraverso il controllo di
una vulnerabilità.

Access control
Un tipo di security control è proprio l’access control, il quale definisce delle policy (politiche) di accesso a risorse
aziendali. Una politica è definita come la somma di who + what + how e queste regole devono essere declinate anche
nel mondo reale, non solo nel mondo informatico.
Si potrebbe pensare che l’attaccante sia il classico tizio dietro il pc con il cappuccio alzato, ma non è più così da anni,
ormai esistono interi gruppi criminali e delle volte anche sponsorizzati dagli stati i quali hanno accesso a risorse super
avanzate.

Security threats
Per fare threats analysis e di conseguenza il modelling abbiamo bisogno di fare una classificazione delle minacce:
• Interception, l’attività di intercettare dati e prenderne possesso
• Interruption, i cosiddetti DoS (denial of service) dove si interrompe un servizio
• Modification, il processo di modifica dei dati o processi
• Fabrication, fabbricazione di dati o processi impuri

Tutti questi threats si declinano in base al tipo di assets, sia esso hardware/software o data
Ad esempio, un attacco hardware può essere anche il provocare un incendio oppure rubarselo ma non solo questo
tipo di attacchi anche quelli che vanno a modificare proprio l’accesso a determinate zone di memoria kernel
Ma se l’hardware vulnerability può essere confinata a determinate aziende quella che può colpire tutti è la data
vulnerabilities, essi infatti non sono più solo file elettronici ma un insieme di informazioni sensibili quali:

• Stipendi
• Dati medici
• Atti privati
• Personali
• Etc

In una nostra applicazione sarà proprio nostro compito capire quali sono i nostri dati sensibili e che se rubati
provocano una perdita delle proprietà CIA. Anche qui dobbiamo capire qual è il grado di severity di un attacco ai
nostri dati.

Software vulnerabilities apre un altro mondo e può essere declinato in:

• Software deletion
• Software modification
• Software theft
Nel corso di software security si approfondiscono questi tipi di attacchi ma per adesso diremo che esistono tecniche di
analisi statica e dinamica per attuare delle contromisure, ma hanno un costo così elevato che si preferisce usare i cicli
di vita ed analisi del software.

Quando dobbiamo affrontare un problema di sicurezza dobbiamo sempre fare affidamento sulla mamma (si lol è un
inside joke). Infatti, un attaccante avrà sempre bisogno di tre cose: metodo, opportunità e motivo.

Se andiamo a vedere com’è protetto un sistema reale abbiamo la perfetta analogia con un castello: un unico punto di
accesso, protezioni esterne ed interne, etc.
A fine lezione (1:18:30) fa vedere Stuxnet che è stato uno dei primi virus a mettere in ginocchio interi paesi. Si tratta
di un sistema di raffreddamento per sistemi Siemens SCADA di una centrale termoelettrica che ha subito un attacco
informatico per i quali non sono stati attivati i sistemi di raffreddamento (gli attacchi davano misure false di valori di
temperatura) e quindi è scoppiato tutto. L’attacco informatico utilizzava 4 zero-day vulnerability, cioè vulnerability
non ancora note e per cui non ci sono ancora patch. È stato realizzato per attaccare un insieme di sistemi SCADA.

Secure data analysis

La cybersecurity non offre una protezione completa e perfetta. A supporto di questa troviamo la secure data analysis,
che trasforma i dati rilevati nella consapevolezza di situazioni in cui vi deve essere security. Cosa fa?

• Tramite la compilazione, l’elaborazione e la fusione di dati effettua dei technical view point
• La capacità umana di comprendere implicazioni e trarre conclusioni per effettuare decisioni (cognitive
viewpoint)
Il sistema di controllo SCADA è simile a questo mostrato di sotto, ad oggi è ovviamente più complesso. I compiti
principali di un sistema del genere sono:
• Acquisizione dati
• Comunicazione dei dati sulla rete
• Presentazione dati/ avvisi
• Controllo
LEZIONE 34 16/12/21
Business Continuity and Disaster Recovery
La definizione di disastro la recuperiamo dalle lezioni precedenti per quanto riguarda l’hazard analysis ma entrambi i
due termini sono abbastanza esplicativi, e vogliono indicare in che modo continuiamo a mantenere attivo il nostro
business aziendale e qual è il piano di recupero in caso di disastro.
Ma per sicurezza rivediamo la definizione di disastro: “Un incidente causato dalla natura o dagli umani che influenza
negativamente le organizzazioni o l’ambiente”, se guardiamo le grafiche abbiamo modo di capire di come l’uomo sia la
causa della maggioranza degli eventi ed ovviamente, sarà nostro compito cercare di diminuire il più possibile la
probabilità di tali eventi. In più avremo il compito di velocizzare anche il recupero dell’operatività in caso di disastro
stesso.
Mentre la definizione più formale per business continuity abbiamo: “L’abilità di un’azienda di continuare ad operare
con il minimo disfunzionamento o con un basso tempo di recupero a seguito di un disastro”. Per molti anni questo
business continuity lo si aveva in forma cartacea e non era obbligatorio, ma da diversi anni è divenuto mandatorio.

Ma quali sono gli effettivi danni per la quale abbiamo bisogno di una business continuity? L’immagine di seguito è
abbastanza esplicativa, e come possiamo notare copre moltissimi aspetti. Le perdite possono essere sia dirette che
indirette, ad esempio una perdita indiretta potrebbe essere quella della fama dell’azienda oppure una diretta
potrebbe essere la diminuzione dello stipendio.

Ma perché quest’operazione non veniva fatta? Prima di tutto perché richiede personale competente e non è di facile
realizzazione, in più perché costa infatti la business continuity pyramid ci mostra numerose fasi insieme alla sua
complessità. La Farnesina, ad esempio, è obbligata a seguire queste procedure per tutti gli interventi che deve
eseguire
Come si realizza un Business Continuity Plan?
La creazione del Business Continuity Plan viene guidata dalla piramide del Business Continuity Program come se fosse
un processo aziendale.

Ma come va tarato un business recovery plan? Quando succede qualcosa abbiamo una finestra di interruzione che è
definita come il tempo che intercorre tra il punto di fallimento e la ripresa del servizio. In questa finestra il servizio non
viene ovviamente fornito, dopo di che tentiamo di recuperare il minimo funzionamento con il piano di disaster
recovery. Questo piano non è istantaneo e serve per garantire i servizi minimi e questa situazione è chiamata
alternate mode.
La Disaster Recovery è una attività che coinvolge i processi, le politiche e le procedure necessarie per il ripristino delle
attività e la continuazione delle funzioni critiche di un'organizzazione dopo un disastro.
Gli obiettivi di tale attività sono:

• Limitare gli effetti dei disastri sulle funzioni aziendali

• Riportare l’azienda a uno stato operativo normale.
• Minimizzare l’occorrenza di certi tipi di disastri nel futuro.
Dopo un certo periodo nel quale si lavora in modo alternato bisogna effettuare un restoring dei servizi. Questa
finestra è chiamata maximum tolerable outarage ed è il massimo tempo per cui io riesco a tollerare un outage del
mio sistema, chi lo calcola? Noi progettisti/ingegneri.
Ma come si può fare un ciclo di business continuity plan? Non è molto differente dai sistemi safety critical visti
durante il corso:
1. Identify: da effettuare dopo le valutazioni del rischio (Risk assessment) nel quale categorizziamo il rischio per
i disastri.
2. Analyze: Business impact analysis perché devo capire rispetto al rischio qual è il mio impatto sul business. Se
ad esempio mi si allaga la fabbrica ed mi si rompono i macchinari forse riesco ancora per un po’ a lavorare,
ma se mi si allaga l’amministrazione io non posso più gestire nulla.
3. Design: Strategy selection
4. Execute: Plan and Mitigation Strategy Development
5. Measure: Plan Testing and Maintenance

Nel dettaglio, soffermiamoci sulla fase di Business Impact Analysis. Tale analisi cerca di rispondere alle seguenti
domande:
• Quale dei processi di business sono di importanza strategica?
• Quali disastri potrebbero occorrere?
• Quali impatti potrebbero avere questi disastri sull’organizzazione finanziaria dell’azienda? Oppure che impatti
a livello legale/sulle vite umane/sulla reputazione
• Qual è il periodo richiesto per il tempo di recupero?
Event Damage Classification
I danni vengono classificati in base ad una precisa nomenclatura:

• Negligible: Nessun costo o danno significante

• Minor: un evento non insignificante con nessun impatto sull’aspetto finanziario o materiale dell’azienda
• Major: Impatta su uno o più dipartimenti e potrebbe impattare con i clienti all’esterno dell’azienda
• Crisis: Un evento che ha un forte impatto sui materiali o l’aspetto finanziario dell’azienda.

Gli ultimi tre devono essere in ogni caso documentati per informare, di conseguenza, su cosa fare e per tenere traccia
dell’evoluzione degli eventi.

Con tale matrice si descrivono gli eventi a criticità maggiore attraverso il quale si costruisce un Disaster Recovery Plan
(DRP).

Disaster Recovery Plan

In cosa consiste un piano di disaster recovery? Ovviamente è composto da tre arre:
 • Prevenzione (prima di un disastro): La attuiamo rendendo sicuri i sistemi vulnerabili e bisogna proteggere i
sistemi salvaguardando i dati importanti, si usano tutte quelle misure che evitano un danno all’aziende. Non
tutto è sempre prevedibile come, ad esempio, un terremoto ma possiamo prevedere un fallimento di
sistema.
• Continuità (Durante un disastro): Continuare ad erogare le operazioni critiche le quali permettono all’azienda
di funzionare correttamente.
• Recupero (Dopo un disastro): Ripristinare tutti i sistemi e le risorse per il funzionamento regolare.

È importante capire che queste sono strategie di business non tecnici. Netflix, ad esempio, ha avuto successo in Italia
perché ha investito nel posizionamento dei server negli autonomous system, diversamente da disney e dazn che
invece si sono affidati ad un modello di business normale richiedendo ai provider della banda per erogare il servizio.

Developing recovery strategies

Entriamo adesso più nel tecnico e vediamo il suo core, ovvero i metodi di backup. Ottenere una copia di tutti gli
archivi del sistema è fondamentale ma per farlo ho bisogno di un sito di backup e di una strategia di backup , ovvero
come faccio il backup? Online con un cloud service? Oppure lo faccio “Cold” senza collegamento ad Internet.
Un’altra considerazione può essere: Se perdo il sistema chi me lo sostituisce? Devo recuperare solo i dati o tutto?

Una Disaster Recovery Plan (DRP) deve rimanere affidabile e consistente in caso di un disastro, per testare un piano si
attua una combinazione di:
• Scenario di test
• Trasferimento di sistemi in un sito alternativo, questo permette di verificare che il sistema torni operativo
entro una particolare finestra temporale
• Spiegazione strutturata, al fine di esporre errori o mancanze che si avrebbero senza l’uso del DRP e costo
associato al test completo
Backup
Il backup è la strategia principale di recovery e in generale consiste in una copia addizionale dei dati che possono
essere usati per lo scopo di ripristino e recupero. La copia creata può essere non solo dei dati, ma anche di
funzionalità.
Generalmente il sistema di backup ha due procedure:
1. Salvataggio
2. Recovery o restore

Per decidere una strategia di backup, quando entriamo in un’azienda e ci viene chiesto di farlo, dobbiamo rispondere
alle seguenti domande:

Possono sembrare banali, ma ad esempio una TAC di un ospedale se fatta ad alta risoluzione occupa fino ad 1 TB. Le
metodologie dietro ad un backup sono tre e sono:
• Mirrored disks: Esatta copia bit a bit di tutti i dati su un device fisico, viene conservato in maniera separata e
mantenuto sincronizzato.
• Snapshots: Contiene un set di marcatori che puntano ai dati salvati su un dispositivo
• Continuous Data Protection (CDP): Salvano automaticamente una copia di ogni cambiamento

Anche la granularità può essere differente ed importante da tenere in considerazione, sono due i tipi disponibili:
 • Differenziale, vi è un full backup ad ogni giorno prefissato della settimana ma solo una volta a settimana
• Incrementale, anche qui vi è l’aggiornamento ad una sola settimana ma i cambiamenti registrati sono fatti in
base alle differenze con il giorno precedente.

Dal punto di vista del backup, qual è il migliore per la banda? È quello incrementale.
Quindi la differenza è che i backup differenziali parte dalle differenze rispetto all’ultimo FULL backup del sistema e di
conseguenza un maggior uso della banda. Dal punto di vista del recovery è molto più robusta. Il backup
incrementale è più efficace ma per il restore necessito di tutti i dischi e quindi ho meno robustezza.

Tecnologie di backup
Vediamo una breve panoramica sulle tecnologie per capire in che modo esse vengono effettuate. La prima che
vediamo è quella a nastro che nonostante si pensi essere una tecnologia vecchia ed obsoleta, in realtà trova moltissimi
impieghi e con diversi vantaggi.

Ad esempio, i file system con allogazione contigua sono super veloci e comodi per poter effettuare accessi sequenziali.
I nastri sono organizzati in rack e sono organizzati con strati software che permettono di accedere e salvare via rete.
Per la gestione dei rack possiamo immaginarci la stessa identica gestione che avviene per i jukeboxes, ovvero
attraverso un sistema di rotazione dei nastri. Uno dei metodi e detto five to five dove i nastri vengono ruotati giorno
per giorno tranne che per due giorni.

Se vogliamo avere anche backup mensili c'è un'ulteriore schema: Grandfather – father- son
Poi ci sono i più disparati metodi matematici per migliorare le performance di salvataggio, come il metodo della torre
di Hanoi:

Un esempio di azienda che si occupa di fare backup è Microsoft con Azure, nelle slide del prof ci sono alcune
informazioni a riguardo ma non le reputo più di tanto interessanti.
Gli ultimi 10 minuti di lezione sono solo sulla legge di come gestisce la questione dei backup.