3. Few highlights on learning outcomes
Si vede sin da subito una grossa differenza tra i due approcci: 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.
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.