Newsgroup: it.comp.os.linux.sys
Titolo: Scheduler e real-time

Salve a tutti,
dovendo realizzare un'applicazione real-time, stavamo pensando di
utilizzare RTAI.
Prima però di "perdere" tempo nella comprensione del funzionamento di
RTAI, e nella traduzione del software per questo sistema... vorrei
chiedere se qualcuno è a conoscenza di confronti tra le prestazioni
dello Scheduler presente "di default" nel kernel di linux rispetto
allo scheduler real-time di RTAI. In definitiva, vorrei capire se/
quanto ne vale la pena.
grazie
Lorenzo

 Lorenzo
prestazioni per fare *cosa*? Il Real Time è fatto per rispondere in
brevissimo tempo agli interrupt esterni, per esempio a un segnalatore
di temperatura, e per fare ciò usa una sorta di Super-Scheduler molto
leggero (poche centinaia di righe di codice) che tratta il kernel come
un processo normale (il quale a sua volta fa girare altri processi) e
gestisce gli interrupt in tempo reale con routine molto brevi
(anche qui poche centinaia di righe di codice) create a hoc per la
gestione degli eventi.
Dunque se il sistema deve rispondere nel minor tempo possibile a
stimoli esterni il Real Time è più veloce, in quanto specificatamente
progettato, mentre per normali elaborazioni non cambia nulla o al
limite peggiora le prestazioni.

 limite peggiora le prestazioni.
per me il concetto di Real Time non è legato al fatto di "rispondere
nel minor tempo possibile", ma è legato al fatto di "rispodere in un
tempo deterministico, cioè che è sempre quello".
ciao
Lorenzo

 wrote in news:f770838f-3850-4148-8bc6-
38e3d1...@m44g2000hsc.googlegroups.com
:

un sistema real time e' pensato per garantire un tempo di risposta certo 
agli input.
il kernel di linux (ho visto quello di debian, ma penso non sia molto 
diverso da quello standard) non mi pare abbia uno scheduler pensato per 
raggiungere questo obiettivo.
magari qualche versione particolare, ma il kernel standard non credo faccia 
al caso tuo...
-- 
Paolo opg
BE AWARE that this post uses a fake reply-to address
to contact me write to:
janickg ( at ) hotmail ( dot ) com
--

 deterministico, cioè che è sempre quello".
Il primo si chiama "soft real time", il secondo "hard real time".
Bye.


la differenza tra soft e hard non è legata alle conseguenze di
un'eventuale mancato rispetto dei tempi prestabiliti?
In un sistema hard-realtime il non rispetto dei tempi ha esiti
catastrofici.
O sbaglio?
ciao
Lorenzo

 raggiungere questo obiettivo.
Ho letto in giro che con la versione 2.6 del kernel è stato introdotto
uno scheduler O(1).
O(1), a quanto so, significa che il tempo è costante al variare del
numero di processi attivi.
E' per questo che mi è venuto il dubbio, se fosse effettivamente
possibile garantire tempi deterministici con il kernel senza applicare
patch.
E in questo senso chiedevo se esistono confronti nelle prestazioni.
ciao
Lorenzo

 wrote in
news:b2dc5668-26c3-4f56...@c65g2000hsa.googlegroups.com
: 

anche io avevo in testa che il concetto di real time non fosse legato al 
tempo di risposta in se', ma al tempo *massimo* di risposta. 
magari c'impiega meno del tempo massimo, ma io ho la certezza di qual'e'
il caso peggiore (e nessuna garanzia di tempi inferiori). 
se una risposta mancata e' accettabile, il sistema e' soft.
se una risposta mancata non e' accettabile, il sistema e' hard.
piu' o meno...


 O sbaglio?
Stringi stringi, e` la stessa cosa, vista dall'altro lato. :)
In un sistema critico dovrai usare un S.O. hard RT (se non risponde entro 
tot la centrale nucleare va in fusione), in un computer desktop puoi usare 
soft RT (se non risponde entro tot la musica scatticchia).
Bye.

 E in questo senso chiedevo se esistono confronti nelle prestazioni.
Non ne sono a conoscenza.
Bye.

 wrote in
news:6cjuv2F...@mid.individual.net
: 

il cavillo e' nella definizione di hard rt e soft rt.
per quel che ne so, un sistema con risposte rapide non e' detto sia real 
time.
un sistema e' rt se ha un tempo massimo di elaborazione noto, ma che il 
tempo sia breve non credo sia un requisito per la definizione di rt.
poi un rt hard esige il rispetto di tutte le scadenze di elaborazione, un 
rt soft puo' accettare/gestire il mancato rispetto di alcune scadenze.
ma deve eserci un tempo massimo di risposta noto (non necessariamente 
breve), altrimenti come fai a capire se una risposta e' oltre il tempo 
limite?
all'universita', come esempio di rt hard portavano la catena di montaggio 
di un'auto; i tempi non sono rapidi, se il pezzo arriva in anticipo e 
resta a disposizione, nessun problema, ma se la scadenza non e' 
rispettata (aka il pezzo non c'e' quando devo montarlo), il sistema si 
blocca.
sistema rt hard con tempi non brevi (anche qui, 'breve' e' 
soggettivo...).
vado un po' a memoria, ma m'e' venuta la curiosita' di verificare...


 tempo sia breve non credo sia un requisito per la definizione di rt.
Si`, un sistema realtime deve avere dei tempi dichiarati di risposta agli 
stimoli. Questi tempi possono anche non essere brevi, ma sono determinati.
La differenza tra un softrealtime e un hardrealtime e` che il primo puo` 
sforare questi tempi senza conseguenze, mentre il secondo no.
Credo che stiamo dicendo la stessa cosa ma guardandola da due punti di 
vista diversi ed io mi sono spiegato male nella prima risposta ad L.
Bye.

 dichiarati RT, che avranno quindi precedenza su tutti gli altri.
Quello lo puoi fare anche con le pthread, se sei root e se scheduli i 
processi con priorita` piu` alta degli altri e con tipologia di 
scheduling SCHED_RR o SCHED_FIFO (vedi man pthread_attr_init). Un 
programma che lancia un thread con questi attributi e il seguente body:
void rt_thread() { for (;;); }
...lanciato da root inchioda la macchina :)
Quindi su linux hai la possibilita` di avere processi con priorita` RT 
senza avere bisogno di RTAI o RTlinux, quello che non hai la certezza 
che gli interrupt siano preemptive, in quanto il kernel 2.6, ha ancora 
diverse regioni di codice non premptable, quindi un sistem linux 
"vanilla", pure compilato con l'apposita opzione preemptive, non 
garantisce una risposta in tempo costante ad un interrupt, e quindi non 
puo` essere usato come sistema realtime.
C'e' da dire che tra scheduler a 1000hz, l'apposita opzione del kernel 
per il preemptive e l'implementazione dei thread del 2.6 si puo` di 
fatto utilizzare un sistema linux per compiti realtime non troppo critici :)
Detto cio` in azienda abbiamo diversi progetti che hanno avuto bisogno 
di certificazione realtime e tali progetti che un tempo scrivevamo su 
vxworks ora li scriviamo con RTAI :)
Bye,
  Gabry

 E in questo senso chiedevo se esistono confronti nelle prestazioni.
Forse solo con RT-Linux si trova qualcosa.
bye,
-- 
piergiorgio

 critici :)
Prestando un po' di attenzione, direi che ci si puo`
anche riuscire, certamente.
bye,
-- 
piergiorgio

 partire o meno e` un'altra questione.
mi potresti spiegare meglio cosa intendi?
grazie
Lorenzo




Lo scheduler standard di Linux funziona cosi`: Quando un nuovo processo 
entra in coda, controlla il suo valore di nice, e lo posiziona nella coda 
di esecuzione in una certa posizione (piu` alta se ha nice basso). Durante 
la sua esecuzione verifica quanto e` "simpatico". Se usa tanto la CPU non 
e' molto simpatico, quindi gli abbassa la priorita`, inserendolo piu` 
basso in coda. Se ne usa poca, gli alza la priorita`, portandolo piu` in 
alto nella coda.
Questo a grandi linee, poi ci sono diverse politiche di scheduling.
Quando c'e` un task switching (ogni tot microsecondi), semplicemente 
prende il primo processo della coda e gli passa l'esecuzione (ecco l'O
(1)), mentre il processo che esce dalla coda subisce lo scheduling come ho 
detto sopra.
Linux ha anche altre code di scheduling, tra cui la FIFO e la RR di cui 
parla Gabriele Greco: ogni processo che esce dalla cima della coda va a 
finire in fondo. In questo modo tutti i processi nella coda hanno garanzia 
di essere eseguiti con la stessa priorita`, e non subiscono penalita` per 
il loro comportamento. Inoltre queste code hanno priorita` sullo scheduler 
standard. Se c'e` un processo in attesa su questa coda viene eseguito 
prima di quelli di altre code. Ecco perche` un ciclo infinito rischia di 
inchiodare la macchina.
Tendenzialmente in RR/FIFO ci si dovrebbero mettere solo processi che 
hanno veramente bisogno di questo comportamento, e che eseguono il loro 
compito nel minor tempo possibile, lasciando libera la CPU velocemente. 
Per esempio il gestore del mouse o della tastiera (come sull'Amiga), o un 
programma di masterizzazione che elabora i codici di ritorno del drive per 
evitare buffer underrun (cdrecord), o un server audio che manda i segnali 
alla scheda il piu` velocemente possibile per evitare scatti (pulseaudio, 
opzionalmente), ecc.
Bye.

 mi potresti spiegare meglio cosa intendi?
Allora, esempio.
Diciamo che ci sono 10 processi.
Lo scheduler, per decidere chi deve partire (dopo
un task switch), ci mette 10ms (e` un esempio).
Con 100 processi ci mette 100ms, con 1000 processi
ci mette 1000ms.
Questo vuol dire che il tempo di esecuzione dello
scheduler dipende dal numero di processi che deve
considerare, cioe` lo scheduler ha complessita` O(n),
dove n sono i processi nel sistema.
Un'altra possibilita` e` che lo scheduler ci metta
sempre 10ms, sia con 10, che con 100 o 1000 o 10000
processi. Questo vuol dire che lo scheduler ha
complessita` O(1), cioe` costante al variare del
numero dei processi nel sistema.
Detto cio`, come lo scheduler decida chi deve partire
e chi deve aspettare e` una questione di politica di
scheduling, che puo` essere RT oppure no.
Per esempio lo scheduler potrebbe semplicemente
applicare un round robin e far partire i processi
uno dopo l'altro, senza priorita`.
Il che mette in dubbio il real-time.
Altre politiche sono possibili, ovviamente.
bye,
-- 
piergiorgio