Real World 802.11ac Performance Under OS X

A good friend of mine recently bought an older house and had been contemplating running a bunch of Cat6 through the crawlspace in order to get good, high-speed connectivity through his home. Pretty stoked about what I found with 802.11ac performance on the MacBook Air, I thought I came across a much easier solution to his problem. I shared my iPerf data with him, but he responded with a totally valid request: was I seeing those transfer rates in real world file copies?

I have an iMac running Mountain Lion connected over Gigabit Ethernet to my network. I mounted an AFP share on the MacBook Air connected over 802.11ac and copied a movie over.

21.2MB/s or 169.6Mbps is the fastest I saw.

Hmm. I connected the iMac to the same ASUS RT-AC66U router as the MacBook Air. Still 21.2MB/s.

I disabled all other wireless in my office. Still, no difference. I switched ethernet cables, I tried different Macs, I tried copying from a PC, I even tried copying smaller files - none of these changes did anything. At most, I only saw 21.2MB/s over 802.11ac.

I double checked my iPerf data. 533Mbps. Something weird was going on.

I plugged in Apple’s Thunderbolt Gigabit Ethernet adaptor and saw 906Mbps, clearly the source and the MacBook Air were both capable of high speed transfers.

What I tried next gave me some insight into what was going on. I setup web and FTP servers on the MacBook Air and transferred files that way. I didn’t get 533Mbps, but I broke 300Mbps. For some reason, copying over AFP or SMB shares was limited to much lower performance. This was a protocol issue.

Digging Deeper, Finding the Culprit

A major component of TCP networking, and what guarantees reliable data transmission, is the fact that all transfers are acknowledged and retransmitted if necessary. How frequently transfers are acknowledged has big implications on performance. Acknowledge (ACK) too frequently and you’ll get terrible throughput as the sender has to stop all work and wait for however long an ACK takes to travel across the network. Acknowledge too rarely on the other hand and you run the risk of doing a lot of wasted work in sub optimal network conditions. The TCP window size is a variable that’s used to define this balance.

TCP window size defines the max amount of data that can be in flight before an acknowledgement has to be sent/received. Modern TCP implementations support dynamic scaling of the TCP window in order to optimize for higher bandwidth interfaces.

If you know the round trip latency of a network, TCP window size as well as the maximum bandwidth that can be delivered over the connection you can actually calculate maximum usable bandwidth on the network.

The ratio of the network’s bandwidth-delay product to the TCP window size gives us that max bandwidth number.

The 2-stream 802.11ac in the new MacBook Air supports link rates of up to 867Mbps. My iPerf data showed ~533Mbps of usable bandwidth in the best conditions. Round trip latency over 50 ping requests between the MBA client and an iMac wired over Gigabit Ethernet host averaged 2.8ms. The bandwidth-delay product is 533Mbps x 2.8ms or 186,550 bytes. Now let’s look at the maximum usable bandwidth as a function of TCP window size:

Impact of TCP Window Size on 802.11ac Transfer Rates, 533Mbps Link, 2.8ms Latency
Window Size Bandwidth-Delay Product TCP Window/BDP Percentage Link Bandwidth Max Realized Bandwidth
32KB 186550B 32768/186550B 17.6% 533Mbps 93.6Mbps
64KB 186550B 65536/186550B 31.1% 533Mbps 187.2Mbps
128KB 186550B 131072/186550B 70.3% 533Mbps 374.5Mbps
256KB 186550B 262144/186550B 140.5% 533Mbps 533Mbps

The only way to get the full 533Mbps is by using a TCP window size that’s at least 256KB.

I re-ran my iPerf test and sniffed the packets that went by to confirm the TCP window size during the test. The results came back as expected. OS X properly scaled up the TCP window to 256KB, which enabled me to get the 533Mbps result:

I then monitored packets going by while copying files over an AFP share and found my culprit:

OS X didn’t scale the TCP window size beyond 64KB, which limits performance to a bit above what I could get over 5GHz 802.11n on the MacBook Air. Interestingly enough you can get better performance over HTTP or FTP, but in none of the cases would OS X scale TCP window size to 256KB - thus artificially limiting 802.11ac.

I spent a good amount of time trying to work around this issue, even manually setting TCP window size in OS X, but came up empty handed. I’m not overly familiar with the networking stack in OS X so it’s very possible that I missed something, but I’m confident in saying that there’s an issue here. At a risk of oversimplifying, it looks like the TCP window scaling algorithm features a hard limit in OS X’s WiFi networking stack optimized for 802.11n and unaware of ac’s higher bandwidth capabilities. I should also add that the current developer preview of OS X Mavericks doesn’t fix the issue, nor does using an Apple 802.11ac router.

The bad news is that in its shipping configuration, the new MacBook Air is capable of some amazing transfer rates over 802.11ac but you won’t see them when copying files between Macs or PCs. The good news is the issue seems entirely confined to software. I’ve already passed along my findings to Apple. If I had to guess, I would expect that we’ll see a software update addressing this.

802.11ac: 533Mbps Over WiFi Display
Comments Locked

233 Comments

View All Comments

  • arkhamasylum87 - Monday, June 24, 2013 - link

    Broadwell will have a refreshed GPU architecture and with the process shrinks, the gains would be more amenable to all. Although the intent to raise the GPU perf a decent percentage with dedicating more than the half the die is a big time change at Intel.
  • rmr - Monday, June 24, 2013 - link

    Hi Anand,

    Good review! I'm waiting for the updated review (using the i7 processor). BTW will it be possible for you to test the Air with an older 802.11g router (since some people have been complaining in the Apple forums about the Air dropping Wifi connections)? I was planning to get a new MBA but I'll be mostly using it at locations with older .11g routers.

    Thanks.

    Regards,
    rmr
  • scyap - Monday, June 24, 2013 - link

    Did the writer mention what OSX version was used for testing? Or I missed out?
    If this review was using Mountain Lion, should I expect even better battery life in Mavericks?
  • xype - Tuesday, June 25, 2013 - link

    Yes, you should. Every dev I know who runs on Mavericks reports 10-20% better battery life (that's mighty subjective and unscientific, but I am sure AnandTech will do a proper test).

    Personally I'll make use of my dev account and upgrade as soon as all the dev tools I need are confirmed a running (homebrew-installed stuff mostly).
  • Ricopolo - Tuesday, June 25, 2013 - link

    Anand, love your site. But your constant use of acronyms (like PCH, TDP, etc) that are non-household terms can be quite an obstacle to lay people, who are interested in gaining a bit of insight in tech development. Can you put together a glossary for these acronyms and put it in the footer or somewhere obvious?
    Thanks a lot.
  • SkylerSaleh - Tuesday, June 25, 2013 - link

    PCH stands for Platform Controller Hub. It provides some needed utilities required to run the CPU correctly, such as display handling, connecting peripherals, DMI, etc. As a lay-mans example, the PCH supports the CPU's operation, similar to how your subconscious supports your operation. Taking over the responsibility of semi-voluntary/non-voluntary actions like breathing, so that you can think about other things.
    TDP stands for thermal design power. It is a measurement of the maximum amount of cooling that is needed to cool a chip in its worst case. As a rule of thumb, the higher the TDP, the more power the chip will use at peak. (However this is not a good measurement of power usage when idle.)
  • name99 - Tuesday, June 25, 2013 - link

    Google shows up the obviously correct results for both of these very high in its list.
    If you want even cleaner and simpler results search on wikipedia.

    I don't want to be a dick, but part of Anand being a fairly high-end site (including, for example, the variety of technical details which make it substantially more interesting than a Macworld or The Verge or WSJ review) is that it consists of an engineering aware community, which speaks in its natural language, just like any other community.

    If you wish to be part of that community, the solution is not to complain that they use unfamiliar language, but to familiarize yourself with that language. It's not hard --- more so than ever before in the past you can learn what you need to just by scanning Google and wikipedia. And if you want to understand more details, again it's easier than its ever been before --- just look over the review articles either on this site, on Ars Technica (for the simplest introduction) or on David Kanter's Real World Tech (for the most sophisticated introductions you can probably get for free on the internet).
  • jb510 - Wednesday, June 26, 2013 - link

    Well said. It's worth noting that even some of us very technical folks have to look up a lot of terms and acronyms reading here as the spectrum of content is so broad. However, I greatly prefer the clean without reference to terms style of AT to the cumbersome reading if copy that is interrupted constantly to define things. Unless you're reading the print edition of AT, the whole internet is just one click away.
  • robco - Tuesday, June 25, 2013 - link

    The updated Airs seem pretty sweet. I use my laptop as my primary machine, so I'll probably wait for the rMBP to get updated. I'm also curious to see how well the Iris 5100 graphics compare to the HD 5000. An IPS display would have been a nice upgrade, but I can see why Apple decided to make upgrades in other areas instead.

    The WiFi snafu is interesting. I'm not sure if Apple missed it, or figured it would be a while before most users would upgrade to ac and decided to go ahead and ship it in time for WWDC. As for battery life, even the numbers under heavy workload are impressive for such a small machine. I'm curious to see how well the battery life numbers improve for other ultrabooks as they switch to Haswell running different OSes. I would also like to see if or how well battery live improves after OS 10.9 is released this fall.
  • Abelard - Tuesday, June 25, 2013 - link

    Thanks for the thorough review, Anand. The battery life you were getting is very impressive.

    I'm curious how the MBA will perform running OS X Mavericks, though. Developers and early adopters seem to be reporting battery life improvements. It's possible Mavericks could squeeze another hour or two out of the 2013 MBA.

Log in

Don't have an account? Sign up now