Skip navigation

New Macbook Air - wifi connectivity problems

444160 Views 2,047 Replies Latest reply: Apr 14, 2014 1:09 PM by Garryatco RSS Branched to a new discussion.
  • blite Calculating status...
    Currently Being Moderated
    Jan 4, 2014 6:16 AM (in response to spekkie)

    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

  • bvannorman Level 1 Level 1 (0 points)
    Currently Being Moderated
    Jan 5, 2014 3:18 AM (in response to blite)

    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.

  • mingjiantsai Calculating status...
    Currently Being Moderated
    Jan 7, 2014 6:30 AM (in response to vhkim)

    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.

  • attiland Level 1 Level 1 (0 points)
    Currently Being Moderated
    Jan 7, 2014 7:37 AM (in response to blite)

    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.

  • richard_vd Level 1 Level 1 (0 points)
    Currently Being Moderated
    Jan 7, 2014 8:27 AM (in response to attiland)

    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.

  • attiland Level 1 Level 1 (0 points)
    Currently Being Moderated
    Jan 7, 2014 9:02 AM (in response to richard_vd)

    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

  • ekeyser Calculating status...
    Currently Being Moderated
    Jan 7, 2014 9:24 AM (in response to attiland)

    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.

  • richard_vd Level 1 Level 1 (0 points)
    Currently Being Moderated
    Jan 7, 2014 9:27 AM (in response to attiland)

    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.

  • attiland Level 1 Level 1 (0 points)
    Currently Being Moderated
    Jan 7, 2014 10:00 AM (in response to ekeyser)

    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

  • attiland Level 1 Level 1 (0 points)
    Currently Being Moderated
    Jan 7, 2014 10:08 AM (in response to richard_vd)

    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?

  • Jeff Geerling Level 6 Level 6 (11,100 points)
    Currently Being Moderated
    Jan 7, 2014 10:33 AM (in response to attiland)

    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 .

  • jaimehrubiks Level 1 Level 1 (0 points)
    Currently Being Moderated
    Jan 7, 2014 10:56 AM (in response to Jeff Geerling)

    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...

  • andQlimax Level 1 Level 1 (0 points)
    Currently Being Moderated
    Jan 7, 2014 11:11 AM (in response to vhkim)

    APPLE listen this:

     

     

    Windows F U C K the world!!!

     

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

  • richard_vd Level 1 Level 1 (0 points)
    Currently Being Moderated
    Jan 7, 2014 3:11 PM (in response to Jeff Geerling)

    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!
  • vigorito Calculating status...
    Currently Being Moderated
    Jan 9, 2014 1:36 PM (in response to richard_vd)

    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

Actions

More Like This

  • Retrieving data ...

Bookmarked By (72)

Legend

  • This solved my question - 10 points
  • This helped me - 5 points
This site contains user submitted content, comments and opinions and is for informational purposes only. Apple disclaims any and all liability for the acts, omissions and conduct of any third parties in connection with or related to your use of the site. All postings and use of the content on this site are subject to the Apple Support Communities Terms of Use.