Riot: IEEE802.15.4: HW Auto ACK considerado prejudicial

Na maioria dos casos, essa prática pode ser prejudicial.

Falando de forma realista, com que frequência isso causa danos reais? Que porcentagem de mensagens são confirmadas enquanto são realmente descartadas pelo MCU?

O rádio muda para o modo TX ao receber (#11256)

Este caso é exclusivo para rádios com um buffer de recepção/transmissão compartilhado, certo? Portanto, afeta apenas a classe de dispositivos at86rf2xx

Isso pode produzir comportamentos estranhos, …

Você tem alguns exemplos em que isso causa problemas?

Assim, proponho deixar o Auto ACK como opcional e implementar a resposta ACK no software

Você tem alguns números sobre o impacto nisso? Tamanho do flash/uso de RAM, mas também uso de energia, pois o MCU precisa acordar por mais tempo. Além disso, quanto tempo existe entre a recepção do quadro e o tempo limite de ack e é realista lidar com ACKs no software se o rádio estiver conectado por SPI?

Além de ter um L2 mais confiável

Estou um pouco cético em relação a essa afirmação (se isso ainda não ficou claro no meu comentário), lidar com acks L2 é um caso em tempo real suave (os prazos perdidos degradarão o serviço) e lidar com eles no software coloca um requisito difícil no comportamento em tempo real do RIOT.

Eu não me importo com o software L2 acks se for um requisito difícil para algumas camadas MAC específicas, mas isso não é mencionado na descrição aqui.

Olá @bergzand

Falando de forma realista, com que frequência isso causa danos reais? Que porcentagem de mensagens são confirmadas enquanto são realmente descartadas pelo MCU?

Para as camadas superiores não é grande coisa (considerando que geralmente são os melhores esforços).
No entanto, algumas camadas MAC e sub-MAC (OpenThread, TSCH) usam o ACK para atualizar as informações dos vizinhos.

Este caso é exclusivo para rádios com um buffer de recepção/transmissão compartilhado, certo? Portanto, afeta apenas a classe de dispositivos at86rf2xx

Verdadeiro. Estou apenas apontando cenários onde isso pode acontecer.

Você tem alguns exemplos em que isso causa problemas?

Fornecer informações erradas aos usuários da camada MAC (por exemplo, Mesh Link Establishment) provavelmente afetaria a qualidade do link. Estou ciente de que ainda não temos isso no RIOT (e as pilhas que o usam já implementam o recurso).

Você tem alguns números sobre o impacto nisso? Tamanho do flash/uso de RAM, mas também uso de energia, pois o MCU precisa acordar por mais tempo. Além disso, quanto tempo existe entre a recepção do quadro e o tempo limite de ack e é realista lidar com ACKs no software se o rádio estiver conectado por SPI?

Infelizmente não. Como não está implementado, não tenho números para comparar. Eu só tenho algumas ramificações de teste com ACK automático, mas não testei mais profundamente.

Estou um pouco cético em relação a essa afirmação (se isso ainda não ficou claro no meu comentário), lidar com acks L2 é um caso em tempo real suave (os prazos perdidos degradarão o serviço) e lidar com eles no software coloca um requisito difícil no comportamento em tempo real do RIOT.

Há algumas informações do Tiny OS que o software ACK tende a ter quedas mais altas (https://vs-git.informatik.uni-kl.de/engel/tinyos/blob/020c6a6d8cc542bf58ca6afb8b1bf24efbe381de/doc/txt/tep126.txt), mas pelo menos não há falsos positivos.
AFAIK o IEEE802.15.4 não fala sobre hard constrains (apenas sobre valores de timeout). Se um pacote ACK não for entregue a tempo, ele será considerado perdido. Mas, como dito antes, não tenho informações sobre o desempenho do sistema operacional com ACKs de software. Seria interessante ter alguns benchmarks

Eu não me importo com o software L2 acks se for um requisito difícil para algumas camadas MAC específicas, mas isso não é mencionado na descrição aqui.

Precisamos implementar o software ACK de qualquer maneira para rádios que não suportam Auto ACK e recursos que não estão disponíveis em aceleradores de hardware (não conheço rádios que suportem ACKs aprimorados para ser honesto).
A questão é: queremos que isso seja opcional ou obrigatório para nossas configurações padrão? Como descrito anteriormente, a ideia não é remover o suporte ao Auto ACK, mas ter um melhor suporte de L2. Ainda podemos habilitar o Auto ACK se quisermos (é por isso que propus adicionar caps de rádio em https://github.com/RIOT-OS/RIOT/pull/11473)

Talvez eu esteja enganado, mas a solução parece simples:

• Implementamos um ARQ (independente de hardware) -> queremos isso independentemente desta discussão.
• Comparamos desempenhos (e interoperabilidade) de implementações de hardware e software.
• Desejamos uma configuração padrão específica da plataforma, que não impeça de compilar a outra.

Como um nó lateral: O fato de nunca termos enfrentado o problema destacado por @jia200x pode estar relacionado à falta de camadas MAC em cima de um rádio no RIOT. Além disso, com rádios com perdas de baixa potência, toleramos certa perda de qualquer maneira.

Qual a importância dos ACKs de software para 6TiSCH? IIRC, OpenWSN usa ACKs de software parcialmente para rastrear a qualidade do link entre vizinhos.

Qual a importância dos ACKs de software para 6TiSCH? IIRC, OpenWSN usa ACKs de software parcialmente para rastrear a qualidade do link entre vizinhos.

6TiSCH não fala contra ACKs de hardware, mas requer ACKs aprimorados para passar informações de tempo. No OpenWSN, isso é tratado pelo próprio pacote.

*e ACKs aprimorados não são suportados pelo hardware que eu conheço.

Além disso, o problema com os recursos de reconhecimento de hardware em alguns casos é que ele assume total responsabilidade pelo mecanismo sem necessariamente expor informações relevantes, como ACK recebido ou número de tentativas. Com o 6TiSCH você pode retransmitir um quadro em outra célula, o que requer esse tipo de informação. Assim, o OpenWSN baseia-se em um conjunto limitado de recursos de dispositivos de rádio e implementa todos os outros componentes MAC em software.

Este problema foi marcado automaticamente como obsoleto porque não teve atividade recente. Será fechado se não ocorrer mais nenhuma atividade. Se você quiser que eu ignore esse problema, marque-o com o rótulo "State: don't stale". Obrigado por suas contribuições.