Q: New Macbook Air - wifi connectivity problems

It appears my wifi adapter on my new retina macbookpro is falling asleep if not used at an interval of less than a second.  I think this is exactly the latency issue i've been seeing when connecting to remote terminals.  The more remote shells I run the less this seems to be an issue.  However one remote ssh connection is not enough to keep the wifi adapter from going into some sort of sleep mode.  Below are the results of pinging at a 0.2 sec (200ms) interval vs pinging at a 1s (1000ms) interval.

ping -i 0.2 192.168.1.1

PING 192.168.1.1 (192.168.1.1): 56 data bytes

64 bytes from 192.168.1.1: icmp_seq=0 ttl=64 time=38.522 ms

64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=1.136 ms

64 bytes from 192.168.1.1: icmp_seq=2 ttl=64 time=1.149 ms

64 bytes from 192.168.1.1: icmp_seq=3 ttl=64 time=1.075 ms

64 bytes from 192.168.1.1: icmp_seq=4 ttl=64 time=1.156 ms

64 bytes from 192.168.1.1: icmp_seq=5 ttl=64 time=1.025 ms

64 bytes from 192.168.1.1: icmp_seq=6 ttl=64 time=1.139 ms

64 bytes from 192.168.1.1: icmp_seq=7 ttl=64 time=1.166 ms

64 bytes from 192.168.1.1: icmp_seq=8 ttl=64 time=1.195 ms

64 bytes from 192.168.1.1: icmp_seq=9 ttl=64 time=1.059 ms

64 bytes from 192.168.1.1: icmp_seq=10 ttl=64 time=1.133 ms

64 bytes from 192.168.1.1: icmp_seq=11 ttl=64 time=1.065 ms

64 bytes from 192.168.1.1: icmp_seq=12 ttl=64 time=1.605 ms

64 bytes from 192.168.1.1: icmp_seq=13 ttl=64 time=1.638 ms

64 bytes from 192.168.1.1: icmp_seq=14 ttl=64 time=1.224 ms

64 bytes from 192.168.1.1: icmp_seq=15 ttl=64 time=1.076 ms

64 bytes from 192.168.1.1: icmp_seq=16 ttl=64 time=1.026 ms

64 bytes from 192.168.1.1: icmp_seq=17 ttl=64 time=1.169 ms

64 bytes from 192.168.1.1: icmp_seq=18 ttl=64 time=1.128 ms

64 bytes from 192.168.1.1: icmp_seq=19 ttl=64 time=1.760 ms

64 bytes from 192.168.1.1: icmp_seq=20 ttl=64 time=1.112 ms

64 bytes from 192.168.1.1: icmp_seq=21 ttl=64 time=1.051 ms

64 bytes from 192.168.1.1: icmp_seq=22 ttl=64 time=1.255 ms

64 bytes from 192.168.1.1: icmp_seq=23 ttl=64 time=1.055 ms

64 bytes from 192.168.1.1: icmp_seq=24 ttl=64 time=1.117 ms

64 bytes from 192.168.1.1: icmp_seq=25 ttl=64 time=1.173 ms

64 bytes from 192.168.1.1: icmp_seq=26 ttl=64 time=1.126 ms

64 bytes from 192.168.1.1: icmp_seq=27 ttl=64 time=1.289 ms

64 bytes from 192.168.1.1: icmp_seq=28 ttl=64 time=1.153 ms

64 bytes from 192.168.1.1: icmp_seq=29 ttl=64 time=1.255 ms

64 bytes from 192.168.1.1: icmp_seq=30 ttl=64 time=0.975 ms

64 bytes from 192.168.1.1: icmp_seq=31 ttl=64 time=1.114 ms

64 bytes from 192.168.1.1: icmp_seq=32 ttl=64 time=1.672 ms

64 bytes from 192.168.1.1: icmp_seq=33 ttl=64 time=1.598 ms

64 bytes from 192.168.1.1: icmp_seq=34 ttl=64 time=1.153 ms

vs

ping -i 1 192.168.1.1

PING 192.168.1.1 (192.168.1.1): 56 data bytes

64 bytes from 192.168.1.1: icmp_seq=0 ttl=64 time=259.458 ms

64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=180.414 ms

64 bytes from 192.168.1.1: icmp_seq=2 ttl=64 time=100.878 ms

64 bytes from 192.168.1.1: icmp_seq=3 ttl=64 time=22.095 ms

64 bytes from 192.168.1.1: icmp_seq=4 ttl=64 time=249.786 ms

64 bytes from 192.168.1.1: icmp_seq=5 ttl=64 time=170.507 ms

64 bytes from 192.168.1.1: icmp_seq=6 ttl=64 time=91.480 ms

64 bytes from 192.168.1.1: icmp_seq=7 ttl=64 time=11.999 ms

64 bytes from 192.168.1.1: icmp_seq=8 ttl=64 time=1.183 ms

64 bytes from 192.168.1.1: icmp_seq=9 ttl=64 time=160.052 ms

64 bytes from 192.168.1.1: icmp_seq=10 ttl=64 time=79.727 ms

64 bytes from 192.168.1.1: icmp_seq=11 ttl=64 time=1.630 ms

64 bytes from 192.168.1.1: icmp_seq=12 ttl=64 time=35.497 ms

64 bytes from 192.168.1.1: icmp_seq=13 ttl=64 time=1.881 ms

64 bytes from 192.168.1.1: icmp_seq=14 ttl=64 time=69.822 ms

64 bytes from 192.168.1.1: icmp_seq=15 ttl=64 time=106.626 ms

64 bytes from 192.168.1.1: icmp_seq=16 ttl=64 time=130.952 ms

64 bytes from 192.168.1.1: icmp_seq=17 ttl=64 time=137.781 ms

64 bytes from 192.168.1.1: icmp_seq=18 ttl=64 time=58.795 ms

64 bytes from 192.168.1.1: icmp_seq=19 ttl=64 time=204.236 ms

64 bytes from 192.168.1.1: icmp_seq=20 ttl=64 time=207.971 ms

64 bytes from 192.168.1.1: icmp_seq=21 ttl=64 time=1.166 ms

64 bytes from 192.168.1.1: icmp_seq=22 ttl=64 time=48.795 ms

64 bytes from 192.168.1.1: icmp_seq=23 ttl=64 time=276.781 ms

64 bytes from 192.168.1.1: icmp_seq=24 ttl=64 time=197.100 ms

64 bytes from 192.168.1.1: icmp_seq=25 ttl=64 time=118.236 ms

64 bytes from 192.168.1.1: icmp_seq=26 ttl=64 time=38.446 ms

I just bought my macbook air yesterday. And the internet was so laggy it was driving me insane. After researching I stumbled on this thread and tried the device driver roll back. Now my wifi internet is fine. Hope apple fixes this driver update soon, or the hardware company that makes the wifi card, it certainly was an annoyance.

Oh and since I just bought this MBA, it came with Mavericks installed. the .22 driver version works just fine and once I followed the instructions on page 105, after the reboot, connectivity speed I would expect off an $1,100 machine.

My MBA 2013 have the same wifi ping latency issues. Even the local apple authorized service center has been replace my wifi network card and the mother board. But my wifi issues still exist.

ast login: Tue Jan  7 22:12:40 on console

localhost:~ mingjiantsai$ ping 192.168.1.1

PING 192.168.1.1 (192.168.1.1): 56 data bytes

64 bytes from 192.168.1.1: icmp_seq=0 ttl=64 time=2.130 ms

64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=1.638 ms

64 bytes from 192.168.1.1: icmp_seq=2 ttl=64 time=1.756 ms

64 bytes from 192.168.1.1: icmp_seq=3 ttl=64 time=59.867 ms

64 bytes from 192.168.1.1: icmp_seq=4 ttl=64 time=114.824 ms

64 bytes from 192.168.1.1: icmp_seq=5 ttl=64 time=112.540 ms

64 bytes from 192.168.1.1: icmp_seq=6 ttl=64 time=107.536 ms

64 bytes from 192.168.1.1: icmp_seq=7 ttl=64 time=50.587 ms

64 bytes from 192.168.1.1: icmp_seq=8 ttl=64 time=100.301 ms

64 bytes from 192.168.1.1: icmp_seq=9 ttl=64 time=96.800 ms

64 bytes from 192.168.1.1: icmp_seq=10 ttl=64 time=92.872 ms

64 bytes from 192.168.1.1: icmp_seq=11 ttl=64 time=39.900 ms

64 bytes from 192.168.1.1: icmp_seq=12 ttl=64 time=85.387 ms

64 bytes from 192.168.1.1: icmp_seq=13 ttl=64 time=81.840 ms

64 bytes from 192.168.1.1: icmp_seq=14 ttl=64 time=78.083 ms

64 bytes from 192.168.1.1: icmp_seq=15 ttl=64 time=27.850 ms

64 bytes from 192.168.1.1: icmp_seq=16 ttl=64 time=70.947 ms

64 bytes from 192.168.1.1: icmp_seq=17 ttl=64 time=66.805 ms

64 bytes from 192.168.1.1: icmp_seq=18 ttl=64 time=0.967 ms

64 bytes from 192.168.1.1: icmp_seq=19 ttl=64 time=16.817 ms

64 bytes from 192.168.1.1: icmp_seq=20 ttl=64 time=53.600 ms

64 bytes from 192.168.1.1: icmp_seq=21 ttl=64 time=49.638 ms

64 bytes from 192.168.1.1: icmp_seq=22 ttl=64 time=45.006 ms

64 bytes from 192.168.1.1: icmp_seq=23 ttl=64 time=5.381 ms

64 bytes from 192.168.1.1: icmp_seq=24 ttl=64 time=36.904 ms

64 bytes from 192.168.1.1: icmp_seq=25 ttl=64 time=32.855 ms

64 bytes from 192.168.1.1: icmp_seq=26 ttl=64 time=29.390 ms

64 bytes from 192.168.1.1: icmp_seq=27 ttl=64 time=1.028 ms

64 bytes from 192.168.1.1: icmp_seq=28 ttl=64 time=21.175 ms

64 bytes from 192.168.1.1: icmp_seq=29 ttl=64 time=17.236 ms

64 bytes from 192.168.1.1: icmp_seq=30 ttl=64 time=1.926 ms

^C

--- 192.168.1.1 ping statistics ---

31 packets transmitted, 31 packets received, 0.0% packet loss

round-trip min/avg/max/stddev = 0.967/48.503/114.824/36.972 ms

         After compare the ping response time between 3 x MBA 2013 with the MBP 2012, I found that the MBP 2012's ping response time always lower than 1 ms and very stable not like the other MBA 2013.

blite wrote:

 

It appears my wifi adapter on my new retina macbookpro is falling asleep if not used at an interval of less than a second.  I think this is exactly the latency issue i've been seeing when connecting to remote terminals.  The more remote shells I run the less this seems to be an issue.  However one remote ssh connection is not enough to keep the wifi adapter from going into some sort of sleep mode.  Below are the results of pinging at a 0.2 sec (200ms) interval vs pinging at a 1s (1000ms) interval.

I do a lot of ssh connection from my air. ssh is very low in traffic almost invisible that is why so good for remote access a server/computer. In my experience more traffic you generate faster the connection will be. Do file transfer and you will see real figures and you also will see improvement on the ping times. There are loads of people complaining about this, but I don't see it as an issue. The connection is stable, fast when it needs to be and not disconnecting at all and that is what is most impotrant for ssh/telnet and many other app. Ping is not a reliable way to check connection anyway, all it confirms there is some kind of connection.

attiland wrote:

 

Ping is not a reliable way to check connection anyway, all it confirms there is some kind of connection.

Ping is used for two purposes here: to keep the wireless card awake for low latency (one of the issues that needs to be fixed by Apple, I'm waiting for around 6 months now), and secondly to display the actual round trip latency.

The ping latency results accurately represent the latency experienced by an SSH user when pressing a key and waiting for the response from the server.

richard_vd wrote:

 

 

attiland wrote:

 

Ping is not a reliable way to check connection anyway, all it confirms there is some kind of connection.

 

Ping is used for two purposes here: to keep the wireless card awake for low latency (one of the issues that needs to be fixed by Apple, I'm waiting for around 6 months now), and secondly to display the actual round trip latency.

 

The ping latency results accurately represent the latency experienced by an SSH user when pressing a key and waiting for the response from the server.

Yes you are right in ssh you might have to wait for the first caracter to be displayed longer than on a desktop, but after the first key I never seen the lag in SSH. As I said before I don't really see it as a big deal. Of course any improvement is welcomed.

To me the 12 hour battery means I can go around server rooms all day long, without charge and if I have to wait 200ms more before I see what I have type in the console while I have long battery life that is acceptable as long my SSH session doesn't break, because that could do harm. I think for many of the users the best solution would be if you could just set when the chipset goes to sleep, so we culd ballance out what is our personal need. To be honest probably I would keep te settings as it is even if I would have a facility to change it, not to mention for critical operation you always have USB/Thundebird network cable which is cheap more stable and much faster.

The problem with wireless is that people expect it to work

attiland, you're kind of clueless as far as I can tell. richard_vd is right in that ping is used for many things one of which is latency and round trip time. this isn't 1978.

here's the problem with your logic: if, like you say, traffic is established after that first character and this improves performance then why not just have better performance from the get go? seems to me this isn't a problem inherent with wireless connectivity but in the implementation that broadcom/apple have come up wtih. why do I need to have a continuous stream of data to maintain a good, low latency ssh connection? That's just idiotic. just give it to me out of the gate. is it really saving that much power? and if it is then it's somewhat false advertising to indicate 10 hour battery life if it's not an apples to apples comparison to my 3 year old macbook which never had this problem.

So before you write back with whatever justification you have, e.g., people expecting wireless to work, desktops working better or being more suitable for network activity, _you_ not seeing it as a big deal, etc, etc, think for a second what you're providing to the discussion. forums aren't really for opionions - this is a place for suggesting fixes, validating issues/problems that others have, providing workarounds.

attiland wrote:

To me the 12 hour battery means I can go around server rooms all day long, without charge and if I have to wait 200ms more before I see what I have type in the console while I have long battery life that is acceptable

If Apple were to fix this in the BCM4360 driver, the impact on battery life would be second to none. I think of this latency issue now more as a silly mistake (bug) rather than a smart way to save power.

I installed the background service (described earlier in this thread) that keeps pinging Google's DNS every 200 ms, and I don't even notice the impact on battery life, even though this workaround must have a much higher overhead compared to a proper driver fix by Apple. The impact of this workaround on perceived latency is huge for me in my daily use of the MBA.

ekeyser wrote:

 

attiland, you're kind of clueless as far as I can tell. richard_vd is right in that ping is used for many things one of which is latency and round trip time. this isn't 1978.

 

So you are aware of why ping is not the best tool to test it

ekeyser wrote:

here's the problem with your logic: if, like you say, traffic is established after that first character and this improves performance then why not just have better performance from the get go?

This is just an opinion too. So here is mine. Why would you generate traffic when you don't use it. Oh are you on about faster wake up time. Yes that would be nice.

is it really saving that much power?

Aperently it does. Most of the people know wireless is consuming a lot of enery. Read up on it.

it's not an apples to apples comparison to my 3 year old macbook which never had this problem.

10 years ago I had a car with no onboard computer. The current one has one and guess what; I had issue with it. It is also irrelevant.

ekeyser wrote:

 

 

So before you write back with whatever justification you have, e.g., people expecting wireless to work, desktops working better or being more suitable for network activity, _you_ not seeing it as a big deal, etc, etc, think for a second what you're providing to the discussion. forums aren't really for opionions - this is a place for suggesting fixes, validating issues/problems that others have, providing workarounds.

This is just arrogant.

PS: I have added my solution to the problem when there was one. By the way latency is off-topic in this discussion as been mentioned before. And reread my post many times, so you can see what I am suggesting. Now read it again because you have missed it again

Have a nice day

richard_vd wrote:

 

If Apple were to fix this in the BCM4360 driver, the impact on battery life would be second to none. I think of this latency issue now more as a silly mistake (bug) rather than a smart way to save power.

I hope you are right, and it is something can be improved. But you and me and others here are just guessing, since no sourcecode been seen.

Tell me how your workaround improved the connecton? When I do file transfer it is fast. when I do SSH it is also fast enough for my needs.What I see is the connection is not droping and the speed suites the need.

Was your connection droping before applied your workaround?

Can we please just drop it and agree that there's a problem—which manifests itself in different ways for different people—and it needs a solution?

For me, the (random) latency kills me—I work via SSH and with intermittent network protocols all day, and the random dropouts (sometimes), bluetooth interference (sometimes), mixed-mode network problems (sometimes), and other weird problems all add up to me detesting the built-in WiFi on my almost-new MacBook Air.

I use four different Macs day-to-day, and all are running Mavericks. Only the Air has any issues at all. Something's wrong with it, someday I hope it's fixed .

For those who think there is no problem:

First, It has also been reported Wifi Disconnections, and also difficulties to connect.

And Last, PING, try to play a videogame with this driver...

APPLE listen this:

*****

Is this a useless and inappriopriate comment? no, it's only the true.

<Edited by Host>

Jeff Geerling wrote:

 

For me, the (random) latency kills me—I work via SSH and with intermittent network protocols all day, and the random dropouts (sometimes), bluetooth interference (sometimes), mixed-mode network problems (sometimes), and other weird problems all add up to me detesting the built-in WiFi on my almost-new MacBook Air.

Yes Jeff it's a good point that there are multiple sources of high latency. The ones I have identified so far:

• idle traffic -> latency up to a few hundred ms -> workaround is to keep the traffic flowing at all times, see the post on page 125 by dliang
• bluetooth -> latency, and easily halves your download speed on 2.4 GHz -> my workaround is to install the Airport Extreme 802.11ac and solely connect to 5 GHz Wi-Fi.
• clicking on the Wi-Fi icon in the menu bar -> initiates Wi-Fi AP scanning which is very very slow on 5 GHz (latency spikes of 2000 ms)
• using AirDrop -> initiates Wi-Fi AP scanning. Don't leave a Finder window open on AirDrop if you're not using it, result is very high latency!
• Find My Mac -> initiates Wi-Fi AP scanning when it's updating your location
• Airport Utility -> initiates W-Fi AP scanning and sends bursts of IP broadcasts
• low signal levels -> 802.11ac at low signal rates (around 100 Mbit or less) will initiate continuous Wi-Fi AP scanning, which is so slow that the resulting 2000ms latency totally destroys an otherwise still usable connection!

anuone else is having problem with internet while your external hdd is connected? on the left usb internet is working but on the right usb its just stops right away and when i disconnect hdd its come back right away,i test both usb port with several others usb devices both works perfectly just have problem with usb 3 external hdd??? lion 10.8.5