Netgear Nighthawk X8 R8500 AC5300 Router Brings Link Aggregation Mainstream
by Ganesh T S on December 31, 2015 8:00 AM EST- Posted in
- Networking
- NetGear
- Broadcom
- 802.11ac
- router
The Promise of Gigabit Wi-Fi
The Nighthawk X8 R8500 is marketed as an AC5300-class router. This naturally leads consumers to wonder whether it is really possible to get gigabit Wi-Fi (considering that an AC5300 router should theoretically support up to 2165 Mbps on each of the 5 GHz bands). In order to test out this aspect, we configured another R8500 in bridge mode (this is necessary to test 4x4 Wi-Fi bridging at the maximum possible link rate because 1024-QAM works only with other Broadcom devices, and the R8500 is the only Broadcom device that also has 4x4 capabilities).
Irrespective of where we placed the bridging router relative to the main R8500, we found that the link rate never reached 2165 Mbps, but topped out at 1733 Mbps. Eventually, we settled down on keeping the bridging router around 10 ft away, but, across a drywall (in order to simulate realistic conditions). The wired PCs connected to ports 3,4 and 5 of the main router were shifted to ports 1,2 and 3 of the bridging R8500. To our consternation, the results from running our folder download / upload test were downright abysmal.
While we did see occasional bursts of more than 800 Mbps during the testing, the majority of the time was spent in the 100 Mbps range. Apparently, we were not the only people to notice this issue, leading me to believe that there is still plenty of scope for performance improvements in the R8500.
It must be noted that the bridged R8500 connects only to one of the 5 GHz SSIDs. Could the second SSID help in driving up the throughput numbers? The R8500 in bridge mode was obviously not performing well. So, we shifted to using two Netgear Nighthawk R7000 routers in bridge mode, with each one connecting to one of the 5 GHz SSIDs. Ideally, we should also have had a third router in bridge mode to connect to the 2.4 GHz band, but we decided to test out with bridging on just the two 5 GHz SSIDs. We also cut down the number of clients from three to two (one to each bridging router).
The performance in this case was much better. We managed to sustain close to gigabit speeds over wireless (over two 5 GHz channels) for the multi-client upload and download cases. Note that each stream managed between 400 Mbps and 500 Mbps only despite a link rate of 1300 Mbps.
Concluding Remarks
We set out to check the effectiveness of link aggregation with the Netgear R8500 and Netgear ReadyNAS RN214, and we are pleased with the user-friendliness of the whole process. Netgear has managed to bring the concept of link aggregation to mainstream consumers with the Nighthawk X8 R8500 AC5300 router. The ReadyNAS RN214 is a nice complement to the router for this purpose. The whole setup process is pretty much seamless. The sole suggestion we would like to make here is that the ReadyNAS web UI could make the transmit has policy for 802.3ad LACP to be Layer 2 + 3 by default (instead of Layer 2 only).
On the gigabit Wi-Fi side, consumers are going to be a tad disappointed. Despite claims of up to 5.3 Gbps speeds, the router seems barely capable of 1 Gbps over Wi-Fi (out of a possible theoretical 4.3 Gbps) under real world conditions. Though we didn't set out to review the full capabilities of the Nighthawk X8 R8500, it is evident from our limited wireless testing that there is plenty of scope for performance improvements in the firmware.
66 Comments
View All Comments
blaktron - Thursday, December 31, 2015 - link
Using 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 - link
LACP 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 - link
I 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 - link
He mentions having LACP to the *router*.sor - Friday, January 1, 2016 - link
Right, 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 - link
Yeah, 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 - link
That isn't how latency works. Two packets at once would be throughput.lowtolerance - Sunday, January 3, 2016 - link
Latency 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 - link
As 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 - link
I dont believe it has anything to do with latency, more like throughput.