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

11–20 of 31 posts

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

#11

Post by mbell »

acdha wrote: post #10

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 differ…

Was about to write the same thing, in addition you probably need to increase:

  net.inet.tcp.win_scale_factor
To something higher than the default of 3, 5-8 should work.

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

#12

Post by asafira »

I think it's worth pointing out that Anand did a good piece on this, with some more details into his methodology:

http://www.anandtech.com/show/7085/the-2013-macbook-air-revi...

Anandtech has some great reviews --- I recommend them to anyone that has ever fallen into the trap of reading a CNET review, product a product, and then realizing it falls short of expectations. That, and I also recommend them to anyone interested in diving into some of the more technical details of processor architecture and benchmarking, screen diagnostics, and more detailed write-ups on device performance.

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

#13

Post by drewcrawford »

trotsky wrote: post #6

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 pe…

Probably because afp or cifs are going to be the situation that ordinary people experience a WLAN bottleneck?

The speed of RTSP over 802.11ac would be relevant if you are giving a keynote address in your living room that needs to be streamed to the hundreds of interested participants in the kitchen.

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

#15

Post by dmmalam »

Apple losing their server division, and their huge focus on iOS has led to many of their core OS technologies lagging behind. Examples are networking, filesystems (still HFS+), kernel level benchmarks, concurrency, NUMA etc, and especially so compared to what Linux, Solaris, *BSD, and NT have progressed in the last few years.

A few years ago, I remember some of their kernel engineers saying Apple's performance goals are holistic with their hardware ie prioritise things that the majority of their consumers (mainly low end laptops) would need. This seems reasonable, why invest in best of class IO when most users are on 54g wifi with a single 5400rpm HDD. The problem is now consumer hardware has caught up, gigabit wifi, PCI-e SSDs, 8+cores, retina screens, multi-level cache hierarchies.

One thing OSX does extremely well at is power management, and that's in a large part due to iOS. I wonder what Apple run at their data centers?

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

#18

Post by trotsky »

drewcrawford wrote: post #13
trotsky wrote: post #6

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 pe…

Probably because afp or cifs are going to be the situation that ordinary people experience a WLAN bottleneck? The speed of RTSP over 802.11ac would be relevant if you are giving a keynote address in your living room that needs to be streamed to the hundreds of interested participants in the kitchen.

yet they test 10ft los in a barren band, making it clear that they're trying to conduct an unrealistic lab style rf/phy interface test.

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

#19

Post by objclxt »

dmmalam wrote: post #15

Apple losing their server division, and their huge focus on iOS has led to many of their core OS technologies lagging behind. Examples are networking, filesystems (still HFS+), kernel level benchmarks, concurrency, NUMA etc, and especially so compared to what Linux, Solaris, *BSD, and NT have progressed in the last few years. A few years ago, I remember some of their kernel engineers saying Apple's performance goals…

>I wonder what Apple run at their data centers?

They've posted job ads for their data centers in the past that mention Solaris and IBM/AIX. I don't know if there's anything official beyond that.

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

#20

Post by Hengjie »

It was incredibly alarming that the author blamed OSX on slow SMB performance and neglected to say which version of SMB they used. OSX 10.8 (Mountain Lion) only defaults SMB v1, where as Windows 8 defaults SMB v3. SMB v1 is incredibly chatty and has typically has bad performance over high latency networks (in other words the very 802ac network they were testing). And SMBv3 solves that problem altogether. So it's no wonder Windows 8 was faster. If the author bothered to do additional testing with iperf (like in http://anandtech.com/show/7085/the-2013-macbook-air-review-1...) then they would get completely different results.
Post reply on HN