Netgear Nighthawk X8 R8500 AC5300 Router Brings Link Aggregation Mainstreamby Ganesh T S on December 31, 2015 8:00 AM EST
- Posted in
The average consumer equipment's wired ports have been stuck at 1 Gbps for quite some time. On the other hand, 802.11ac enables router manufacturers to market multi-gigabit Wi-Fi. Power users have tried to use prosumer and business switches to take advantage of multiple ports on devices and obtain multi-gigabit throughput. Netgear recently introduced its AC5300-class router, the Nighthawk X8 R8500. One of the interesting features was the availability of 802.3ad LACP in the official firmware. In the marketing material, they also pointed out that it was simple enough for the average user to utilize when combined with a Netgear ReadyNAS unit.
The Netgear Nighthawk X8 R8500 was launched in October 2015. It is an AC5300-class tri-band router. This implies the presence of two 5 GHz SSIDs (4x4 for 1733 Mbps with Broadcom's 1024 QAM extensions to get 2165 Mbps on each SSID) and one 2.4 GHz SSID (4x4 for 800 Mbps, with Broadcom's 1024-QAM again bringing it to 1000 Mbps). We covered the full details in our launch piece, and will not delve much into the details here. Link aggregation is made necessary in these flagship products because of the presence of multiple SSIDs capable of gigabit throughput. Since each wired port is limited to 1 Gbps, it becomes impossible for any one client to actually make full use of the wireless capabilities.
There are different ways to aggregate two network ports together. These include round-robin, active backup, balance-xor, fault tolerance, adaptive load balancing etc. Multiple modes tend to create confusion for the average user. Hence, Netgear has chosen to keep things simple by making 802.3ad Dynamic Link Aggregation (LACP) as the only available teaming mode.
Netgear assumes that most of the consumers would be connecting a NAS unit to the LACP ports. They have separate guides for ReadyNAS, QNAP and Synology units on their website.
Ideally, the configuration should be a couple of clicks at the most in the web UI. While that is true on the router side, the NAS side has a few issues. The fact that the setup will utilize 802.3ad LACP is drilled down quite a bit, but the changing of the hash type to Layer 2 + 3 needs to be done explicitly (it is Layer 2 by default). Note that choosing Layer 2 will still keep the UI status on both the NAS and the router side happy. The NAS is also accessible via the LACP ports irrespective of the hash type chosen.
This review will start off with a description of a realistic test setup to bring out the benefits of link aggregation. In the initial configuration, we will take a look at a pure wired setup. In the second experiment, we will check if the benefits of link aggregation translate to practical gigabit Wi-Fi.
It is important to remember that a single PC or a single transfer stream will not benefit from 802.3ad LACP. For example, a client with bonded ports can't get multi-link throughput from a server with bonded ports for any given transfer (unless one is using SMB multi-channel, for example). In any case, this is a moot point since the R8500 supports only two ports for link aggregation.
Our test setup consists of the Netgear ReadyNAS RN214 connected to the link aggregation ports of a R8500 and configured with a bonded link as described in the previous subsection. The NAS is configured with a RAID-5 volume using 4x 4TB Seagate NAS HDDs. On the clients side, we have three PCs running Windows 8.1 Pro connected to ports 3, 4 and 5 of the same R8500. Two of the PCs had an integrated RealTek Semiconductor RTL8168/8111 PCI-E Gigabit Ethernet NIC while one had a Intel Ethernet Connection I218-V Gigabit Ethernet NIC. The performance difference between the Realtek and Intel NICs is not a big factor in the benchmarks today.
In the second experiment, we configured another R8500 in bridge mode to connect to the first 5 GHz SSID on the main R8500. The three wired clients used in the first experiment were connected to the bridged R8500's LAN ports numbered 1,2 and 3. Link aggregation was disabled on the bridged R8500, but the ReadyNAS RN214 continued to remain connected via LACP on the primary R8500.
The gallery above shows some of the configuration pages on the R8500 units and the RN214 relevant to the above discussion.
The actual benchmark consisted of transferring a 10.7 GB Blu-ray folder structure from the NAS to the PC and vice-versa in a synchronized manner. A Blu-ray folder allows us to mimic a good mix of files of different sizes. Synchronizing the operations allows us to identify how the setup behaves when multiple clients are trying to simultaneously access the link-aggregated target (ReadyNAS RN214, in this case). This is the typical scenario when multiple machines are attempting to backup or restore from a backup.
Post Your CommentPlease log in or sign up to comment.
View All Comments
Ertaz - Thursday, December 31, 2015 - linkHey, thank you for taking the time to do this review. This is good info and it's given me things to think about when I upgrade my network in the middle of the year.
creed3020 - Thursday, December 31, 2015 - linkThanks for confirming my suspicions, at least with this hardware, that wireless AC at the highest end is still not ready to replace my Cat5e cables snaked through the house.
I love my fast connection to my NAS, router, and other clients without high latency and jittery speeds.
IndianaKrom - Thursday, December 31, 2015 - linkThe other thing to keep in mind is that all 802.11 based standards are half-duplex and all these routers claims of bandwidth is the sum of the total system bandwidth in both directions. But in reality the bandwidth is split 50/50 between the transmit and receive sides of the time division multiplexing. So in any one direction transfer the maximum theoretical throughput of a pair of wireless devices is 50% of the negotiated link speed.
Basically if wired lan was advertised the same as wifi routers, then your 1 gigabit cat5e would be marketed as "2 gigabits".
zodiacfml - Thursday, December 31, 2015 - linkWow, I was about the mention the same thing. I did a lot of reading last year on Wi-Fi and standards that I came to know of this half-duplex operation as I am perplexed why multi-gigabit Wi-Fi don't come close LAN cabling. Even uglier are the spatial streams which has diminishing returns. A second spatial stream, if I'm correct, is around 50% improvement and the third stream is around 20 to 30%.
easp - Friday, January 1, 2016 - linkYou make a valid point about the difference between full and half-duplex operation.
You miss though that ethernet was originally shared and half-duplex, and so a 10baseT or 10base2 network segment shared 10mbps among all connected devices. This bandwidth was measured at the PHY (physical) layer, and didn't take into account the overhead imposed the collision detection and avoidance MAC (media access control). During the the rise in full-duplex NICs and switches starting in the mid-1990s, bi-directional communication was still a selling point.
When WiFi arrived, it was specced similarly to early ethernet. The quoted speeds were based on the maximum available PHY rate, and ignored the overhead imposed by other layers of the wireless stack. This pattern held until 802.11ac, when the quoted datarates were at the MAC layer, and arrived with efficiency improvements in the MAC. However, they still are half-duplex.
While I agree that the distinction between the full-duplex norms of most wired networking and the half-duplex norms of WiFi are important to consider. I think you've manage to both under and overstate the implications when it comes to WiFi.
Also, your comment on shared bandwidth between two wireless stations connecting through the same WiFi router/access point should probably acknowledge that things change straightforward once multi-user MIMO (MU-MIMO) becomes better supported and adopted, particularly since the article you are commenting on is about MU-MIMO capable hardware.
easp - Friday, January 1, 2016 - linkDerp. I meant to cut my second-to-last paragraph.
Notmyusualid - Sunday, January 3, 2016 - linkAdd to your half-duplex wireless hates, air listening times, back-off times, re-tranmissions, noisy environments (I had 57 viewable networks from the apartment in Copenhagen), and more all lead to increased latency. So I gave up on 802.11g long ago... 2.4GHz was saturated.
My two C3750G switches are hard-wiring my house just fine, without LACP or PAGP, my etherchannels are hard coded as ON.
But I actually still like this product - I've seen more than enough small business run on non-enterprise gear (NOT my decision), and so having etherchannels available to a NAS makes sense - for a storage solution that might be under quite some load with a dozen or so users.
And wait until DD-WRT gets their hands on it, you might get some port security etc too!
michaelag - Thursday, December 31, 2015 - link"On the other hand, 802.11c enables router manufacturers to market multi-gigabit Wi-Fi."
ganeshts - Thursday, December 31, 2015 - linkThanks for pointing out. Fixed the typo.
The_Assimilator - Thursday, December 31, 2015 - linkI'm honestly surprised there hasn't been a lawsuit in the US regarding the lies about wireless speeds that router companies peddle. "5.3Gbps WiFi Speeds"... I doubt Netgear has ever even seen that in their own testing, and I doubt anyone ever will.
Maybe one day wireless speeds won't be "up to" with the average maximum throughput being 20% of what the manufacturer claims... and maybe I'll fart butterflies. Until then, I'm sticking with wired Ethernet - it may be an old standard, and a pain, but at least it delivers.