Qui prodest?

Devo dire che tenere questo blog mi ha fatto rivalutare l'Italiano. E sto facendo su un pesierino sulle lingue classiche come il latino ed il greco. Perche'? Perche' cosi' complico la vita a chi sta passando al pettine fine questo blog alla disperata ricerca di una effermazione che possa essere usata contro di me e contro i miei colleghi che sviluppano ScicosLab. Le sfumature della lingua italiana sono veramente difficili da apprezzare ed ancora piu' difficili da comprendere.

Tranquilli.

L'unica cosa che riusciranno a trovare sara' il loro imbarazzo. Noi navigheremo tranquilli fino alle calde spiagge di Cuba (non so se mi sono spiegato). Vi raccontero' i dettagli di progettazione dell' Красный Октябрь in un prossimo post. Per adesso mi raccomando di controllare la temperatura dell'elio liquido perche' sopra 4.2 Kelvin il superconduttore NbSn collassa e addio viaggio tranquillo fino alle calde spiagge di Cuba.

Ritorniamo a RTAI.


La filosofia di RTAI e' semplice e geniale allo stesso tempo. Invece di costringere tutti i programmi a vivere nel mondo hard real time, stravolgere lo scheduler del kernel e obbligare la riscrittura di tutti i driver, RTAI vi permette di continuare a far vivere in un normale ambiente Linux "soft real time" le applicazioni che usate di solito (e senza bisogno di ricompilare nulla), mentre "a lato" crea un ambiente misto kernel/user space dove "vivono" i programmi hard real time.

Per attivare queste funzionalità, l'unica cosa che bisogna fare e' applicare una patch al kernel e ricompilarlo.

Tranquilli: applicare la patch e ricompilare il kernel e' facile. La cosa difficile e' far funzionare corretamente la baracca. Putroppo esistono un sacco di fattori di disturbo che possono rendere la vita con RTAI molto ma molto difficile. Un primo ostacolo sono di driver proprietari delle schede video NVIDIA e ATI. Succede spesso che i driver binari si allocano troppe risorse per troppo tempo, a scapito della velocita' di risposta di Linux RTAI. Evitate quindi di mischiare Linux RTAI con driver binari, cercate di usare hardware supportato tramite driver open source.

Ma la cosa che pou' mandarvi in paranoia e' il chipset della vostra scheda madre. Non solo ne esistono una infinita', ma i costruttori di mother board sono degli specialisti nel mischiare le carte in tavola.

Paolo ha fatto del tuning molto spinto per ottimizzare i tempi di risposta. Dubito fortemente che possiate riuscire ad avere delle latenze migliori di RTAI. Purtroppo il team di Paolo non ha le risorse per fare dei test esaustivi su tutte le configurazioni possibili di PC. Quindi le cose potrebbero andarvi lisce alla prima, come potreste entrare in un brutto giro di cazzotti a colpi di SMI, interrupt persi, interrupt sporadici ed inspiegabili quanto improvvisi picchi di latenza.

Non pensate che i vostri problemi siano dovuti a software open source di scarsa qualità. Ho provato la patch hard real time di Real Time Windows Target (Mathworks) su 12 PC diversi. Su 4 il PC si pianta e siete costretti al reboot. Su due e' instabile. Sugli altri funziona perfettamente. Il problema e' sempre lo stesso: nessun sviluppatore software puo' testare ed ottimizzare il codice su tutte le combinazioni hardware/software immaginabili, nemmeno un gigante come Mathworks.

Come si fa allora a migliore la situazione?

Risposta: si usano gli utilizzatori come cavie da laboratorio. Puo' sembrare inumano ma e' cosi' che l'Open Source funziona. E' un sistema a loop chiuso. Gli sviluppatori onesti cercano di fare del loro meglio, pubblicano il software e aspettano il feedback degli utilizzatori per correggeri i bug.