Regole del forum
1) Citare sempre la versione di Slackware usata, la versione del Kernel e magari anche la versione della libreria coinvolta. Questi dati aiutano le persone che possono rispondere.
2) Per evitare confusione prego inserire in questo forum solo topic che riguardano appunto Gnu/Linux in genere, se l'argomento è specifico alla Slackware usate uno dei forum Slackware o Slackware64.
3) Leggere attentamente le risposte ricevute
4) Scrivere i messaggi con il colore di default, evitare altri colori.
5) Scrivere in Italiano o in Inglese, se possibile grammaticalmente corretto, evitate stili di scrittura poco chiari, quindi nessuna abbreviazione tipo telegramma o scrittura stile SMS o CHAT.
6) Appena registrati è consigliato presentarsi nel forum dedicato.
La non osservanza delle regole porta a provvedimenti di vari tipo da parte dello staff, in particolare la non osservanza della regola 5 porta alla cancellazione del post e alla segnalazione dell'utente. In caso di recidività l'utente rischia il ban temporaneo.
Leggevo su una rivista di applicazioni realtime... e così mi è venuta voglia di approfondire l'argomento... e fare qualche prova!
Secondo voi devo compilare il kernel con dei moduli particolari o devo installare qualche supporto realtime?
Per applicazioni che non richiedono tempi stringenti secondo voi è possibile utilizzare dei "demoni" che esplicano le stesse funzioni di un applicativo real-time?
Devi scaricare il modulo e ricompilare il kernel con le Security Capabilities e l'estensione per SElinux. Qui c'è un howto: http://ftp-ildp.httpdnet.com/RTLinux-HOWTO, ma leggi il readme del pacchetto. Io ho attivato il realtime per il server audio Jack, su kernel 2.6, e non da problemi, a parte una probabile desincrozizzazione se redirigo l'output da una scheda all'altra, che causa una distorsione del segnale. Penso di aver risolto abilitando l'HW e il SW monitor...
touchstyle ha scritto:Devi scaricare il modulo e ricompilare il kernel con le Security Capabilities e l'estensione per SElinux. Qui c'è un howto: http://ftp-ildp.httpdnet.com/RTLinux-HOWTO, ma leggi il readme del pacchetto. Io ho attivato il realtime per il server audio Jack, su kernel 2.6, e non da problemi, a parte una probabile desincrozizzazione se redirigo l'output da una scheda all'altra, che causa una distorsione del segnale. Penso di aver risolto abilitando l'HW e il SW monitor...
grazie delle info...
L'idea era quella di sviluppare qualcosa su una scheda embedded linux, che dici?
Se uno dovesse leggere delle info ad esempio da un sensore di temperatura messo in terrazza, o comunque un segnale variabile nel tempo non serve qualcosa di real time oppure basta come dicevo un demone fatto su misura?
se devi rilevare delle temperature di una terrazza non penso che farai un campionamento troppo rapido...anche se ne facessi 1 ogni secondo penso che basti e avanzi. La temperatura esterna varia così velocemente.
Il realtime è utile, ma bisogna applicarlo solo quando serve, in un caso come questo penso che non è necessario.
Firetux ha scritto:se devi rilevare delle temperature di una terrazza non penso che farai un campionamento troppo rapido...anche se ne facessi 1 ogni secondo penso che basti e avanzi. La temperatura esterna varia così velocemente.
Il realtime è utile, ma bisogna applicarlo solo quando serve, in un caso come questo penso che non è necessario.
la terrazza era un esempio, ma se è come dici te se dovessi campionare a 10m secondi il realtime diventa necessario...
no?
Non si tratta di velocità di campionamento, si tratta di velocità nella reazione.
Nei sistemi realtime attivo nello scheduling delle priorità, che mi permettono di conoscere in quanto tempo il sistema conclude l'operazione avendo una determinata priorità rispetto alle altre.
Nell'ambito della registrazione audio, se sto campionando un suono, questa operazione deve avere avere la priorità rispetto ad un refresh dello sfondo (esempio), pena la perdita di informazioni (che si traduce in "click"...).
Al posto di un sensore di temperatura, prova a fare as esempio un vu-meter software. In questo modo potrai verificare le potenzialità di un sistema realtime, disponendo già del segnale di ingresso...
Ciao,
Touch.
PS: Alessandro Rubini ha scritto molto sul realtime.
touchstyle ha scritto:Non si tratta di velocità di campionamento, si tratta di velocità nella reazione.
Nei sistemi realtime attivo nello scheduling delle priorità, che mi permettono di conoscere in quanto tempo il sistema conclude l'operazione avendo una determinata priorità rispetto alle altre.
Nell'ambito della registrazione audio, se sto campionando un suono, questa operazione deve avere avere la priorità rispetto ad un refresh dello sfondo (esempio), pena la perdita di informazioni (che si traduce in "click"...).
Al posto di un sensore di temperatura, prova a fare as esempio un vu-meter software. In questo modo potrai verificare le potenzialità di un sistema realtime, disponendo già del segnale di ingresso...
Ciao,
Touch.
PS: Alessandro Rubini ha scritto molto sul realtime.
Capisco e così mi sa che un esperienza sul realtime non me l toglie nessuno... magari mi invento il motivo!
]
