linux user group brescia

immagine del castello

Archivio della mailing list

Luca Giuzzi giuzzi a dmf.bs.unicatt.it
Mar 16 Nov 1999 15:26:49 UTC
Da quello che posso immaginare ti servono sistemi "hard real time", i.e. con
latanza di interrupt molto bassa. Una premessa va fatta subito: ethernet
 non e' realtime in quanto non garantisce la qualita' del servizio e possono
 avvenire collisioni fra pacchetti che richiedono la ritrasmissione dei dati;
 se vuoi una LAN "real time" probabilmente la soluzione migliore e' ATM
 [supportata dal kernel, ma piuttosto cara]. Token ring [si'... esiste ancora]
 o FDDI sono forse delle opzioni intermedie che potrebbe valere la pena
 considerare in quanto garantiscono che la macchina col `token' e' l'unica
 autorizzata a trasmettere e evitano in tale modo lo scontro di pacchetti...
 il problema potrebbe pero' essere la latenza [i.e. il dover attendere che
 il token arrivi alla macchina che deve parlare] ... tutto dipende dal tipo
 di applicazioni che ti interessa implementare.

Riguardo il real time: il kernel di linux prevede la possibilita' di avere
 diversi schedulers in funzione concorrentemente e due di essi sono 
 classificati come "real time" e sono basati su algoritmi di round robin (uno
 di essi) e di FIFO (il secondo). Sostanzialmente consentono di avere una
 priorita' piu' alta per alcuni processi rispetto quella che avrebbero con
 lo scheduler normale, ma resta il problema degli interrupt: possono andare
 bene per masterizzare su di una macchina carica ma non li consiglierei ove
 sia essenziale avere tempi di risposta inferiori al millisecondo!

Rimane la soluzione di usare dei kernels speciali appositamente disegnati per
 il RT; c'e' un prezzo da pagare pero' ed e' che la applicazione real time non
 puo' usarei direttamente i servizi standard (non real time) del kernel mentrei
 e' in funzione e, al contempo,
 puo' facilmente bloccare il sistema
 se non si decide a ripassare il controllo al kernel... il vantaggio e' che
 quando l'applicazione in oggetto non sta elaborando dati e' comunque
 possibile usare le funzionalita' standard di linux per processare le 
 informazioni raccolte.

Che io sappia ci sono almeno due progetti degni di nota a questo proposito:
 RT-Linux (vedi a http://www.rtlinux.org) e
 RED-linux ( http://linux.ece.uci.edu/RED-Linux/ )

Il progetto RED-linux parrebbe orientato all'user space e al multimedia
 piuttosto che all'impiego di strumentazione scientifica, sebbene ad occhio
 sembri piu' semplice da impiegare...
 
 ...RT-Linux promette una interfaccia di libreria `posix-like' ed e'
 sostanzialmente un nuovo scheduler a valle del kernel stesso... la latenza
 promessa si aggira sui 30 microsecondi ed e' possibile accedere ai dati
 da linux stesso tramite delle FIFO (sostanzialmente ci sono dei devices ove
 il processo real-time presenta i suoi risultati). Personalmente mi sentirei
 di raccomandare questa soluzione per la acquisizione di dati da strumentazione
 di laboratorio...

Ciao,
 lg



Maggiori informazioni sulla lista Lug