3. Few highlights on learning outcomes
Sia RTA che empirismo mostrano una grossa differenza tra i due approcci. In RTA, TSP ha sempre valori più bassi e "crolla" molto presto. Gli esperimenti di XU & Burns partivano da utilizzazioni di 1.6, un valore già alto per il mondo TSP. In empirismo, le differenze di utilizzazione sono nette.
Per capire i grafici dell'empirismo bisogna spiegare cosa sono gli MCS green e orange moment (didascalia fig. 11 dell'articolo).
Credo che faccia capire velocemente quanto il conservatorismo (high watermark + safety margin) sia un approccio "punitivo" e che non si presta bene all'arricchimento di funzionalità SW a meno di incrementare l'HW (con i dovuti problemi tecnici e di approvvigionamento).
Nel grafico sotto si vede come tasksets ampi falliscano l'esecuzione a causa dell'esaurimento del loro budget. (Ricordo che abbiamo calibrato l'utilizzazione reale di ogni task tra il 70-90% di quella nominale). Avere tanti tasks implica, con DRS, che ognuno di essi abbia budget molto basso in termini assoluti. L'utilizzazione reale è il 70-90% di esso. Questo implica che se un task ha budget di 4.8 millisecondi (il minimo), il suo tempo di esecuzione può arrivare (su carta) fino a 4,32 millisecondi (lo scarto è inferiore ai 500 microsecondi). Noi calibriamo il tempo di esecuzione di un task in maniera sisntetica. Con tempi così stretti, basta poco per sbagliare questa calibrazione. Se poi il taskset è ampio, la probabilità di avere sbagliato (essere stati imprecisi) su almeno un task si alza.
Un sistema con tantissime tempistiche molto strette è difficile da gestire: troppo probabile aver calibrato in maniera non sufficientemente precisa almeno un task. Si poteva fare meglio questa calibrazione? Può essere, ma gli altri 3 esperimenti mostrano sempre una curva Budget Exceeded molto più contenuta.
Per noi il problema aveva due dimensioni. Generare un insieme di tasksets:
- unbiased
- con iperperiodi controllati e contenuti, così da evitare test empirici con durata di mesi/anni.
Ha praticamente fatto tutto Perale in realtà.
Nel documento di Tesi, i risultati presentati erano basati su RTA (per MCS) senza considerare l'overhead del runtime. Nell'articolo finale, invece, la RTA presenta questa raffinazione. Di seguito, i risultati dell'esecuzione di tasksets reali (marcati schedulabili secondo la RTA) sul target HW per la RTE Platform.
Risultati empirici costruiti su una RTA raffinata con l'overhead della piattaforma RTE.
Risultati empirici costruiti su una RTA raffinata senza l'overhead della piattaforma RTE.
Gli andamenti Actually Schedulable (tasksets che sono stati dichiarati schedulabili dalla RTA e che lo sono anche durante l'esecuzione sull'HW) e Deadline Missed (tasksets che sono stati dichiarati schedulabili dalla RTA ma che hanno mancato una deadline durante l'esecuzione sull'HW) sono ben diversi (Si notino i diversi intervali presi sugli assi x).
N.B. se un taskset è stato dichiarato schedulabile dalla RTA, ma poi durante l'esecuzione reale manca una deadline (curva arancio, Deadline Missed, allora la RTA non è stata abbastanza precisa.
Da questo ho imparato che la valutazione empirica di una RTA non può prescindere da un suo raffinamento con l'overhead della piattaforma reale.