Tempos de ping intermitentes em um ponto de acesso wi-fi do raspberry pi

Question

Eu configurei um pi de framboesa como um ponto de acesso wi-fi. Neste ponto, tudo que eu quero fazer é ssh o rpi. Eu estou achando que as sessões de ssh duram de 5 a 30 segundos a cada 1 a 6 minutos. Meu laptop é o único cliente conectado ao AP. Se eu configurar um ping contínuo do meu laptop para o endereço AP, o tempo médio de ping será de 1 a 4ms, mas, de vez em quando, atrasos excessivos de cerca de 100-500ms ou tempos limite de até 5 a 30 segundos ocorrerão. Isso ocorre se existe uma sessão ssh ativa ou não. Por comparação, se eu pingar a porta ethernet, todos os atrasos são de 1ms ou menos e não tenho timeouts. Eu tentei mudar de canal sem nenhum benefício.

O que é interessante é que, se eu desabilitar o modo wifi 'n' (agora em execução em g), wmm e ht_capab no hostapd.conf, melhorarei muito a situação com muito poucos (ou nenhum) tempo limite. Com estes desativados, os tempos de ping habituais são de 1-2 ms com atraso ocasional de 120 ms.

lsmod mostra os seguintes módulos:

-Module Size Used by
-aes_generic 31536 1
-8021q 17966 0
-garp 6295 1 8021q
-stp 1969 1 garp
-llc 5440 2 stp,garp
-snd_bcm2835 15846 0
-snd_pcm 77560 1 snd_bcm2835
-snd_page_alloc 5145 1 snd_pcm
-snd_seq 53329 0
-snd_seq_device 6438 1 snd_seq
-snd_timer 19998 2 snd_pcm,snd_seq
-snd 58447 5 snd_bcm2835,snd_timer,snd_pcm,snd_seq,snd_seq_device
-arc4 1676 2
-rt2800usb 14940 0
-rt2800lib 55351 1 rt2800usb
-rt2x00usb 11215 1 rt2800usb
-rt2x00lib 42334 3 rt2x00usb,rt2800lib,rt2800usb
-mac80211 273413 3 rt2x00lib,rt2x00usb,rt2800lib
-cfg80211 184163 2 mac80211,rt2x00lib
-rfkill 18202 2 cfg80211
-crc_ccitt 1522 1 rt2800lib
-leds_gpio 2235 0
-led_class 3562 2 leds_gpio,rt2x00lib

hostapd.conf

-interface=wlan0
-driver=nl80211
-ctrl_interface_group=0
-ssid=ivoPI

-hw_mode=g
-ieee80211n=1
-wmm_enabled=1

-channel=5
-#macaddr_acl=0
-auth_algs=3
-#ignore_broadcast_ssid=0
-wpa=3
-wpa_passphrase=*******
-wpa_key_mgmt=WPA-PSK
-wpa_pairwise=TKIP
-rsn_pairwise=CCMP

-ht_capab=[HT20][SHORT-GI-20] #[RX-STBC1]

Se alguém puder ajudar aqui, seria muito apreciado. aplausos

Ivo

Além do acima:

Eu já tentei o adaptador wifi acima, junto com outro, no modo cliente. O primeiro adaptador possui chip rt3072 com driver rtl2800usb / cfg80211. O segundo adaptador possui um chip Realtek rtl8188us com o driver de preparação r8712u. Cada adaptador (separadamente) foi conectado a um hub energizado. O pi não tinha a Ethernet conectada.

Primeiro adaptador Com baixa carga do processador e sem shell ou shell sem tráfego, não houve resultados típicos do ping. Atrasos pareciam ser totalmente aleatórios de 2ms a 320ms - em todo o lugar. Houve tempos limite ocasionais. Quando o topo foi executado a 0,01 seg, os pings ficaram muito estáveis em 2-3ms com ocasionais atrasos de ping únicos de 195-222ms. Eu observei no tempo limite 5 segundos ao longo de um período de cerca de 20 minutos.

segundo adaptador Com baixa carga do processador e sem shell ou shell sem tráfego, os resultados típicos do ping foram de 1-2ms. Os resultados do ping eram geralmente muito estáveis. Sob carga máxima superior a 0,01 segundos, o atraso do ping foi de cerca de 2-3 ms com ocasionais atrasos de ping únicos de 166-200ms. Eu não observei nenhum tempo limite.

Então, o que se conclui disso? Parece-me ser um problema de driver com rtl2800usb / cfg80211 ou algum outro componente relacionado. Quase se poderia consertar o problema correndo top continuamente, mas parece meio que um desperdício !! e ainda recebo o tempo limite ocasional. Eu não sei ainda se foi a maior carga do processador ou o aumento do tráfego TCP / IP que fez a melhoria.

    

Answer 1

Eu tive os mesmos problemas com varas de wi-fi diferentes no meu framboesa. Eu tentei fontes de alimentação diferentes, diferentes framboesas e também um hub USB ativo. Então, tive a sorte de ver sua observação, que desativar o modo 'n' de wifi, wmm e ht_capab poderia levar a melhores resultados. Desativei o modo n e wmm no meu roteador Wi-Fi Asus RT-N66U (executando openwrt / tomato ), e o tempo de ping diminui de 10 a 100 ms para 1-3 ms e a conexão ficou muito estável. Antes disso, a conexão diminuía muito frequentemente (após 30 a 60 minutos) e era muito lenta em geral.

Mas desabilitar o n-mode para a rede wifi completa não poderia ser a solução, então eu acho outra recomendação ( link ):

• Crie o arquivo /etc/modprobe.d/8192cu.conf , que contém a linha:

  options 8192cu rtw_power_mgnt=0 rtw_enusbss=0
  

• Reinicializar

Isso desativa a economia de energia do Wi-Fi e da suspensão USB.

• Você pode verificar se o modo de economia de energia está desativado:

  cat /sys/module/8192cu/parameters/rtw_power_mgnt
  

Desde 24 horas, a conexão Wi-Fi é estável agora em duas diferentes framboesas. Os tempos de ping são ligeiramente maiores (5-6 ms) do que desativar o modo n e o wmm no roteador wifi, mas muito estáveis e com apenas pequenas variações.

    

Answer 2

Você tem o mesmo comportamento com ele na rede do que apenas um cliente? Eu não testei com tanto detalhe quanto você, mas meu pi é inclinado um pouco assim às vezes; Eu tive apenas algumas semanas e tenho atribuído isso ao driver 8192cu que é glitchy de outras maneiras - por exemplo, ele não funcionará em um hub de energia, apenas quando conectado diretamente em.

Significando que o dongle tem que estar em uma das portas usb com baixo desempenho do pi - elas entregam no máximo 140 mA ao invés do padrão USB 2.0 500 mA (veja aqui ) - que eu acho que deve tornar um dispositivo wifi propenso a problemas. Eu faço o ping do roteador a cada cinco segundos e quando o ping falha, ele se reconecta (eu não estou usando o NetworkManager ou qualquer daemon do sistema, que normalmente lida com isso ... de qualquer maneira, se ele reconecta imediatamente leva ~ 15 segundos); Olhando para o log para isso, aconteceu 3 vezes nas últimas 30 horas, o que não é tão ruim, mas também não tem feito nada. Na sexta-feira eu estava compilando via ssh (então, maximizando o processador continuamente por um longo tempo) e isso aconteceu com freqüência (talvez a cada 5-10 minutos? Felizmente isso apenas congela o ssh i / o para um pouco).

Eu posso acabar recebendo um adaptador mais robusto que funcionará no hub de energia se ele continuar sendo um problema. Se você quiser usá-lo como um ponto de acesso, eu acho que você definitivamente deveria usar um hub de energia externo se você ainda não estiver. Aparentemente, é comum que eles não sejam regulados internamente, de modo que cada porta possa se aproximar da capacidade do hub (2-4 amperes) e não apenas 500mA, o que significa que você também pode energizar o pi para fora dele; algumas referências implícitas a esse aqui . Eu tenho um dos hubs belkin e obter cerca de 0,05-0,1 volts menos no hub do que em um carregador de 2A 5V. Agora, com o adaptador wi-fi plugado no pi (e é um pequenino nano), ele recebe outros 0,05 a 0,1 volts a menos, o que não é desprezível, já que a faixa ideal é de 4,75-5,25V - de acordo com o multímetro I estou bem na parte inferior do hub com o adaptador nano quando ocioso .

Eu acho que trabalhar em uma rede g exige menos do adaptador wi-fi, pois é mais lento que n.

Ah e BTW existe uma troca de pilha rpi :)

    

Answer 3

Eu tive o mesmo problema com meu Pi e com o módulo 8192cu , e não consegui nenhuma dessas sugestões para corrigir o problema.

No final, por desespero, verifiquei que outros pontos de acesso wifi estavam ativos na área e, para minha surpresa, um vizinho instalou uma nova rede wifi no mesmo canal que o meu estava usando. Mudar para um canal diferente resolveu o problema!

Não há mais 20.000ms pings ou 40% de perda de pacotes, ótimo! Às vezes as soluções mais fáceis são as mais difíceis: -)