FACOLTFACOLTÁÁ DI INGEGNERIA DI INGEGNERIA

CORSO DI LAUREACORSO DI LAUREAINGEGNERIA INFORMATICAINGEGNERIA INFORMATICA

Progetto e Sviluppo di un Algoritmo di Scheduling per il

Sistema RTAI

Candidato:Luca Marzario

SommarioSommario

Motivazioni Obiettivi Architettura del sistema RTAI Implementazione Test Conclusioni

MotivazioniMotivazioni

Applicazioni interattive e multimediali Quality of service

Sistemi operativi general-purpouse (Windows, Linux, ...) non offrono garanzie temporali

Sistemi operativi real-time troppo costosi non offrono supporto adeguato alle applicazioni

multimediali e interattive

Caratteristiche di LinuxCaratteristiche di Linux Linux non è un sistema operativo real-time Possiede molte caratteristiche che ne fanno un

ottimo sistema operativo:

robusto e affidabileampio supporto di processori

e periferichenetworking avanzatostrumenti di sviluppo e dubugginginterfaccia graficaampia disponibilità di software

Linux e Real-TimeLinux e Real-Time

Linux non possiede le caratteristiche tipiche dei sistemi real-time:determinismo (prevedibilità)possibilità di preemtionspecifica vincoli temporaliprogrammazione “fine” del timer

RTAIRTAI Real-Time Application Interface (RTAI)

Affianca a Linux un kernel real-time Schedula Linux come idle task

Vantaggi Buone prestazioni real-time per i task RTAI Sistema di sviluppo basato su Linux

Problemi Starvation di Linux in caso di alti carichi

real-time Crash del sistema in caso di errori di

programmazione o malfunzionamenti

SoluzioniSoluzioni

Implementare un algoritmo di reservation su RTAI Riservare banda di utilizzo del processore a ogni task

Tempo minimo di esecuzione garantito Protezione del sistema da errori di

programmazione o malfunzionamenti

Schedulare Linux con il CBS Shell di comandi sempre attiva Minor tempo di risposta delle applicazioni Linux

Real Time Application Interface (RTAI)Real Time Application Interface (RTAI)

Sistema real-time che permette l’esecuzione di applicazioni tipo hard real-time

Fa parte dei progetti Linux Real-Time

Questo tipo di sistemi si definisce “real time executive”

Solo il kernel real-time ha il pieno controllo dell’hardware

Principali sistemi: RTAI e RTLinux

real time executive

hardware

Linux Task 1 Task n

RTAI vs RTLinuxRTAI vs RTLinux

Prestazioni offerte paragonabili. Interfacce di programmazione (API) molto simili RTAI è meno intrusivo rispetto a RTLinux:

Maggiore mantenutibilità Più facile aggiornamento delle modifiche kernel Linux

RTLinux open-source non è più mantenuto RTAI costantemente aggiornato

Ultima versione di RTAI rilasciata il 23 settembre 2002

RTAIRTAI

Costituito di moduli da inserire nel kernel Linux precedentemente modificato

Moduli principali Gestore interruzioni

(interrupt dispatcher) Scheduler

Moduli aggiuntivi FIFO shared memory POSIX etc.

Task Real-Time

Gest. Interr

Scheduler

FIFO

Shared Mem

POSIX

RT task

kernel

Linux

modificato

LinuxTask

Applicazione RTAIApplicazione RTAICostituita di due componenti

Meccanismi di comunicazione fifo scambio di messaggi segnali memoria condivisa ...

TaskRT1

RTAI

TaskRTn

TaskRT2

Linux

P1

P2

Pk

Real-time (acquisizione, elaborazione, controllo etc.) eseguita da task RTAI (real-time)

Non real-time (visualizzazione, tracing etc.) eseguita da processi Linux non disturba le attività real-time

RTHALRTHAL

Attivazione RTAI modifica dei puntatori dell’rthal

Linux disable interrupt

RTHAL disable interrupt

Hard disable

Soft disable

Disattivazione ripristino dei puntatori alle funzioni originali di Linux

Modifiche kernel Linux Linux perde il controllo diretto dell’hardware

RTHAL

hardware

Linux Task 1 Task n

RTAI interrupt dispatcherRTAI interrupt dispatcher

RTAI dispatcher

Salva registri

rtai handler? rtai handler

Linux in esec?

Linux handler

Linux handler?

interruzionependente

Ripristina registri

SchedulerScheduler Architetture supportate

monoprocessoremultiprocessore

Politiche di schedulingPrioritario SempliceRate MonotonicEarliest Deadline First

Gestione del Timermodalità periodicamodalità one-shot

Resource reservationResource reservation

Ogni task ha riservato un tempo Q ogni periodo T

Processi hard real-time e soft real-time possono convivere

E’ possibile riservare una frazione del tempo macchina a Linux

Il Constant Bandwidth ServerIl Constant Bandwidth Server

Resource reservation tramite CBS (Constant Bandwidth Server)

Basato sul TBS e DSSRispetto al TBS non richiede WCETRispetto al DSS migliori prestazioni

Algoritmo CBSAlgoritmo CBS Ad ogni task viene associato un server schedulato

con EDFcapacità massimaperiodo

Ad ogni istanza servita dal server viene associata una deadline dinamica

Durante l’esecuzione la capacità viene decrementata. Una volta esaurita, viene ricaricata al suo valore massimo e la deadline viene posposta (diminuzione priorità)

Applicazione di provaApplicazione di prova

Linux P1

RT3

RT2

RT1

FIFO

Frequenze jitter con CBS

0102030405060708090

100

-6 -5 -4 -3 -2 -1 0 1 2 3 4 5 6

jitter (ms)

Frequenze jitter senza CBS

01020

30405060

708090

-6 -5 -4 -3 -2 -1 0 1 2 3 4 5 6

jitter (ms)

ConclusioniConclusioni

Risultati ottenutiDiminuzione dei tempi di risposta delle

applicazioni LinuxGaranzia di schedulazione di Linux anche in

caso di grossi carichi real-timeMaggior controlloMaggiore robustezza