Menor latência dos padrões Wi-Fi 802.11


8

Estou fazendo um projeto usando um módulo Arduino e um ESP8266 executando o firmware esp-link - o que me permite usar o MQTT para controlar o Arduino. Eu já tinha visto algo como um módulo XBee - mas eles são muito caros em comparação com o ESP8266! ( Se você não sabe o que é o ESP8266 ou o MQTT, não se preocupe - basta saber que está usando TCP por Wi-Fi ).

Os pacotes MQTT são pequenos, portanto a taxa de transferência da rede Wi-Fi nunca será um problema. Porém, latência e confiabilidade são grandes fatores. O sistema MQTT está usando TCP, portanto deve ser confiável o suficiente - mas não tenho tanta certeza sobre a latência.

Eu tenho a opção de usar uma conexão 802.11b, .11g ou .11n para a rede que o ESP8266 usa. Existe algo em algum desses padrões que faça com que a latência seja menor do que qualquer outro? Com qual eu esperaria ter o melhor desempenho para pacotes muito pequenos e pouco frequentes?


1
Em considerações de latência, há também o outro lado envolvido, além de um problema de qualidade na implementação. Não acho que números teóricos o levem muito longe.
PlasmaHH

google para um artigo do LWN chamado "tornar o wifi rápido".
precisa saber é o seguinte

Respostas:


10

Primeiro de tudo, você está fazendo algo MUITO certo que muitos designers e usuários da IoT não fazem: Você considera o fato de que a operação precisa ser confiável e limitada pela latência. Nem todo mundo faz isso, e é por isso que muitos dispositivos de IoT são realmente ruins.

A escolha do padrão entre 802.11 b / g / n não influenciará muito sua latência. Suponho que estamos limitando latências <10ms, porque tudo "funcionará em 99,5% dos casos, usando um bom hardware WiFi".

Se você estiver em um cenário de latência, certamente não

  • use TCP (e, portanto, MQTT, que é construído sobre isso)
  • use um dispositivo que emule um link serial lento - se seus pacotes tiverem 4 caracteres e 9600 bauds, você gastará um milissegundo apenas para obter dados do µC para o dispositivo WiFi
  • use Wi-Fi, já que não há garantia de que sua estação poderá enviar dentro de uma janela de tempo finito, de todo (apenas uma probabilidade)

Se você precisa de confiabilidade, por outro lado, não deve

  • use UDP puro (já que não há garantia ou feedback de que os pacotes chegam ao seu destino)
  • use um protocolo de rádio unidirecional puro (mesma razão)
  • use um ESP8266, que tira vantagem de preço por falta de teste, projeto e certificação para operação de alta confiabilidade (e, portanto, nenhum grande fabricante de eletrônicos o utilizará sem fazer esse teste sozinho, caso em que módulos prontos de fabricantes confiáveis geralmente ficam mais baratos)

Portanto, antes de tudo, defina quais são seus requisitos de latência e de confiabilidade. Você deve ter um pedaço de papel que diz

A latência para a comunicação de {one | two} vias deve ser <{max latency} em {porcentagem tolerável}% dos casos. Não deve haver uma probabilidade superior a {porcentagem tolerável}% de perda de um pacote.

Então, você pode examinar os limites teóricos dos sistemas e, em seguida, os limites práticos das implementações daqueles que se encaixam nisso.


Primeiro de tudo, você está fazendo algo MUITO certo ... Obrigado! :) Por enquanto, é apenas um exemplo de brinquedo, mais do que algo que pretendo disponibilizar como um produto real. A escolha do padrão entre 802.11 b / g / n não influenciará muito sua latência. Eu não achei que isso faria muita diferença, mas pensei em perguntar. Ainda vou fazer alguns dos meus próprios testes, mas obviamente não tenho o equipamento para fazê-lo tão detalhadamente quanto um laboratório. Quanto ao EPS8266 e Wi-Fi - imaginei, já que era mais barato, eu daria uma chance primeiro - e tentaria outra coisa se não fosse aceitável.
Seanlano

Definitivamente, definirei uma declaração da minha latência aceitável e probabilidade de perda de pacotes - e usarei isso como critério para continuar usando o ESP8266 ou não.
Seanlano
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.