Qual o melhor “sabor” para o RT-Linux (Real Time Linux)?

Qual o melhor “sabor” para o RT-Linux (Real Time Linux)? Ricardo Matias Nº27471 e Vitor Hugo Nº21906 Sistemas de Tempo Real 2006 DETI-UA

Overview • Sistemas operativos de tempo real • Soluções para Linux • Teste de varias soluções • Análise de Resultados

Sistemas Operativos de Tempo Real • Resposta correcta no domínio “Lógico” e “Temporal” • (Tem que garantir uma resposta correcta a eventos num período limitado de tempo) • Vantagens de usar Linux: Grande flexibilidade no desenvolvimento e muitas ferramentas disponíveis. • Problema dos sistemas Linux convencionais: • O Kernel monolítico, em grande parte não preemptive. • (Grandes variações nos atrasos de preempção, que podem chegar a centenas de ms)

Abordagens para adequar o Linux para aplicações em Sistemas de Tempo Real: • Executar o Linux como uma tarefa em tempo livre de um Micro Kernel de Tempo Real (que tem completo controlo das interrupções e do processador). São necessários novos drivers para aplicações nesse Kernel. Perdemos a protecção de memoria do Linux. • Modificar o Kernel do Linux internamente, para inserir características de Tempo Real (ex: reserva de recursos). • Low latency patches: Inserir pontos de “rescheduling”, diminuindo o tamanho dos bocados de Kernel não preemptive. • Kernel preemtability patches: Executar o Kernel como multi-processo. É necessário ter em atenção situações de sincronização.

Soluções a avaliar • Linux 2.4 (tem vários problemas quando usado em tempo real, usado para comparação base) • Linux 2.6 (melhor do que Linux 2.4, com introdução de mecanismos para tempo real. Algoritmo de scheduling mais eficiente em situações de sobrecarga, Kernel preemption patch). • Linux 2.4 com RTAI (Real Time Aplication Interface). É um Micro Kernel que corre debaixo de Linux. O Linux executa como tarefa a tempo disponível. • Linux 2.4 com LXRT. É uma extensão do RTAI, permite correr tarefas soft e hardreal time em espaço de usuário, usando o RTAI API.

Mesurement Setup • PC, Target hardware e uma ligação de rede entre o PC e o target. • Vamos ver os tempos de resposta a um evento gerado periodicamente com o sistema sobrecarregado e sem carga.

Descrição dos processos • Comms Server e Comms Client: Criar carga de comunicações e processamento no target. • Data Acq: Colectar a informação dos atrasos através do timer. Espera pelo sinal que indica o inicio do intervalo de controlo, lê o contador do timer (preemption latency) e depois pede informação do time counter armazenada no driver do interrupt handler. Envia essa informação ao File I/O. • File I/O:Recebe informação do Data Acq e organiza a informação em gamas de valores. Termina todo o processo quando atingindo um determinado nº de amostras.

Medidas t1=interrupt latency t2=preemption latency Figura 1: latência de preempção Figura 2: componentes da latência

Modelo de Processos para Linux 2.4 e 2.6 Figura 4: modelo de processos no Linux 2.4 e Linux 2.6

Modelo de processos para Linux com RTAI Figura 5: Linux 2.4 com RTAI

Modelo de Processos para Linux com LXRT Figura 6: Linux 2.4 com LXRT

Latência de Interrupção Latência de Interrupção sem carga Latência de Interrupção com carga Figura 7: Curvas da Latência de Interrupção sem carga Figura 8: Curvas da Latência de Interrupção com carga

Latência de Preempção Sem carga Com carga Figura 9: Curvas da Latência de Preempção sem carga Figura 10: Curvas da Latência de Preempção sem carga

Interrupt Latency Summary Tabela 1: Interrupt Latency Summary

Preemption Latency Summary Tabela 2: Preemption Latency Summary

Overall • RTAI - mais performance • LXRT - ligeiramente menos performance, facilidades do Linux em espaço de usuário. • Linux 2.6 é alternativa às duas primeiras. • Linux 2.4 normal é desadequado para RT (tempos de resposta pouco determinísticos).

Referências http://linuxdevices.com/articles/AT3479098230.html http://www.wikipedia.org Hard Real-Time Computing Systems (2nd edition) Springer, Buttazzo

Qual o melhor “sabor” para o RT-Linux (Real Time Linux)?