Re: real-time
On Thu, Jul 18, 2002 at 09:44:33PM +0200, Daniele Nicolodi wrote:
> On Thu, Jul 18, 2002 at 09:32:46PM +0200, Francesco Paolo Lovergine wrote:
>
> > Differenze sottili o stato di obnubilimento del sottoscritto ... :)
>
> Che cosa e` l'obnubilimento ??
Non so...
> > Le funzioni sched_ ci sono ma con i limiti di un sistema time-sharing
> > non rt... C'e' scritto nelle note delle funzioni. A propos,
> > POSIX.4==POSIX.1b
I limiti non sono dovuti al time-sharing ma alla risoluzione massima del sistema
ed alla gestione delle attività di nucleo che hanno comunque precedenza
sugli eventuali processi di tipo «real-time».
Le limitazioni che dici tu e che sono riportate in fondo alle pagine di man
di sched_setscheduler() sono:
Standard Linux is not designed to support hard real-time
applications, that is, applications in which deadlines
(often much shorter than a second) must be guaranteed or
the system will fail catastrophically. Like all general-
purpose operating systems, Linux is designed to maximize
average case performance instead of worst case perfor
mance. Linux's worst case performance for interrupt han
dling is much poorer than its average case, its various
kernel locks (such as for SMP) produce long maximum wait
times, and many of its performance improvement techniques
decrease average time by increasing worst-case time. For
most situations, that's what you want, but if you truly
are developing a hard real-time application, consider
using hard real-time extensions to Linux such as RTLinux
(http://www.rtlinux.org) or use a different operating sys
tem designed specifically for hard real-time applications.
che appunto fanno riferimento al fatto che Linux è un sistema non
hard real-time ma bensì soft real-time. In pratica Linux permette la
definizione di task (o processi) di tipo soft real-time per i quali
quindi non è data nessuna garanzia sulla terminazione entro la propria
deadline (o scadenza). In pratica i processi Linux possono anche
eseguire oltre la deadline cosa che non accade invece per i sistemi
hard real-time.
Linux mette a disposizione del programmatore alcune primitive che
permettono di avere un maggiore controllo sulla schedulazione dei
processi, come ad esempio la schedulazione FIFO o FIFO Round Robin,
cosa che non hai se usi la schedulazione di tipo time-sharing. Hai poi
anche la possibilità di eliminare lo swap della immagine del processo
per evitare ritardi non desiderati nell'esecuzione del task.
Tutte cose che servono ad aumentare la prevedibilità del sistema,
caratteristica basilare di ogni buon sistema real-time che si
rispetti.
> Visto che ti trovo ferrato in materia non e` che riesci a spiegarmi
> che soluzioni adotta RTLinux per diminuire la latenza ?? Da quello che
> ho capito io dopo il boot il kernel diventa un processo qualsiasi e
> lascia quasi del tutto il controllo ad un processo che e` appunto
> il processo che si desidera realtime. Questo processo non viene
> interrotto se non quando possibile senza ostacolarne la temporizzazione
> (pool, select, ecc...). Tu puoi dare maggiori dettagli e/o correzioni ??
Con RTLinux o RTAI l'intero sistema Linux viene visto come un task
real-time a più bassa priorità. In questo modo si ha la possibilità di
avere una gestione ben precisa dei task real-time e poi, quando avanza
tempo, si esegue Linux.
Così facendo non si fa altro che eliminare tutte quelle «attività di
nucleo» a cui accennavo prima e che non fanno altro che aumentare la
non prevedibilità del sistema.
Rodolfo
P.S. Molti mi riprendono perché ho il vizzietto di chiamare il
«kernel» con il corrispettivo italiano «nucleo». Comunque si capiva
no? ;-p
--
Programs and GNU solutions e-mail: giometti@linux.it
Linux Device Driver giometti@ascensit.com
Embedded Systems home page: giometti.oltrelinux.com
UNIX programming phone: +39 329 7028903
--
To UNSUBSCRIBE, email to debian-italian-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: