Why does my MacBook Pro have long ping times over Wi-Fi?

Question

I have been having problems connecting with my Wi-Fi. It is weird, the ping times to the router (<30 feet away) seem to surge, often getting over 10 seconds before slowly coming back down. You can see the trend below. I'm on a MacBook Pro and have done the normal stuff (reset the PRAM and SMC, changed wireless channels, etc.). It happens across different routers, so I think it must be my laptop, but I don't know what it could be.

The RSSI value hovers around -57, but I've seen the transmit rate flip between 0, 48 and 54. The signal strength is ~60% with 9% noise. Currently, there are 17 other wireless networks in range, but only one in the same channel.

1 - How can I figure out what's going on?
2 - How can I correct the situation?

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  

Answer 1

In earlier Mac laptops it was easy to get at the wifi card (just under the easily-opened keyboard), I don't know whether this is still true.

If it is, I'd recommend unplugging and replugging the connector to that card. In years past, others had problems like this that were solved by reseating that connector.

Answer 2

That ping output is crazy. It's like nothing gets through for 16-18 seconds, and then suddenly it all comes through at once. Even if there were problems with 802.11n frame aggregation and Block Acks, I wouldn't expect everything to get queued and stay queued for 18 seconds and then suddenly all come through. It's also very strange to see out-of-order packets on a single-hop network.

Do you have access to a spectrum analyzer, such as a Metageek Wi-Spy? If you're using the 2.4 GHz band, the $99 Wi-Spy 2.4i is fun thing to have, and very useful for seeing if your neighbor's microwave oven is knocking out the entire band for several seconds at a time.

By the way, do an ifconfig en1 and make sure you don't see PROMISC in the list of interface flags. Some wireless cards don't handle promiscuous mode very well. Even if you don't run things like tcpdump and Wireshark, sometimes poorly written network applications will accidentally set promscuous mode when they didn't really mean to, because they made the wrong calls to libpcap or BPF.

• What version of Mac OS X are you running?
• What's the make/model/hardware-revision/firmware-version of your access point?
• Is the firmware on your access point up to date?
• Do you just have the one access point at this time, or do you have multiple APs "extending the network" wirelessly?

I know you've tried different channels, but have you tried different bands? For instance, if you've been doing this all in the 2.4 GHz band -- channels 1-11, plus perhaps 12, 13, and even 14 in some regions -- it would be interesting to know if the problem goes away if you switch the AP to the 5 GHz band (channel 36 and above).

On Snow Leopard, you can run this to enable lots of AirPort debug logs:

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

Then watch what gets logged to /var/log/kernel.log and /var/log/system.log.

Leopard doesn't have as much logging for this, but you can enable it like this:

sudo /usr/libexec/airportd -d

Leopard doesn't have the separate kernel.log, so it'll probably all go to system.log.

Does the problem go away when you're connected to the AC power adapter as opposed to battery? Modern Mac laptops automatically enable 802.11 powersave mode when on battery. Powersave mode can increase latency some; usually on the order of 100 ms, not even a full second. But it would still be interesting to know if running from AC power makes a difference.