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 hard real 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
Figura 1: latência de preempção
Figura 2: componentes da latência
t1=interrupt latency
t2=preemption latency
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
Figura 7: Curvas da Latência de Interrupção sem carga
Latência de Interrupção com carga
Figura 8: Curvas da Latência de Interrupção com carga
Latência de Preempção
Sem carga
Figura 9: Curvas da Latência de Preempção sem carga
Com 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