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
blaktron - Thursday, December 31, 2015 - linkUsing LACP direct from router to NAS is such a damn waste. If you put an enterprise switch in the middle of that you would get more than a 2x latency improvement to both your internet and files when using multiple clients on the network.
Right now I have a 3 channel LACP to my vHost and a 2 channel to my router with a Procurve in the middle and its incredible how low latency you get on requests compared to single channel setups.
cdillon - Thursday, December 31, 2015 - linkLACP is going to do absolutely nothing for you in regards to a noticeable latency decrease. The link bit-time is still exactly the same as without LACP, you only gain parallelism. Even if it did decrease your already sub-millisecond LAN latency, that would amount to squat when your internet connection already has at least a few milliseconds of latency. You might go from 15.1 ms to 15.05 ms... again, that's only if it did anything for you at all.
sor - Thursday, December 31, 2015 - linkI think what he means is that you'd want wired clients for the NAS, instead of forcing all access through the wireless router. At least, that's the only way I can think of to make his comment remotely sensible.
cdillon - Thursday, December 31, 2015 - linkHe mentions having LACP to the *router*.
sor - Friday, January 1, 2016 - linkRight, and he says to put a switch between them to serve other clients. This device is a router and wireless hub.
blaktron - Friday, January 1, 2016 - linkYeah, so you get a latency decrease by serving two packets at a time. You get the biggest benefit from using srv-io and multiple vm servers off a lacp array. The setup described above still has a single channel bottleneck unless there's an internal switch attaching the wireless module by multiple channels, which there is likely not.
joenathan - Saturday, January 2, 2016 - linkThat isn't how latency works. Two packets at once would be throughput.
lowtolerance - Sunday, January 3, 2016 - linkLatency has nothing to do with how many packets you send at once. It doesn't matter if it's sending one packet, two packets or fifty at a time. That's not to say the net result isn't a decrease in transfer time, but the RTT is going to be the same.
FaaR - Saturday, January 2, 2016 - linkAs gigabit ethernet is already full duplex, I fail to see how adding additional ethernet cables to a setup would reduce latency to any significant degree, unless your environment was previously suffering from a performance issue of some kind... :) *shrug* Maybe I am missing something here?
TexelTech - Saturday, January 2, 2016 - linkI dont believe it has anything to do with latency, more like throughput.