Por que meu MacBook Pro tem tempos de ping longos em relação ao Wi-Fi?

5

Tenho tido problemas para me conectar à minha rede Wi-Fi. É estranho, os tempos de ping para o roteador (< 30 pés de distância) parecem aumentar, muitas vezes ficando mais de 10 segundos antes de voltar lentamente para baixo. Você pode ver a tendência abaixo. Eu estou em um MacBook Pro e fiz as coisas normais (redefinir a PRAM e SMC , alterei os canais sem fio, etc. ). Isso acontece em diferentes roteadores, então acho que deve ser meu laptop, mas não sei o que poderia ser.

O valor de RSSI está em torno de -57, mas já vi a taxa de transmissão entre 0, 48 e 54 A intensidade do sinal é de ~ 60% com 9% de ruído. Atualmente, existem 17 outras redes sem fio ao alcance, mas apenas uma no mesmo canal.

1 - Como posso descobrir o que está acontecendo?
2 - Como posso corrigir a situação?

PING 192.168.1.1 (192.168.1.1): 56 data bytes
64 bytes from 192.168.1.1: icmp_seq=0 ttl=254 time=781.107 ms  
64 bytes from 192.168.1.1: icmp_seq=1 ttl=254 time=681.551 ms  
64 bytes from 192.168.1.1: icmp_seq=2 ttl=254 time=610.001 ms  
64 bytes from 192.168.1.1: icmp_seq=3 ttl=254 time=544.915 ms  
64 bytes from 192.168.1.1: icmp_seq=4 ttl=254 time=547.622 ms  
64 bytes from 192.168.1.1: icmp_seq=5 ttl=254 time=468.914 ms  
64 bytes from 192.168.1.1: icmp_seq=6 ttl=254 time=237.368 ms  
64 bytes from 192.168.1.1: icmp_seq=7 ttl=254 time=229.902 ms  
64 bytes from 192.168.1.1: icmp_seq=8 ttl=254 time=11754.151 ms  
64 bytes from 192.168.1.1: icmp_seq=9 ttl=254 time=10753.943 ms  
64 bytes from 192.168.1.1: icmp_seq=10 ttl=254 time=9754.428 ms  
64 bytes from 192.168.1.1: icmp_seq=11 ttl=254 time=8754.199 ms  
64 bytes from 192.168.1.1: icmp_seq=12 ttl=254 time=7754.138 ms  
64 bytes from 192.168.1.1: icmp_seq=13 ttl=254 time=6754.159 ms  
64 bytes from 192.168.1.1: icmp_seq=14 ttl=254 time=5753.991 ms  
64 bytes from 192.168.1.1: icmp_seq=15 ttl=254 time=4754.068 ms  
64 bytes from 192.168.1.1: icmp_seq=16 ttl=254 time=3753.930 ms  
64 bytes from 192.168.1.1: icmp_seq=17 ttl=254 time=2753.768 ms  
64 bytes from 192.168.1.1: icmp_seq=18 ttl=254 time=1753.866 ms  
64 bytes from 192.168.1.1: icmp_seq=19 ttl=254 time=753.592 ms  
64 bytes from 192.168.1.1: icmp_seq=20 ttl=254 time=517.315 ms  
64 bytes from 192.168.1.1: icmp_seq=37 ttl=254 time=1.315 ms  
64 bytes from 192.168.1.1: icmp_seq=38 ttl=254 time=1.035 ms  
64 bytes from 192.168.1.1: icmp_seq=39 ttl=254 time=4.597 ms  
64 bytes from 192.168.1.1: icmp_seq=21 ttl=254 time=18010.681 ms  
64 bytes from 192.168.1.1: icmp_seq=22 ttl=254 time=17010.449 ms  
64 bytes from 192.168.1.1: icmp_seq=23 ttl=254 time=16010.430 ms  
64 bytes from 192.168.1.1: icmp_seq=24 ttl=254 time=15010.540 ms  
64 bytes from 192.168.1.1: icmp_seq=25 ttl=254 time=14010.450 ms  
64 bytes from 192.168.1.1: icmp_seq=26 ttl=254 time=13010.175 ms  
64 bytes from 192.168.1.1: icmp_seq=27 ttl=254 time=12010.282 ms  
64 bytes from 192.168.1.1: icmp_seq=28 ttl=254 time=11010.265 ms  
64 bytes from 192.168.1.1: icmp_seq=29 ttl=254 time=10010.285 ms  
64 bytes from 192.168.1.1: icmp_seq=30 ttl=254 time=9010.235 ms  
64 bytes from 192.168.1.1: icmp_seq=31 ttl=254 time=8010.399 ms  
64 bytes from 192.168.1.1: icmp_seq=32 ttl=254 time=7010.144 ms  
64 bytes from 192.168.1.1: icmp_seq=33 ttl=254 time=6010.113 ms  
64 bytes from 192.168.1.1: icmp_seq=34 ttl=254 time=5010.025 ms  
64 bytes from 192.168.1.1: icmp_seq=35 ttl=254 time=4009.966 ms  
64 bytes from 192.168.1.1: icmp_seq=36 ttl=254 time=3009.825 ms  
64 bytes from 192.168.1.1: icmp_seq=40 ttl=254 time=16000.676 ms  
64 bytes from 192.168.1.1: icmp_seq=41 ttl=254 time=15000.477 ms  
64 bytes from 192.168.1.1: icmp_seq=42 ttl=254 time=14000.388 ms  
64 bytes from 192.168.1.1: icmp_seq=43 ttl=254 time=13000.549 ms  
64 bytes from 192.168.1.1: icmp_seq=44 ttl=254 time=12000.469 ms  
64 bytes from 192.168.1.1: icmp_seq=45 ttl=254 time=11000.332 ms  
64 bytes from 192.168.1.1: icmp_seq=46 ttl=254 time=10000.339 ms  
64 bytes from 192.168.1.1: icmp_seq=47 ttl=254 time=9000.338 ms  
64 bytes from 192.168.1.1: icmp_seq=48 ttl=254 time=8000.198 ms  
64 bytes from 192.168.1.1: icmp_seq=49 ttl=254 time=7000.388 ms  
64 bytes from 192.168.1.1: icmp_seq=50 ttl=254 time=6000.217 ms  
64 bytes from 192.168.1.1: icmp_seq=51 ttl=254 time=5000.084 ms  
64 bytes from 192.168.1.1: icmp_seq=52 ttl=254 time=3999.920 ms  
64 bytes from 192.168.1.1: icmp_seq=53 ttl=254 time=3000.010 ms  
64 bytes from 192.168.1.1: icmp_seq=54 ttl=254 time=1999.832 ms  
64 bytes from 192.168.1.1: icmp_seq=55 ttl=254 time=1000.072 ms  
64 bytes from 192.168.1.1: icmp_seq=58 ttl=254 time=1.125 ms  
64 bytes from 192.168.1.1: icmp_seq=59 ttl=254 time=1.070 ms  
64 bytes from 192.168.1.1: icmp_seq=60 ttl=254 time=2.515 ms  
    
por Randall 16.02.2010 / 12:40

2 respostas

1

Em laptops Mac anteriores, era fácil acessar a placa wifi (logo abaixo do teclado de fácil abertura), não sei se isso ainda é verdade.

Se for, recomendo desconectar e reconectar o conector a essa placa. Nos anos passados, outros tiveram problemas como esse, que foram resolvidos com o novo conector.

    
por 16.02.2010 / 14:46
1

Essa saída de ping é louca . É como se nada acontecesse por 16-18 segundos e, de repente, tudo aparecesse de uma só vez. Mesmo que houvesse problemas com a agregação de frames 802.11n e Block Acks, eu não esperaria que tudo ficasse na fila e ficasse na fila por 18 segundos e, de repente, todos passassem. Também é muito estranho ver pacotes fora de ordem em uma rede de salto único.

Você tem acesso a um analisador de espectro, como o Metageek Wi-Spy ? Se você estiver usando a banda de 2,4 GHz, o Wi-Spy 2.4i de US $ 99 é algo divertido de se ter, e muito útil para ver se o forno de microondas do seu vizinho está batendo a banda inteira por vários segundos de cada vez.

A propósito, faça um ifconfig en1 e certifique-se de não ver PROMISC na lista de sinalizadores de interface. Algumas placas sem fio não lidam muito bem com o modo promíscuo. Mesmo que você não execute coisas como tcpdump e Wireshark , aplicações de rede às vezes mal escritas acidentalmente configuram o modo promscuous quando não pretendiam, porque faziam chamadas erradas para libpcap ou BPF .

  • Qual versão do Mac OS X você está executando?
  • Qual é a versão do firmware / make / model / hardware / firmware do seu ponto de acesso?
  • O firmware do seu ponto de acesso está atualizado?
  • Você tem apenas o ponto de acesso no momento ou tem vários pontos de acesso "estendendo a rede" sem fio?

Eu sei que você já tentou diferentes canais , mas você já tentou diferentes bandas ? Por exemplo, se você fez tudo isso na banda de 2,4 GHz - canais 1-11, mais talvez 12, 13 e até 14 em algumas regiões - seria interessante saber se o problema desaparece se você mudar o AP para a banda de 5 GHz (canal 36 e acima).

No Snow Leopard, você pode executar isso para habilitar muitos logs de depuração do AirPort:

sudo /usr/libexec/airportd debug +AllUserland +AllVendor +AllDriver

Em seguida, observe o que é registrado em /var/log/kernel.log e /var/log/system.log .

O Leopard não tem muito registro para isso, mas você pode ativá-lo assim:

sudo /usr/libexec/airportd -d

O Leopard não tem o kernel.log separado, então provavelmente tudo irá para system.log.

O problema desaparece quando você está conectado ao adaptador de energia CA em vez da bateria? Os laptops Mac modernos ativam automaticamente o modo de economia de energia do 802.11 quando estão na bateria. O modo de poupança de energia pode aumentar a latência alguns ; geralmente na ordem de 100 ms, nem mesmo um segundo completo. Mas ainda assim seria interessante saber se o funcionamento da energia AC faz diferença.

    
por 08.04.2010 / 02:33