Appunti Impianti di elaborazione

Lezione 1 (27/09/2021)

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.

Cosa vuol dire valutare un sistema?

Valutare un sistema (system evaluation) significa esaminare due aspetti:

• Performance Analysis: analisi delle prestazioni del sistema.
• Dependability Analysis: analisi dei requisiti non funzionali come affidabilità e sicurezza.

Per poter valutare un sistema, dobbiamo prima imparare a effettuare misure e ad analizzare i dati. Questi due aspetti sfruttano un insieme di modelli statistici, design sperimentali, misurazioni, simulazioni e teoria delle code.

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à viene analizzata in fase di assegnazione della commessa e attraverso l’uso di modelli. Quando la parte commerciale fa la proposta di una gara, si cerca di rispondere ai requisiti della stessa cercando di fare un modello per convincere il committente a valutare il sistema.

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 delle quali deve 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 mettere l’ingegneria informatica alla base di tutto.

Principali proprietà da valutare

• 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?”
• 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.

Progettazione e analisi delle performance

Quando progetto 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.

Differenza tra management e planning

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. 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
  • Input per modelli simulati o per regole di tuning, sono dettagliati e per sistemi specifici.
• Planning
  • 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

Definizioni banali

• Sistema: accozzaglia di hardware, software e firmware che effettuano una certa elaborazione.
  • 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.
• Metriche: Criteri per valutare le prestazioni di un sistema (tempo di risposta, numero di richieste per secondo, carico di lavoro)
• Workload: richieste fatte dagli utenti del sistema

Lezione 2 (30.09.2021)

Vediamo qualche esempio per capire cosa dobbiamo imparare a fare durante questo corso.

Primo esempio

Dovremmo comparare prestazioni di sistemi differenti. Comparare due disk, o comparare due algoritmi per trasmissione di pacchetti, sono analisi che comportano metriche di giudizio diverso. Questo significa che le scelte delle metriche dipendono dai tipi di sistemi che dobbiamo andare a comparare.

Si parla di ingegneria di 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.

Valutare la prestazioni implica scegliere una tecnica di valutazione, una metrica e i workloads:

• Tecnica di valutazione
  • 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.
  • 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.
  • Modelli analitici (Teoria delle code): descrivo il sistema attraverso un modello analitico, da usare quando non abbiamo conoscenza alcuna del sistema. La tecnica si allontana leggermente dalla realtà, ma possono essere utilizzati per misurare l’upper bound del sistema; in ogni caso è la più veloce ed economica.
• Metriche: i criteri usati per valutare le performance (es: tempo di risposta, transazioni per secondo)
• Workload: tutto ciò che impongo al sistema (numero richieste, query, carico del sistema, etc.)

Supponiamo che ho due link di comunicazione, link A e link B, e misuro il numero di pacchetti persi per dimensione di file da trasferire. Ad esempio, se ho un file di 1k perdo 5 pacchetti nel link A e 10 nel link B, come si vede in tabella. Quale link è migliore?

Siamo portati a fare una media, e se facciamo una media di questi link, il link B in media perde meno pacchetti del link A. Ma, questa considerazione non tiene conto del workloads: ma se noi non sappiamo come è la distribuzione delle dimensione dei file in questi canali, non sappiamo rispondere.

Non possiamo dire nulla allora se non facciamo ipotesi sul workload: dovrei misurare la percentuale di pacchetti di una certa dimensione e allora potrei fare una media pesata (non aritmetica uniforme) saprei perfettamente la risposta.

Purtroppo, è difficile anche osservando un intervallo di tempo lungo, capire con precisione, quali sono le distribuzioni percentuali dei paramentri di workloads. In ogni caso, è all’infinito che la probabilità di un evento tende all’evento, ma non al finito.

Secondo esempio

Misuriamo le prestazioni di un sistema non in senso assoluto, ma voglio capire quali parametri impattano di più sul sistema. Ho un sistema che usa 3 tipologia di garbage collector (si intende una modalità automatica di gestione della memoria, mediante la quale un sistema operativo, o un compilatore e un modulo di run-time liberano porzioni di memoria non più utilizzate dalle applicazioni), tre tipologie di workload e tre tipologie di CPU.

Tipicamente, questo serve nel caso in cui vogliamo scalare il nostro server: devo aumentare il numero di processori, la memoria, e quindi ho più parametri su cui riflettere e piuttosto che fare esperimenti a caso, si “progettano esperimenti”.

Terzo esempio

Il design measurement è molto importante, così come vengono molto utilizzati gli esperimenti simulati. Per capire in base ai materiali, in base alle condizioni di volo, andiamo a progettare degli esperimenti per valutare dei parametri.

Quarto esempio

Supponiamo che misuro il tempo di esecuzione di un database e il tempo di idle è di 3 secondi, e voglio valutare: Questo tipo di problema viene risolto con modelli analitici: ho un modello che tipicamente ha una soluzione in forma chiusa, ad esempio i modelli a code. OSS: lo Shorts Remaining Time minimizzava i tempi medi e per capirlo è stato utilizzato questo modello a code.

Quinto esempio

Supponiamo di misurare il throughput in due sistemi, A e B: Qual è il sistema migliore? Se comparo le medie, il throughput medio è lo stesso. Se voglio dire quanto A è più veloce rispetto a B: => il sistema A normalizzato rispetto a B è più veloce di circa il 25%. Se normalizzassi il sistema B rispetto ad A, otterrei la considerazione opposta, cioè che B normalizzato è più veloce di A. Un benchmark può dire molto poco se non è collegato al workload tipico del sistema.

Al di là dei numeri, avremo a che fare con sistemi più complessi. Misurare un sistema complesso vuol dire avere misure di questo genere: Ma le cose possono essere più complesse, ad esempio molto oscillante: in cui vediamo una zona di sovrapposizione. Possono complicarsi ancora di più situazioni: non abbiamo un andamento unico, ma possiamo capire che il grafico è diviso in “epoche” (fasce verticali) e studiando queste epoche ci rendiamo conto di come ci sono delle repliche. O in git i tempi: => da quest’ultimo è difficile fare una misurazioni, il che ci fa capire che a noi non servono modelli puntuali.

Se ho due esperimenti, e due tipi di workload che invia 1000 email al secondo e l’altro 900 email al secondo: quale dei due sistemi va meglio? Come si guardano i dati sperimentali? Queste due serie temporali, bisogna capire se differiscono per un fenomeno diverso o in modo casuale: se per esempio voglio fare la differenza dei positivi al covid tra una regione ed un’altra, non posso fare ragionamenti puntuali, perché queste serie sono astrazioni di un campione, e la differenza tra due punti D, questa differenza è casuale o c’è un fenomeno dietro? La prima cosa che ci dovremmo chiedere è come cercare da questa serie temporale, tutta la parte casuale per eliminarla.

Le due serie in figura, sono praticamente uguali dal punto di vista statistico: quando la differenza non è statisticamente significativa non è possibile esprimere nulla perché differiscono per i punti casuali. Quando modello il sistema, non devo modellare la parte casuale.

In questo corso, dobbiamo capire come trattare le curve. Perché è importante nei sistemi di elaborazione tutto ciò? Perché nei sistemi di elaborazione complessi, abbiamo uno stack software con delle sorgenti di non determinismo (interrupt, scheduling): quando abbiamo sorgenti di non determinismo abbiamo una casualità. 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.

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.

Tecniche di valutazione

• Tecniche di valutazione
  • Analytic modelling (teoria delle code)
  • Simulazioni
  • Misure sperimentali
• Metriche di performance
• 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 fuorviante. I costi sono 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:

• Non affidarti ai risultati di una simulazione senza...