Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

OS X is holding back the 2013 MacBook Air’s 802.11ac Wi-Fi speeds

arstechnica.com

Post reply on HN
Print view View original

1–10 of 31 posts

Re: OS X is holding back the 2013 MacBook Air’s 802.11ac Wi-Fi speeds

#6

Post by trotsky »

Why would you test wifi speed using afp or cifs? Don't both those protocols dictate a fsync on each block, meaning they are very dependent on rtt which is much longer via radio? If you're testing radio bandwidth you really want to use a protocol without restraints like that, such as rtsp or http. While window size will undoubtedly help here, I wouldn't be surprised to find that windows 8 isn't flushing as often or performs async fsyncs.

Re: OS X is holding back the 2013 MacBook Air’s 802.11ac Wi-Fi speeds

#8

Post by jared314 »

cjreyes wrote: post #2

Will Mavericks have better support of 802.11ac?

From the end of the article:

Based on our and Shimpi's tests, it seems entirely likely that Apple will be able to fix the issue in software, and I would be surprised to see OS X 10.8.5 or OS X 10.9 ship with the same issues.

Re: OS X is holding back the 2013 MacBook Air’s 802.11ac Wi-Fi speeds

#10

Post by acdha »

A better test is to use something like iperf to see what the underlying TCP limits are like: in the case of something like SMB or AFP, it can be particularly confusing if you haven't adequately accounted for buffering and async writes – I've seen copies which “completed” considerably before the network traffic stopped.

If it is window scaling, adding the following to /etc/sysctl.conf should make a considerable difference by bumping the limits up to values appropriate for >100Mb connections:

    net.inet.tcp.sendspace=262144
    net.inet.tcp.recvspace=262144
Post reply on HN