FACOLTÁ DI INGEGNERIA
CORSO DI LAUREA
INGEGNERIA INFORMATICA
Progetto e Sviluppo di un
Algoritmo di Scheduling per il
Sistema RTAI
Candidato:
Luca Marzario
Sommario
 Motivazioni
 Obiettivi
 Architettura del
sistema RTAI
 Implementazione
 Test
 Conclusioni
Motivazioni

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 Linux

Linux non è un sistema operativo real-time
 Possiede molte caratteristiche che ne fanno un
ottimo sistema operativo:
robusto e affidabile
ampio supporto di processori
e periferiche
networking avanzato
strumenti di sviluppo e dubugging
interfaccia grafica
ampia disponibilità di software
Linux e Real-Time
 Linux
non possiede le caratteristiche tipiche
dei sistemi real-time:
 determinismo (prevedibilità)
 possibilità di preemtion
 specifica vincoli temporali
 programmazione “fine” del timer
RTAI

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
Soluzioni

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)
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
Linux
Task 1
Task n
real time executive
hardware
RTAI 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
RTAI

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
Linux
Task
Applicazione RTAI
Costituita di due componenti
 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

Linux
P1
Pk Task Task Task
P2
RT1 RT2 RTn
RTAI
Meccanismi di
comunicazione





fifo
scambio di messaggi
segnali
memoria condivisa
...
RTHAL

Modifiche kernel Linux


Linux perde il controllo diretto dell’hardware
Attivazione RTAI
Linux
Task 1
Task n
 modifica dei puntatori
dell’rthal
RTHAL

Disattivazione
hardware
 ripristino dei puntatori alle funzioni originali di Linux
Linux disable
interrupt
RTHAL disable
interrupt
Hard disable
Soft disable
RTAI interrupt dispatcher
Salva registri
rtai
handler?
Linux
handler?
RTAI dispatcher
Ripristina registri
rtai handler
Linux in
esec?
Linux
handler
interruzione
pendente
Scheduler
 Architetture supportate
 monoprocessore
 multiprocessore
 Politiche di scheduling
 Prioritario Semplice
 Rate Monotonic
 Earliest Deadline First
 Gestione del Timer
 modalità periodica
 modalità one-shot
Resource 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 Server
 Resource
reservation tramite CBS
(Constant Bandwidth Server)
 Basato sul TBS e DSS
Rispetto al TBS non richiede WCET
Rispetto al DSS migliori prestazioni
Algoritmo CBS

Ad ogni task viene associato un server schedulato
con EDF
 capacità massima
 periodo

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 prova
RT1
RT2
RT3
FIFO
Linux P1
Frequenze jitter senza CBS
90
80
70
60
50
40
30
20
10
0
-6
-5
-4
-3
-2
-1
0
1
2
3
4
5
6
jitter (ms)
Frequenze jitter con CBS
100
90
80
70
60
50
40
30
20
10
0
-6
-5
-4
-3
-2
-1
0
jitter (ms)
1
2
3
4
5
6
Conclusioni
 Risultati
ottenuti
 Diminuzione dei tempi di risposta delle
applicazioni Linux
 Garanzia di schedulazione di Linux anche in
caso di grossi carichi real-time
 Maggior controllo
 Maggiore robustezza