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
Dunkurs1987 - Tuesday, January 5, 2016 - linkT Think Synology have a competition here with RT1900ac router:
iwod - Thursday, December 31, 2015 - linkMay be the industry should move faster to NBase-T; 2.5Gbps / 5Gbps and thinking about 10Gbps on prosumer / SME Network instead?
They say 802.11ax will substantially improve real world single client performance, which i hope it is true because as the article has shown, we aren't anywhere near 1Gbps Real world WiFi speed yet.
cdillon - Thursday, December 31, 2015 - linkI would love to see more reasonably-priced 10GBASE-T equipment. It's already not too bad from a prosumer standpoint. There would be little point to developing 2.5GBASE-T or 5GBASE-T at this point, though, since 10GBASE-T has been available for nearly a decade now.
iwod - Friday, January 1, 2016 - linkThe idea for Base-T is that with a new controller, ( Router , NAS, and your computer ) You could get 2.5 / 5Gbps from an CAT-5e depending on Cable quality and length. For most home users I don't see why they can't achieve 5Gbps unless you live in a castle size home.
My problem is that by the time Base-T standardise and widespread in consumer it will be 2018+. Why are we not forward thinking enough to have 10Gbps on the same controller as well? So it will negotiate the best transfer speed for that cable. I am sure for a lot of SME, and Home, their cables are decent and length are short enough to go 10Gbps.
jhh - Sunday, January 3, 2016 - linkBy 2018, enterprises will have moved to 25G over copper, so the 10G parts might get cheaper as they try to milk the last revenue out of their 10G switches and NICs. The 25/50/100G ports are already in the market, but you need a PCIe3 x16 to handle 100G, along with interrupt steering to distribute the packets to multiple cores.
p1esk - Friday, January 1, 2016 - linkExactly. Real world WiFi speeds are nowhere near 1Gbps. This link aggregation is really a solution to the problem from a fantasy land.
ganeshts - Friday, January 1, 2016 - linkI would think working MU-MIMO might alter the situation a bit. As you can see, we do get almost 1 Gbps with the 3x3 dual-radio configuration and link aggregation does help there.
Also, there is the matter of Qualcomm Atheros 4x4 routers that I am working on right now. They might be able to reach multi-gigabit throughput.
magreen - Friday, January 1, 2016 - link@plesk: Couldn't agree more on the fantasy land comment.
Their solution is a solution to the marketing problem--that their inflated marketing numbers have now outstripped the maximum one cat5e cable can provide. So they aggregate so that it's not theoretically impossible for their inflated marketing numbers to be correct.
It's like "aggregating" two 64-bit CPUs so that you can claim your CPU is 128-bit. Which is useful in the real world for...precisely nothing.
keithjeff - Saturday, January 2, 2016 - linkOh dear, have you seen the prices of Cisco nbaseT switches (or as they call them - mgig)?
The enterprise price is bad enough at a fairly large discount. The one off price would stagger you. And yes, they will come down, but I have no idea when.
zodiacfml - Thursday, December 31, 2015 - link1024 QAM seems not be working. Do we have a review or test of the efficiency of increasing spatial streams? I once tested my Nexus5 with a speed test and I remember having it around 300 to 320 mbps speeds which is pretty close to the theoretical 433 mbps speed and not far from the 400 to 500 mbps actual speeds of 3 spatial streams.