Análise do Tempo de Resposta da Composição de Micro-Protocolos

Análise do Tempo de

Resposta da Composição

de Micro-Protocolos

João Carlos Negrão Ventura

Discussão da Dissertação de Mestrado

12 de Julho de 2001

Faculdade de Ciências

Introdução

„

Motivação

„

Breve introdução aos micro-protocolos

„

Análise de Escalonabilidade

„

Metodologia de análise de

escalonabilidade para micro-protocolos

„

Aplicação Prática: RELCAN

„

Introdução ao EDCAN e RELCAN

„

Cenários Desenvolvidos

Motivação

„

Os sistemas de tempo-real estão a tornar-se

distribuídos

„

Problema: Necessidade cada vez maior de serviços

complexos.

„

Solução: Uso de composições de micro-protocolos.

„

No entanto, a escalonabilidade destas

composições tem de ser garantida!

„

Este trabalho pretende desenvolver uma

metodologia que tire partido das propriedades

intrínsecas dos protocolos para facilitar a sua

análise.

Micro-protocolos

„

Os micro-protocolos são objectos modulares que

fornecem um dado serviço.

„

Através da composição, é possível fornecer

vários serviços.

„

Interacção entre protocolos através de eventos.

„

Cada micro-protocolo é assinante de um

conjunto de eventos e é gerador de outros.

„

Três sistemas para micro-protocolos em tempo

real foram apresentados: CORDS Paths, Canais

RTD do CactusRT e o RT-Appia.

Análise de Escalonabilidade

„

A técnica de análise usada é a “Schedulability

Analysis using Time-Offsets” de Tindell.

„

A utilização de desfasamentos permite tirar partido das

relações de precedência entre as diferentes tarefas dos

micro-protocolos.

„

Melhor maneira de incorporar os tempos de espera da

Modelo Computacional

„

Camadas de micro-protocolos.

„

Cada micro-protocolo é concretizado

usando várias tarefas.

„

Uma tarefa para cada evento

processado.

„

As tarefas são periódicas.

„

O período é derivado do tempo entre

Metodologia de Análise de

Micro-Protocolos (1/3)

Gráfico de eventos

Conjunto de tarefas

Pior Tempo de Resposta

Offsets entre tarefas

Verificação de metas

Conjunto de protocolos

Eventos processados e

gerados

Prioridades dos eventos

Pior Tempo de Computação

Parâmetros de

Escalonamento

Número de processos

envolvidos

Carga de outras tarefas e

mensagens

Parâmetros da Rede

OUTPUT

INPUT

Metodologia de Análise de

Micro-Protocolos (2/3)

„

Cada evento processado, gera outros,

resultando numa cadeia de eventos.

„

As tarefas que fazem parte de uma

cadeia herdam o período e a meta do

evento original.

„

O gráfico de eventos é usado para

extrair a cadeia de eventos.

„

Uma cadeia de eventos completa é uma

Metodologia de Análise de

Micro-Protocolos (3/3)

„

Iterar até os valores convergirem:

„

Determinar tempo de resposta das tarefas, usando os

desfasamentos actuais. Actualizar desfasamento das mensagens

para o tempo de resposta das tarefas emissoras.

„

Determinar tempo de transmissão das mensagens, usando os

desfasamentos actuais. Actualizar desfasamento das tarefas

receptoras para o tempo de chegada das mensagens.

„

O sistema prevê o uso dos melhores tempos de

transmissão na determinação de desfasamentos

“melhor caso”.

„

De modo a escalonar as tarefas no instante exacto de chegada

das mensagens.

„

Por último, comparação entre os tempos obtidos e a

Aplicação Prática:

EDCAN+RELCAN

„

Pilha de protocolos desenvolvida para

fornecer comunicação fiável sobre CAN.

„

O CAN não garante transmissão atómica

quando o penúltimo bit é detectado como

inválido em alguns nós.

„

Dois protocolos:

„

EDCAN: difusão ávida.

Aplicação Prática: EDCAN

„

EDCAN:

„

Protocolo de difusão ávida.

„

Protocolo pesado:

„

Todos os nós retransmitem a mensagem de

modo a mascarar os erros.

„

Usado no modo de recuperação do

RELCAN ou quando é necessário uma

recuperação rápida.

EDCAN Sender

ES1

mess =

NULL

Y

N

edcan.req(mid(type, p, n), mess)

ES2

Wait

can-data.cnf(mid, mess)

or can-rtr.cnf(mid)

edcan.cnf

(mid, mess)

Idle

can-data.req

(mid, mess)

can-rtr.req

(mid)

EDCAN: Diagrama lógico

EDCAN Recipient

Idle

ndup(mid) := 0;

ER

ndup(mid):=ndup(mid)+1

ndup(mid)=1

N

Y

ndup(mid)>j

can-data.ind(mid, mess)

or can-rtr.ind(mid)

can-abort.req

(mid)

Y

edcan.ind

(mid, mess)

mess =

NULL

Y

N

can-rtr.req

(mid)

can-data.req

(mid, mess)

N

Aplicação Prática: RELCAN

„

Protocolo de duas fases:

„

1ª fase: envio da mensagem.

„

2ª fase: envio da confirmação, e entrega da

mensagem.

„

Se o emissor falha:

„

A confirmação não é recebida.

„

O EDCAN é activado para recuperar do modo

RELCAN:

Diagrama lógico

R E L C A N S e n d e r

R S 1

r e l c a n . r e q ( m e s s )

c a n - d a t a . r e q (m id

( R - D A T A , s , n ) m e s s )

R S 2

W a it

c a n - d a t a . c n f ( m i d

( R - D A T A , s , n ) , m e s s )

c a n - r t r . r e q

(m id ( C O N F I R M , s , n ) )

I d le

r e l_ s n : = 0 ;

r e l_ s n : = r e l_ s n + 1 ;

r e lc a n . c n f (m e s s )

R E L C A N R e c ip ie n t

Idle

ndup(m id) := 0;

data(m id):=N U LL;

R R 1

ndup(m id):=ndup(m id)+1;

data(m id) := m ess;

start alarm (m id);

ndup(m id)=1

Y

relcan.ind

_(mess)

R R 2

W ait

N

data(m id) := N U LL;

cancel alarm (m id);

R R 3

edcan.req

(m id, data(m id))

R R 4

ndup(m id):=ndup(m id)+1;

ndup(m id)=1

Y

N

a la r m (m id )

c a n - r t r . in d (m id

(C O N F I R M , s , n ))

c a n - d a t a . in d (m id

(R - D A T A , p , n ), m e s s )

relcan.ind

(mess)

e d c a n . in d

(m id (R - D A T A , p , n ), m e s s )

Gráfico de Eventos:

RELCAN e EDCAN

alarm.timeout

relcan.req

can-data.req

alarm.start can-rtr.req

CAN

RS1

RS2

RR1

EDCAN

RR3

can-rtr.ind

RR2

alarm

alarm.cancel

edcan.req

RR4

relcan.ind

edcan.ind

can-data.ind

can-data.cnf

alarm

CAN

relcan.cnf

can-data.req

ES1

can-rtr.req

can-data.cnf

CAN

ES2a

can-data.ind

edcan.req

edcan.cnf

can-abort.req

edcan.ind

can-data.req

CAN

CAN

can-rtr.cnf

CAN

ES2b

can-rtr.ind

edcan.cnf

can-abort.req

edcan.ind

can-rtr.req

CAN

CAN

ERa

ERb

2

2

1

1

CAN

1

CAN

2

can-rtr.req

can-data.req

Cenário Simples: descrição

„

Rede de 4 nós

„

1 emissor que falha

„

1 receptor correcto

„

Sem efeitos de jitter, bloqueio e

escalonamento

„

Período=2000

µ

s

„

Pior Tempo de Computação=150

µ

s

„

Max. transmissão mensagem =157

µ

s

Cenário Simples:

demonstração

„

Pior tempo de resposta=1928

µ

s

(falha do emissor)

„

Desfasamentos obtidos: 0, 307, 857, 1007, 1314,

765 12 11 10 8 4 2 1 9 3 STOP

tarefa EDCAN

nó 1

nó 2

nó 3

nó 4

CAN

tempo

tarefa RELCAN

Cenário Simples: resultados

obtidos

„

Tempo de resposta é menor se o emissor não

falhar.

„

WCRT=757

µ

s.

„

Mensagens de tamanho máximo.

„

Determinação dos desfasamentos para o melhor

caso:

„

O

_rs1

=0

µ

s, o

_rs2

=o

_rr1

=214

µ

s, o

_rr2

=428

µ

s, o

_rr3

=764

µ

s,

o

_rr4

=1278

_µ

s.

„

O

_es1

=0

µ

s, o

_es2

=O

_ER

=214

µ

s.

„

Estes desfasamentos permitem que a tarefa esteja

pronta para execução no instante de chegada da

mensagem.

Cenário Complexo:

descrição

„

De modo a testar a interferência, o

seguinte cenário complexo foi

desenvolvido:

„

6 nós no barramento CAN.

„

4 nós são emissores, todos são receptores.

„

Cada mensagem (e portanto as tarefas que a

processam) tem uma prioridade diferente.

„

Cada mensagem é transmitida de forma

independente, maximizando a

interferência.

Cenário Complexo: Base

0 500 1000 1500 2000 2500 3000 3500 RS1_ cpu1 RS2_ cpu1 RR1_ cpu1 RR1_ cpu2 RR1_ cpu3 RR1_ cpu4 RR1_ cpu5 RR1_ cpu6 RR2_ cpu1 RR2_ cpu2 RR2_ cpu3 RR2_ cpu4 RR2_ cpu5 RR2_ cpu6 RS1_ cpu2 RS2_ cpu2 RR1_ cpu1 RR1_ cpu2 RR1_ cpu3 RR1_ cpu4 RR1_ cpu5 RR1_ cpu6 RR2_ cpu1 RR2_ cpu2 RR2_ cpu3 RR2_ cpu4 RR2_ cpu5 RR2_ cpu6 RS1_ cpu3 RS2_ cpu3 RR1_ cpu1 RR1_ cpu2 RR1_ cpu3 RR1_ cpu4 RR1_ cpu5 RR1_ cpu6 RR2_ cpu1 RR2_ cpu2 RR2_ cpu3 RR2_ cpu4 RR2_ cpu5 RR2_ cpu6 m icr oseg un dos

WCRT

Offset

Cenário Complexo:

Jitter+Bloqueio e Escalonador

0 1000 2000 3000 4000 5000 6000 cpu1cpu1cpu1cpu2cpu3cpu4cpu5cpu6cpu1cpu2cpu3cpu4cpu5cpu6cpu2cpu2cpu1cpu2cpu3cpu4cpu5cpu6cpu1cpu2cpu3cpu4cpu5cpu6cpu3cpu3cpu1cpu2cpu3cpu4cpu5cpu6cpu1cpu2cpu3cpu4cpu5cpu6 mi cr osegundos

WCRT

Offset

Cenário Complexo:

Prioridades Alternativas

0 500 1000 1500 2000 2500 3000 3500 RS1_ cpu1 RS2_ cpu1 RR1_ cpu1 RR1_ cpu2 RR1_ cpu3 RR1_ cpu4 RR1_ cpu5 RR1_ cpu6 RR2_ cpu1 RR2_ cpu2 RR2_ cpu3 RR2_ cpu4 RR2_ cpu5 RR2_ cpu6 RS1_ cpu2 RS2_ cpu2 RR1_ cpu1 RR1_ cpu2 RR1_ cpu3 RR1_ cpu4 RR1_ cpu5 RR1_ cpu6 RR2_ cpu1 RR2_ cpu2 RR2_ cpu3 RR2_ cpu4 RR2_ cpu5 RR2_ cpu6 RS1_ cpu3 RS2_ cpu3 RR1_ cpu1 RR1_ cpu2 RR1_ cpu3 RR1_ cpu4 RR1_ cpu5 RR1_ cpu6 RR2_ cpu1 RR2_ cpu2 RR2_ cpu3 RR2_ cpu4 RR2_ cpu5 RR2_ cpu6 mi cr osegundos

WCRT

Offset

Conclusões

„

Foi proposta uma metodologia que

permite obter os piores tempos de

resposta de composições de

micro-protocolos.

„

A ferramenta de Tindell foi estendida de

modo a suportar o modelo.

„

Suporte para sistemas distribuídos.

„

Validação da metodologia através do uso

Direcções Futuras

„

Módulo de análise do protocolo.

„

Módulo de obtenção do Pior Tempo

de Computação (WCCT).

„

Verificar os resultados contra uma