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


View All Comments

  • cbrownx88 - Monday, June 24, 2013 - link

    Please please please revisit with the i7 config - been wanting to make a purchase but have been waiting for this review (and now waiting on the update lol). Reply
  • ananduser - Monday, June 24, 2013 - link

    I believe this is the first time a company has actually released a slower product than the previous gen. On principle at least Apple should be penalized in the review.

    Anand may I suggest a battery testing feature ? Count the time it takes to finish one iteration of the looping test. Maybe the battery lasts longer on a certain device but it may also take longer to finish the task. After that "normalize" the results to really measure the improvement.
  • Paapaa125 - Monday, June 24, 2013 - link

    MBA 2013-mid is not really that much slower. It has a lot faster SSD, it has a lot faster WLAN. CPU equal or slower than previous and GPU is faster than previous models. For most usages the net result is a equally fast if not faster computer. Mostly because SSD. Reply
  • captainBOB - Tuesday, June 25, 2013 - link

    Instead of going the typical route and using all the extra power savings to increase performance while maintaining the same battery life of last year's model, Apple decided to increase battery life while maintaining performance with last year's model. Its an ultraportable.

    If you want more juice, get a Macbook Pro, the Macbook Air is all about the ultraportability.

    As for the lack of 1080p, on all those other ultrabooks with a 1080p screen, the DPI scaling is upped to 150% by default because people were complaining that text on the screen was too small, Windows still can't handle DPI scaling very well, and I doubt Windows 8.1 will change things because it will most likely be an API and still be up to the developer to update their programs to support higher resolutions. Given the "stellar" track record of the Windows desktop development community and Microsoft itself in actually USING the awesome new APIs that Microsoft creates. The situation isn't going to change the moment 8.1 comes out, it may not change for several years.

    Retina may be in the Air's future, but for now the Retina display is what clearly separates the Pro from the Air.

    If there is one criticism that is valid, its that the display should've been at least IPS.
  • ananduser - Tuesday, June 25, 2013 - link

    Spare me the marketing talk please...I never mentioned anything about the screen. Why do you feel the need to explain me Apple's motives for that ?

    They could have very well provided a 9 hour machine with a tangible increase in performance, but hey, Apple fans don't care, everything is perfect in camp Cupertino.

    PS: Since you brought it up, the Windows desktop development community is pretty stellar indeed; it's why the best software on the planet, from virtually all categories you wish to name, is made to run on Windows first and foremost. Windows(the software) always handled scaling very well, and having options like 125% or 150% is pretty nifty. Since the display pissing contest just started it will take some time until devs start to obey proper guidelines.
  • Paapaa125 - Tuesday, June 25, 2013 - link

    It's always a tradeoff. Apple went now for maximal battery life with acceptable performance. Most likely they'll focus on performance with rMBP. Sounds logical to me. I think there are many users to whom MBA has enough CPU power and they really need all day battery life. MBA now barely delivers that. Lower battery life would've meant that it will not last all day. Reply
  • ananduser - Wednesday, June 26, 2013 - link

    So...we Anandtech readers... we who are the most pretentious of most users... can't we provide criticism ? Reply
  • jmmx - Monday, June 24, 2013 - link

    What would like to know is this...

    I assume that turbo boost speeds will more likely occur when the unit is plugged in - i.e. it will not be draining the battery. Do any of these tests take this into account? (or did I jut not read far enough yet?)
  • Laststop311 - Monday, June 24, 2013 - link

    I totally despise apple and yes it looks like they are making a lot of mistakes with the 2013 refresh. Staying with low res screens and lower clocked processors that are actually a nudge slower than in 2012. But with the the lower clock speeds and massive battery life improvements of the haswells the macbook air is poised to be the longest running ultrabook on battery this year, especially with the larger battery that adds no weight.

    When you combine the fact that this is haswell, they stayed with low res screens added a larger battery and lowered the cpu frequencies we are in for a real treat with an ultrabook with an insane battery runtime that still has enough power to do everything an ultrabook is used for 99% of the time and do it it with performance in the mid the to midhigh pack with Top battery scores. Not to mention the thermals are probably so much cooler on this air. If Apple left it at 50% would would or probably seen 15 hour idle numbers from apple. And once OSx integrates the power management optimizer feature from haswell those battery life numbers will only go up. Eve more.

    I hate apple. But if battery life i you're #1 concern and want to routinely pull 10 hour workdays from your machine without charging the macbook air 13 model 2013 is the ultrabook for you.
  • KPOM - Thursday, June 27, 2013 - link

    All notebooks are about design compromises. Apparently Apple decided to tweak this one for battery life rather than use Haswell as an opportunity to put in a faster processor or better screen. Hopefully they'll find a way to shave a few ounces off the weight of the 13" rMBP. I have one and like it, but miss the portability of the Air. Reply

Log in

Don't have an account? Sign up now