It seems that the orginal for this thread is becoming confused.
The initial problem is that many 2013 Macbook Airs regularly drop their wifi connection using the original .22 wifi driver. Many Macbook Airs worked flawlessly and didn't have a wifi problem.
Mac put out an update supposedly to fix the problem. The fix was a "fudge" with the computer recognising the wifi had dropped out and the update told the computer to reconnect. The fix did not address the orginal problem of the wifi dropping out.
In introducing this "fix" Apple created a futher problem of latency, identified and very well explained by headcase who has made a major contribution to this thread. Latency is identified by looking at the ping times.
The update has been included in the latest Mac OS update. Does this mean that now all new Macbook Airs have latency problems instead of the previous situation in which only some Macbook Airs had disconnection problems?
Newcomers to this thread may think that the latency issue is the fundamental problem, we need to make sure that the orginal problem is not forgotten.
We can assume that rolling back to the orginal .22 driver will fix the new latency problem but will return us to some Macbook Airs having disconnection problems.
It is highly probable that Apple are struggling to find a solution.
I just read your post about your recent success using IOGear's USB WIFI device -- good pings, connectivity, etc. (I can't find your original message, although it came to my email). Please could you tell us which version of the OS (10.8.4? or 10.8.5? with the 'supplement' or not?) and the MBA WIFI driver you are currently using with the IOGear? These details might help some people who are trying to figure out what to do until the Apple fix for the chip or software appears. Thank you very much. (PS I note that the supplement put out to tweak 10.8.5 several days ago includes something designed for Bluetooth issues, if I recall correctly.)
This is a link to my original post:
I am using the latest IOGear driver v2.0.1 from here:
I am using the latest OS X 10.8.5 with the supplement that was released a couple of days ago.
Please note the IOGear solution works for my environment (at my work and home using Draytek routers and an Airport Express). I cannot guarantee the IOGear will work perfectly with every router. Having said that it has performed flawlessly.
Purchased the IOGear wireless N USB device and can confirm that the results (at least from a Ping test perspective) is much better and more stable than the built in wifi
Results, which is in line with the results Anorax1 posted previously
PING 192.168.1.254 (192.168.1.254): 56 data bytes
64 bytes from 192.168.1.254: icmp_seq=0 ttl=64 time=1.338 ms
64 bytes from 192.168.1.254: icmp_seq=1 ttl=64 time=1.282 ms
64 bytes from 192.168.1.254: icmp_seq=2 ttl=64 time=1.553 ms
64 bytes from 192.168.1.254: icmp_seq=3 ttl=64 time=1.205 ms
64 bytes from 192.168.1.254: icmp_seq=4 ttl=64 time=1.801 ms
64 bytes from 192.168.1.254: icmp_seq=5 ttl=64 time=1.182 ms
64 bytes from 192.168.1.254: icmp_seq=6 ttl=64 time=1.532 ms
64 bytes from 192.168.1.254: icmp_seq=7 ttl=64 time=1.195 ms
64 bytes from 192.168.1.254: icmp_seq=8 ttl=64 time=2.860 ms
64 bytes from 192.168.1.254: icmp_seq=9 ttl=64 time=1.333 ms
64 bytes from 192.168.1.254: icmp_seq=10 ttl=64 time=1.194 ms
64 bytes from 192.168.1.254: icmp_seq=11 ttl=64 time=2.393 ms
64 bytes from 192.168.1.254: icmp_seq=12 ttl=64 time=1.383 ms
64 bytes from 192.168.1.254: icmp_seq=13 ttl=64 time=1.660 ms
64 bytes from 192.168.1.254: icmp_seq=14 ttl=64 time=1.683 ms
64 bytes from 192.168.1.254: icmp_seq=15 ttl=64 time=5.154 ms
64 bytes from 192.168.1.254: icmp_seq=16 ttl=64 time=1.475 ms
64 bytes from 192.168.1.254: icmp_seq=17 ttl=64 time=1.711 ms
64 bytes from 192.168.1.254: icmp_seq=18 ttl=64 time=1.481 ms
64 bytes from 192.168.1.254: icmp_seq=19 ttl=64 time=2.723 ms
PING 192.168.1.254 (192.168.1.254): 56 data bytes
64 bytes from 192.168.1.254: icmp_seq=0 ttl=64 time=1.227 ms
64 bytes from 192.168.1.254: icmp_seq=1 ttl=64 time=1.364 ms
64 bytes from 192.168.1.254: icmp_seq=2 ttl=64 time=27.872 ms
64 bytes from 192.168.1.254: icmp_seq=3 ttl=64 time=1.229 ms
64 bytes from 192.168.1.254: icmp_seq=4 ttl=64 time=4.781 ms
64 bytes from 192.168.1.254: icmp_seq=5 ttl=64 time=1.390 ms
64 bytes from 192.168.1.254: icmp_seq=6 ttl=64 time=17.070 ms
64 bytes from 192.168.1.254: icmp_seq=7 ttl=64 time=39.778 ms
64 bytes from 192.168.1.254: icmp_seq=8 ttl=64 time=67.669 ms
64 bytes from 192.168.1.254: icmp_seq=9 ttl=64 time=70.245 ms
64 bytes from 192.168.1.254: icmp_seq=10 ttl=64 time=5.908 ms
64 bytes from 192.168.1.254: icmp_seq=11 ttl=64 time=6.577 ms
64 bytes from 192.168.1.254: icmp_seq=12 ttl=64 time=51.708 ms
64 bytes from 192.168.1.254: icmp_seq=13 ttl=64 time=74.441 ms
64 bytes from 192.168.1.254: icmp_seq=14 ttl=64 time=102.199 ms
Request timeout for icmp_seq 15
Request timeout for icmp_seq 16
Request timeout for icmp_seq 17
64 bytes from 192.168.1.254: icmp_seq=15 ttl=64 time=3075.222 ms
64 bytes from 192.168.1.254: icmp_seq=16 ttl=64 time=2077.145 ms
64 bytes from 192.168.1.254: icmp_seq=17 ttl=64 time=1076.035 ms
64 bytes from 192.168.1.254: icmp_seq=19 ttl=64 time=15.653 ms
For the meantime until Apple fixes this issue, I'll have this device handy as a workaround. Purchased for around AUD 35, its acceptable
AllThingsD is reporting that Apple is holding an iPad event on Tuesday, October 22. Apparently, the focus of the event will be not only iPads, but also new Mac Pros and OS X Mavericks.
AllThingsD has a pretty good track record with these things—it correctly predicted the date of the iPhone event last month, so new iPads on the 22nd are probably a safe bet.
I received my first replacement Air last friday, and the first thing I did was erased it and reinstalled it and updated it to the most current version. I specifically did not tweak any WiFi drivers. Now I get the irregular and long ping times to my router, but it has never dropped a connection (that I've noticed, at least: I haven't yet been pinging for hours at a time. Note to self: do that). Also my TimeMachine backups happen regularly and without any problems. Screen sharing to my Mac Mini never hangs. Network drives stay mounted and available.
Today I tested it at the office and at the mall, and it could connect to WiFi networks my previous Air could not connect to (no security at the mall and WEP at the office). I still can't connect to the WPA Enterprise network at the office, but even some other devices have problems with that one, so I can't conclusively say anything about that.
However, at these locations, I didn't test the old MBA with exactly the same OS version/driver setup as with the curent MBA, so I can't really say for sure if they would behave differently having all the same updates installed. I guess I could temporarily do the .22 -tweak on my new MBA and see what happens, but currently I'm quite happy with how things are, although there is a slight feeling of it not being quite complete yet.
I've been wondering, though: does the long ping time as such really matter? I've noticed it goes down to around 1 ms when there's a lot of network traffic (as noted elsewhere in the thread), so does it really have any noticeable effect on my network experience? Is there any chance it could be a power-saving feature? I assume not, but would it make sense?
But in any case, it looks like I won't be returning this one.
Yes, for eg.it can effect RDP and VOIP. Presuming it drops into powersave mode a bit too quickly when traffic is low, and then can't pick up again quickly enough to keep up the with the traffic. Eg. voip can be great, but then can start stuttering after a random amount of time. This is using the same network as a macbook pro which doesn't exhibit the same problem at all.
Of interest, has anyone tried Windows 8.1 or Mavericks to see if the problem is resolved with the updated drivers in these systems?
If indeed the Broadcom chip is being forced into power saving mode constantly I'd rather not have this "feature" at the expense of wifi stability. At the very least Apple should offer an option to turn off aggressive power saving. As some others have pointed out installing Windows bootcamp results in ultra-low pings and a stable wifi connection with the built-in chip. This should be the norm.
If this was Apple's way of achieving the much lauded 12 hour battery time well I think they need to go back to the drawing board. I shouldn't have to be forced to use an external wifi USB to achieve a stable connection as a workaround simply to allow Apple to achieve their operating specifications.