Q: New Macbook Air - wifi connectivity problems

OK, rolled back the Broadcom firmware to *****22, otherwise all 10.8.5.

Ping times now fine! Thanks headcase.

--- 192.168.100.1 ping statistics ---

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

round-trip min/avg/max/stddev = 1.686/5.124/14.990/2.654 ms

Hmmm... It sounds like a problem of the power management system, I mean, the power saving. It could be, I do not know.

I think that the wifi drops are a hardware problem, and the bad pings are a software problem related to the power saving features, maybe something to do with the new Haswell technology.

Cloudi, did you realize of your bad pings only after using the computer after sleep? Did you try rebooting it and then trying again the ping test?

As others have stated, ping times return to normal if there is something that is using the connection in the same time (eg: YouTube, download, etc).

@ Cloudi

Last night , is it possible you had something like that in the background ? Something like Dropbox, or a TimeMachine via wifi, or whatever? 

Cloudi -

With all sincerity, let me say I'm sorry to hear that your first test with 10.8.5 was an anomoly and you needed to roll back to the original .22 driver too.  But alas, I believe the latency bug introduced on the subsequent drivers is real and impacts everyone.  I'll keep folks posted on what I hear from my reaching out to Apple network engineers.

words cannot convey how disappointing after 10.8.5 rollout.  Did Apple engineers really not read this forum or pay attention to all the returns/exchanges?  3 months from the first reports to address this issue in the new update?  More and more this seems a hardware issue that cannot be fixed by firmware updates.

Honestly, it's disgraceful Mr. Cook has not acknowledged the problem by now.

APPLE - PLEASE FIX THE PROBLEM.

"APPLE -  PLEASE FIX THIS PROBLEM"

Sorry to tell you, but Apple is busy colecting fingerprints and it doesn't give a..... "apple" about our ping values. 

---

Troll.

<harsh>if you people had returned all the junk piece of metal you so happily agreed to pay $2000, may they would have already fixed it</harsh>

And no, this is not trolling. It's a very basic market rule that for some reason people think doesn't apply to Apple.

I am still waiting for rMBP to see if it has the same wifi issue before buying the mba.

Fair enough, eppes.  Anyone is certainly entitled to return a product they aren't satisfied with, irrespective of the vendor, and I will retract my Troll comment.

Btw, let me try to debunk a few comments some have made here in the past...

a) "This MBA ***** because Apple QA is going down hill!"  As I said before on this support thread, you can go back many years on this support forum and elsewhere on the web, and you will see various wireless networking bugs being referenced upon the release of a new Mac, new WiFi radio, or new OS X build.  Heck, to that very point, my recent lengthy post on the rollback steps are literally the same steps folks have used on previous Macs in previous support threads.  For better or worse, this is NOT a new trend.  Go look for yourself if you don't believe me.  But more importantly, its well known in the industry that frequent WiFI issues like this are not exclusive to vendors such as Apple and Broadcom, given the wireless networking industry still has a long ways to evolve to be anywhere on par with wired networking, both in terms of reliability and performance (the scope of which goes well beyond this thread).

b) "They'll never fix this problem because its definately a hardware issue!"  Per my recent comments, this is pure speculation by users, and the reality is that Apple and Broadcom engineers are best equipped so source the primary culprit(s) and best resolution.  To each their own, but I'd say spending cycles speculating on whether some dude in China in banging his hammer improperly on some MBA logic boards rolling down the assembly line or "xxxxxxxxxxx has to be the reason", is primarily a waste of time.  For me, trying to remedy or mitigate based on what's in my span of control (my network, my devices / OS / apps / drivers), along with what I know or what I can learn, is seemingly a better use of time.

c) "Apple doesn't care!"  Based on interactions at my company (Cisco) with Apple's engineers, I believe that Apple tries to address documented bugs in a meaningful way like most other IT vendors.  Yes, I've seen some instances where they make it clear that "Network defect #134432 will not be resolved in the next release", etc, but I think the severity and persistency of this latency bug in the last two MBA driver updates will require a fix by Apple in the near term, in concert with the disconnect bug fix they pushed out for some MBA owners.

All that said, am I content with my 2013 MBA?  Absolutely - like the reviews have said from its release, this model is an awesome mix of features and performance, and I would still recommend it to others without hesitation.  Do I wish this latest AC chip from Broadcom work seamlessly with other mobile devices and do I wish Apple and Broadcom had this resolved already?  Of course.  But I'm also a realist who puts this in the context of where the technology is, and where it isn't, at this point in time.

No.

No.

Thanks.

I've done the OS X 10.8.5 combo update and it is of course having the same problems as the .35 driver did.

However I'm sad to report that after rolling back to .22 I continue to have exceedingly bad ping problems:

64 bytes from 192.168.0.1: icmp_seq=170 ttl=255 time=1.566 ms

64 bytes from 192.168.0.1: icmp_seq=171 ttl=255 time=2.887 ms

64 bytes from 192.168.0.1: icmp_seq=172 ttl=255 time=2.505 ms

64 bytes from 192.168.0.1: icmp_seq=173 ttl=255 time=3.355 ms

64 bytes from 192.168.0.1: icmp_seq=174 ttl=255 time=1.354 ms

64 bytes from 192.168.0.1: icmp_seq=175 ttl=255 time=1.336 ms

64 bytes from 192.168.0.1: icmp_seq=176 ttl=255 time=1.554 ms

64 bytes from 192.168.0.1: icmp_seq=177 ttl=255 time=1.633 ms

64 bytes from 192.168.0.1: icmp_seq=178 ttl=255 time=2.655 ms

64 bytes from 192.168.0.1: icmp_seq=179 ttl=255 time=1.483 ms

64 bytes from 192.168.0.1: icmp_seq=180 ttl=255 time=3.474 ms

64 bytes from 192.168.0.1: icmp_seq=181 ttl=255 time=2.608 ms

64 bytes from 192.168.0.1: icmp_seq=182 ttl=255 time=2.726 ms

64 bytes from 192.168.0.1: icmp_seq=183 ttl=255 time=2.948 ms

64 bytes from 192.168.0.1: icmp_seq=184 ttl=255 time=3.214 ms

64 bytes from 192.168.0.1: icmp_seq=185 ttl=255 time=0.968 ms

64 bytes from 192.168.0.1: icmp_seq=187 ttl=255 time=1.528 ms

64 bytes from 192.168.0.1: icmp_seq=188 ttl=255 time=41.104 ms

Request timeout for icmp_seq 189

64 bytes from 192.168.0.1: icmp_seq=189 ttl=255 time=1953.608 ms

64 bytes from 192.168.0.1: icmp_seq=190 ttl=255 time=952.555 ms

64 bytes from 192.168.0.1: icmp_seq=191 ttl=255 time=1952.998 ms

64 bytes from 192.168.0.1: icmp_seq=192 ttl=255 time=951.939 ms

64 bytes from 192.168.0.1: icmp_seq=193 ttl=255 time=117.030 ms

64 bytes from 192.168.0.1: icmp_seq=194 ttl=255 time=951.039 ms

64 bytes from 192.168.0.1: icmp_seq=195 ttl=255 time=1950.731 ms

64 bytes from 192.168.0.1: icmp_seq=196 ttl=255 time=949.546 ms

64 bytes from 192.168.0.1: icmp_seq=197 ttl=255 time=113.968 ms

64 bytes from 192.168.0.1: icmp_seq=198 ttl=255 time=1.720 ms

64 bytes from 192.168.0.1: icmp_seq=199 ttl=255 time=2.803 ms

64 bytes from 192.168.0.1: icmp_seq=200 ttl=255 time=1.230 ms

64 bytes from 192.168.0.1: icmp_seq=201 ttl=255 time=3.345 ms

64 bytes from 192.168.0.1: icmp_seq=202 ttl=255 time=2.940 ms

Hi orchetect !

Sorry to hear that.

Did your MBA WiFi work OK originally?

Mine did.  Since the roll-back to *****22 after updating to 10.8.5, my pings are fine again.

Why would that be?