Troubleshooting slow Wi-Fi performance writing to NAS
Setup:
- a Late 2007 MacBook Pro, running latest OS X 10.6,
- connects via Wi-Fi access point, ASUS WL-330gE
- to AFP share on NAS Synology DS508 running under latest DSM 4.0.
When doing rsync from the Mac to the NAS, I experience slow upload speeds.
On files of 20+MB in size rsync reports 1.5–2.0 MB/s (which is slow). On files of 2MB in size rsync reports 15-20 MB/s (which is OK). If I run two rsync processes in parallel (on different sets of larger files), transmission speed on both will be 1.5–2.0 MB/s.
If I disable Wi-Fi and connect my Mac via an Ethernet cable, upload speed is good for all file sizes.
How do I troubleshoot this problem?
Solution 1:
Let's run the numbers
First, let's gather the specifications of your hardware and do a quick estimate calculation of what your speed should be.
Assumptions and Inputs
Network speeds are usually given in megabits per second (Mbps), which are 10^6 = 1,000,000's of 1-bit bits per second. Disk/File I/O speeds are usually given in MebiBytes per second (MiB/sec), which are 2^20 = 1,048,576's of 8-bit Bytes per second. So 1 MiB/sec = 8.388608 Mbps. Let's round that up to 8.4.
Your Late 2007 MacBook Pro has an 802.11n card capable of a 300 Mbps maximum data rate when used with 40MHz-wide channels (HT40) and short guard intervals (Short GI) in the 5GHz radio band. It's wired Ethernet, in comparison, is gigabit.
Unfortunately, your ASUS WL-330gE is a really lame Wi-Fi AP; it's stuck on 802.11g (a.k.a. "Wireless-G") rates from 11 or 12 years ago, so the max it can do is 54 Mbps. And on its Ethernet side, it's only 10/100 Mbps, not gigabit.
Your Synology DS508 NAS has two gigabit Ethernet ports, and claims a RAID5 Write speed of 34+ MiB/sec and a RAID5 Read speed of 54+ MiB/sec.
The rule of thumb for TCP over IPv4 over 802.11a/b/g Wi-Fi efficiency is about 50% of your Wi-Fi PHY rate (physicaly-layer signaling rate). 802.11n and 802.11ac can get closer to 80% with frame aggregation, but 802.11g didn't have that.
The rule of thumb for TCP over IPv4 over gigabit Ethernet is 94.1% efficiency. That is with good hardware, OSes, and software, you can get 941 megabits/sec of pure TCP throughput over gigabit Ethernet.
Let's suppose for now that you're doing Wi-Fi on a clean channel and your MacBook Pro is close enough to your AP that you're always getting the maximum 54 megabit/sec PHY rate that your poor old Asus AP can handle.
Calculation:
54 Mbps, times 50% efficiency, divided by 8.4 to convert from Mbps to MiB/sec.
( 54 * .5 ) / 8.4 = 3.2 MiB/sec expected pure TCP throughput in ideal conditions.
AFP is a remote filesystem protocol, and remote filesystem protocols as a class add significant additional overhead, because they often transfer files in a bunch of smaller reads or writes that results in bursty network traffic, rather than setting up a constant data stream that keeps the network fully utilized. Plus disks, even RAID5 disks, add some latency.
So, overall, the 1.5-2.0 MiB/sec of AFP file transfer performance actually sounds pretty reasonable for real-world RF conditions where there might be some interference, or where you can't always hold onto the 54Mbps PHY rate and sometimes slip down to the 48, 36, or 24Mbps PHY rates.
The gigabit Ethernet case
When you switch to plugging the MacBook Pro's gigabit Ethernet directly into the Synology's gigabit Ethernet port, you could get something like:
1000 Mbps, times 94.1% efficiency, divided by 8.4 to convert from Mbps to MiB/sec:
(1000 * .941) / 8.4 = 112 MiB/sec
That's more than your Synology DS508's RAID5 write speed of 34MiB/sec. So in the wired gigabit Ethernet case, the Synology's disk speed would be the bottleneck, not the network.
Then what about that surprisingly high `rsync` speed?
One question this raises is why you would ever see 15-20 MiB/sec via rsync over Wi-Fi. Unless rsync is just lying to you sometimes, I'm betting you're taking advantage of rsync's ability to compress files before sending them across the network. Is -z or --compress (or some unambiguous substring of --compress) one of your arguments to rsync? That compression is the only thing that could truly account for a 10x speedup, or any speedup that gets more than 3.2MiB/sec over that 802.11g-style Wi-Fi link. A smaller effect would be that depending on how you're invoking rsync, you might not be going over AFP at all. rsync can be used to sync two "local" directories (and AFP-mounted remote directories look local to rsync in this case), or it can be invoked in a way that it talks its own rsync network protocol to an rsync server running on the remote device. Synology NAS boxes appear to be capable of running rsync servers. rsync's own network protocol is probably significantly more network-efficient than AFP, but still won't get you above 3.2MiB/sec over that bad Wi-Fi link.
So how can I solve this?
You could get an easy up-to-6x-or-more improvement buy buying a Wi-Fi AP that supports "N300" like your Late 2007 MacBook Pro does. To be specific, that's 2x2:2 (2 spatial stream) 802.11n with 40MHz channels and Short GI in the 5GHz RF band. Your Late 2007 MacBook Pro already supports this mode, which some AP vendors might call "5GHz N300". Please note that you can't just buy any "N300" AP; you need one that will work in 5GHz, because Macs only support narrower 20MHz-wide channels in the legacy 2.4GHz band, so if you try this in 2.4GHz, your Mac will max out at a 130Mbps PHY rate instead of a 300Mbps PHY rate. If you have any other devices around that only support the 2.4GHz band, then you'll probably need to get a "simultaneous dual-band" AP. Or keep your crappy Asus 802.11g AP for your old 2.4GHz devices, and buy a one-band-at-a-time, 5GHz-capable "N300" AP just for your 5GHz-capable devices like your MacBook Pro.
As evidenced by your 2007 MacBook Pro's support of it, 300Mbps 802.11n is 7-year-old technology at this point, so you might find someone who's throwing out an old AP that does this, because he's upgrading to 802.11ac or something.
The "N300" calculation:
300 Mbps, times 80% efficiency (802.11n supports frame aggregation), divided by 8.4 to convert from Mbps to MiB/sec.
(300Mbps * .8 ) / 8.4 = 28.6 MiB/sec expected pure TCP throughput in ideal conditions.
That shows that just by upgrading from 12-year-old Wi-Fi technology to 7-year-old Wi-Fi technology, you could come a lot closer to maxing out the 34MiB/sec write speed of your Synology DS508 NAS, in ideal conditions.
What about 802.11ac?
To do a big leap better than N300 would require upgrading both your AP and your MacBook Pro to 802.11ac. But upgrading the internal card on Macs is next to impossible, and the 802.11ac USB dongles are kind of crap, and 802.11ac is faster than your 2007 MacBook Pro's USB 2.0 "Hi-speed" 480Mbps anyway. So it's just not worth it to try to upgrade the wireless in your 6-year old MacBook Pro. Instead, maybe you could use this as justification to buy a 2013 or 2014 model retina MacBook Pro or MacBook Air, which have 802.11ac PCIe cards built in, capable of 1300 Mbps and 867 Mbps PHY rates, respectively. Coupled with a 2013 802.11ac AirPort Extreme (1300 Mbps), you'd have a nice fast 2013-era network.
I've clocked the 1,300 Mbps 802.11ac retina MacBook Pros at 1.02 Gbps TCP/IPv4 throughput on a direct Wi-Fi connection (one Mac acting as the AP), and 840 Mbps of TCP throughput when bridged through an 802.11ac AirPort Extreme from Wi-Fi to gigabit Ethernet. That's 100 MiB/sec, which would make your Synology's disk speed the bottleneck again on either reads or writes. In ideal conditions. YMMV.
tl;dr
- You're getting the best that can be expected given your hardware, and real-world RF conditions.
- Your Asus Wi-Fi AP is the bottleneck since it only does 802.11g.
- If you replace your Asus AP with an AP that maxes out your MacBook Pro's "N300" capabilities (which you might be able to get for cheap or free), you can easily improve your throughput by 6x or more.
- If you replace your AP and your MacBook Pro with 2013 models that do 1300Mbps 802.11ac, you could get an even more dramatic improvement, to where your Synology DS508 would become the bottleneck.