What's new

Linksys EA8500 Max-Stream AC2600 MU-MIMO Smart Wi-Fi Router Reviewed

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

mediatrek

Regular Contributor
The Linksys EA8500 (AC2600) is due to be out on or around May 10th. It will be the third router to ship with Qualcomm-Atheros’ IPQ SoC. The first being the R7500 from Netgear and the E8350 from Linksys. Sadly both of those units mixed vendor chips with the Quantenna QSR1000 solution for the 5G radio, which was “MU-MIMO ready” yet still has yet to actually be MU-MIMO functional with firmware updates.

The EA8500 uses Qualcomm chips across the board and is out of the box MU-MIMO capable. SemiAccurate posted this article a few days about looking at the 802.11ac MU-MIMO solution from Qualcomm. It was an interesting read and does look at the EA8500 specifically. The only question I have regarding the QCA 5G Wave 2 solutions is offload processing. Quantenna’s solution has a 500Mhz dual-core offload, and Broadcom’s upcoming solutions (from what I have read) do as well. Does QCA’s just rely on the main SoC?

The EA8500 has been Wi-FI certified, and I have emailed Belkin (Linksys), but have not heard back as to if the unit comes with any traffic shaping capabilities (ie- QCA’s Streamboost).
 

Attachments

  • EA8500_a.jpg
    EA8500_a.jpg
    45.5 KB · Views: 809
  • EA8500_b.jpg
    EA8500_b.jpg
    76.1 KB · Views: 953
The slow processor speed won't be able to handle a VPN encryption/decryption and still make any good speed.
 
All 32-bit ARM cores suck at OpenVPN - it's OpenVPN's portable code that is the problem...

If I recall correctly, isn't Qualcomm-Atheros' IPQ Wave2 chipsets actually based on Qualcomm's Krait cores - if so, it's hella faster than ARM's Cortex-A9...
 
The Linksys EA8500 (AC2600) is due to be out on or around May 10th. It will be the third router to ship with Qualcomm-Atheros’ IPQ SoC. The first being the R7500 from Netgear and the E8350 from Linksys. Sadly both of those units mixed vendor chips with the Quantenna QSR1000 solution for the 5G radio, which was “MU-MIMO ready” yet still has yet to actually be MU-MIMO functional with firmware updates.

The EA8500 uses Qualcomm chips across the board and is out of the box MU-MIMO capable. SemiAccurate posted this article a few days about looking at the 802.11ac MU-MIMO solution from Qualcomm. It was an interesting read and does look at the EA8500 specifically. The only question I have regarding the QCA 5G Wave 2 solutions is offload processing. Quantenna’s solution has a 500Mhz dual-core offload, and Broadcom’s upcoming solutions (from what I have read) do as well. Does QCA’s just rely on the main SoC?

The EA8500 has been Wi-FI certified, and I have emailed Belkin (Linksys), but have not heard back as to if the unit comes with any traffic shaping capabilities (ie- QCA’s Streamboost).
@mediatrek, I have the same issue with Quantenna for ASUS RT-AC87U, "MU-MIMO ready" is a open ended term, I have a contact at Quantenna and they are working on MU-MIMO as we speak, so hang tight all Quantenna will soon have MU-MIMO.
QCA although they miss the 802.11ac wave1 boat, they will be dominant for wave2 for sure. Having working on the QCA wave1 chipset and Broadcom, all I can say is the QCA wave2 chip is better IMHO, their offload processor architecture is well suit to handle gigabit traffic, more ever the chip runs much much cooler versus the others vendors in the wave2 space.
 
@mediatrek, I have the same issue with Quantenna for ASUS RT-AC87U, "MU-MIMO ready" is a open ended term, I have a contact at Quantenna and they are working on MU-MIMO as we speak, so hang tight all Quantenna will soon have MU-MIMO.
Huh? Quantenna has had at least a year with no competitors to get MU-MIMO running on all the "MU-MIMO ready" routers with its chipset inside. So now they're ready...soon...almost? Feh.
 
And if we're going to get all excited about MU-MIMO routers, how about some discussion about MU-MIMO clients and how there aren't any.

The router guys (and Qualcomm) are pushing this so hard that they are having to send MU-MIMO laptops along with the routers for reviewers.
 
...how about some discussion about MU-MIMO clients and how there aren't any.

My understanding is that in Qualcomm Snapdragon 805, 808 & 810 full mobile platform solutions, QCA MU-MIMO solution(s) have been made available to hardware OEM's (LG, Samsung, Motorola, etc) when those platforms were sampled. The OEM's chose not to include a QCA MU-MIMO solution in their end products, but instead to save some $$ they went with Wi-Fi & bluetooth solutions from other vendors.

For example, MU-MIMO could have been offered to consumers in the Nexus 6 from Motorola & Google, but for cost reasons, they went with a Broadcom solution and not the full QCA Solution platform.

In addition, in in late 2014 Qualcomm offered a software update to OEM's for devices that used the full Snapdragon 801 platform solution that added MU-MIMO client support.
 
Huh? Quantenna has had at least a year with no competitors to get MU-MIMO running on all the "MU-MIMO ready" routers with its chipset inside. So now they're ready...soon...almost? Feh.
:cool: same reaction like you "Huh?" , my source from Quantenna is reliable, the difficulty to verify MU-MIMO was to have client devices with MU-MIMO. I check in the beacons sent by the RT-AC87U and there is not MU. I think people push a little bit strong the envelop with "MU-MIMO ready".
 
:cool: same reaction like you "Huh?" , my source from Quantenna is reliable, the difficulty to verify MU-MIMO was to have client devices with MU-MIMO. I check in the beacons sent by the RT-AC87U and there is not MU. I think people push a little bit strong the envelop with "MU-MIMO ready".

Look for the VHT epigram - MU-Beamforming - if set to true...

sfx
 
And having that set to true on the WRT1900ac, and perhaps on the WRT1200ac as well, this might have some very interesting interop issues...
 
Look for the VHT epigram - MU-Beamforming - if set to true...

sfx
Like I said earlier, MU-TxBF is false, only SU is true for RT-AC87U. I will buy WRT1900ac as MU-TxBF is true like you said. I have Agilent to generate MU-MIMO and decode with VSA, big deception when RT-AC87U not yet MU-MIMO. My setup was to peer RT-AC87U one side as client-bridge and other side as AP. Does the WRT1900ac can be put in client mode ?
 
Save your money and wait - I brought this up to Linksys last summer, and they emphatically denied MU-MIMO or any kind of MU-Beamforming, but the epigram continues to exist across different firmware builds.

MU-MIMO is a chipset thing at the MAC/PHY, so one typically won't see it in logs, one has to do the wirecaps and see what happens there... sounding and MU group assignments...
 
Look for the VHT epigram - MU-Beamforming - if set to true...

sfx
And having that set to true on the WRT1900ac, and perhaps on the WRT1200ac as well, this might have some very interesting interop issues...
Translation: When MU-MIMO devices ship, they will think these WRTs support MU-MIMO?
 
Save your money and wait - I brought this up to Linksys last summer, and they emphatically denied MU-MIMO or any kind of MU-Beamforming, but the epigram continues to exist across different firmware builds.

MU-MIMO is a chipset thing at the MAC/PHY, so one typically won't see it in logs, one has to do the wirecaps and see what happens there... sounding and MU group assignments...
Thanks for the advice, I will save my money then :cool: I was so pump up to see NDP sounding frames but none of that did happen...so fall back to Agilent in the mean time.
 
Translation: When MU-MIMO devices ship, they will think these WRTs support MU-MIMO?

I don't think so... the Linksys folks, I think were a bit surprised when I pointed that out... went well beyond the normal point of contact, and I get a direct response from Engineering. There's nothing in the Mamba GPL code drops in the Linksys code that suggests it, so it must be in the Marvell driver code if it exists - or it's a bug in the driver as a missed bit setting for the beacon.

In any event, should matter, as MU-MIMO is a dynamic feature, and perhaps the chipset will elect not to do it.
 
this is from the HT section of the beacon

Transmit Beam Forming (TxBF) Capabilities: 0x1807ff1f
.... .... .... .... .... .... .... ...1 = Transmit Beamforming: Supported
.... .... .... .... .... .... .... ..1. = Receive Staggered Sounding: Supported
.... .... .... .... .... .... .... .1.. = Transmit Staggered Sounding: Supported
.... .... .... .... .... .... .... 1... = Receive Null Data packet (NDP): Supported
.... .... .... .... .... .... ...1 .... = Transmit Null Data packet (NDP): Supported
.... .... .... .... .... .... ..0. .... = Implicit TxBF capable: Not supported
.... .... .... .... .... .... 00.. .... = Calibration: incapable (0x00000000)
.... .... .... .... .... ...1 .... .... = STA can apply TxBF using CSI explicit feedback: Supported
.... .... .... .... .... ..1. .... .... = STA can apply TxBF using uncompressed beamforming feedback matrix: Supported
.... .... .... .... .... .1.. .... .... = STA can apply TxBF using compressed beamforming feedback matrix: Supported
.... .... .... .... ...1 1... .... .... = Receiver can return explicit CSI feedback: delayed and immediate feedback capable (0x00000003)
.... .... .... .... .11. .... .... .... = Receiver can return explicit uncompressed Beamforming Feedback Matrix: delayed and immediate feedback capable (0x00000003)
.... .... .... ...1 1... .... .... .... = STA can compress and use compressed Beamforming Feedback Matrix: delayed and immediate feedback capable (0x00000003)
.... .... .... .11. .... .... .... .... = Minimal grouping used for explicit feedback reports: Groups of 1,2,4 supported (0x00000003)
.... .... ...0 0... .... .... .... .... = Max antennae STA can support when CSI feedback required: 1 TX antenna sounding (0x00000000)
.... .... .00. .... .... .... .... .... = Max antennae STA can support when uncompressed Beamforming feedback required: 1 TX antenna sounding (0x00000000)
.... ...0 0... .... .... .... .... .... = Max antennae STA can support when compressed Beamforming feedback required: 1 TX antenna sounding (0x00000000)
.... .00. .... .... .... .... .... .... = Maximum number of rows of CSI explicit feedback: 1 row of CSI (0x00000000)
...1 1... .... .... .... .... .... .... = Maximum number of space time streams for which channel dimensions can be simultaneously estimated: 4 space time streams (0x00000003)
000. .... .... .... .... .... .... .... = Reserved: 0x00000000


And this is from the VHT section:

VHT Capabilities Info: 0x339b7930
.... .... .... .... .... .... .... ..00 = Maximum MPDU Length: 3 895 (0x00000000)
.... .... .... .... .... .... .... 00.. = Supported Channel Width Set: Neither 160MHz nor 80+80 supported (0x00000000)
.... .... .... .... .... .... ...1 .... = Rx LDPC: Supported
.... .... .... .... .... .... ..1. .... = Short GI for 80MHz: Supported
.... .... .... .... .... .... .0.. .... = Short GI for 160MHz and 80+80MHz: Not supported
.... .... .... .... .... .... 0... .... = Tx STBC: Not supported
.... .... .... .... .... .001 .... .... = Rx STBC: 1 Spatial Stream Supported (0x00000001)
.... .... .... .... .... 1... .... .... = SU Beam-former Capable: Supported
.... .... .... .... ...1 .... .... .... = SU Beam-formee Capable: Supported
.... .... .... .... 011. .... .... .... = Compressed Steering Number of Beamformer Antennas Supported: 4 (0x00000003)
.... .... .... .011 .... .... .... .... = Number of Sounding Dimensions: 4 (0x00000003)

.... .... .... 1... .... .... .... .... = MU Beam-former Capable: Supported
.... .... ...1 .... .... .... .... .... = MU Beam-formee Capable: Supported

.... .... ..0. .... .... .... .... .... = VHT TXOP PS: Not supported
.... .... .0.. .... .... .... .... .... = +HTC-VHT Capable (VHT variant HT Control field): Not supported
.... ..11 1... .... .... .... .... .... = Max A-MPDU Length: 1 048 575 (0x00000007)
.... 00.. .... .... .... .... .... .... = VHT Link Adaptation: No Feedback (0x00000000)
...1 .... .... .... .... .... .... .... = Rx Antenna Pattern Consistency: Supported
..1. .... .... .... .... .... .... .... = Tx Antenna Pattern Consistency: Supported
00.. .... .... .... .... .... .... .... = Reserved: False
 
Thanks for the advice, I will save my money then :cool: I was so pump up to see NDP sounding frames but none of that did happen...so fall back to Agilent in the mean time.

You'll see the sounding frames whether it is MU-MIMO or SU-MIMO - in a SU-MIMO configuration, one still gets beam forming, so the NDP's are still needed so that the AP can steer the beam towards desired STA.

sfx
 
Anyways, even if there is no MU-MIMO clients, these Wave2 early devices will be 4T/4R MIMO, with at least three spatial streams, and this will help out all clients thru the magic of MIMO...

Even single stream legacy clients, as the frames on the extra streams are replicated across all streams, so the client sees it as multiple path returns, and will use maximal ratio combining to clean up the data... same for the AP side..

That's why I've always been a fan of three stream AP's, even if 3-stream clients in 11n are hard to come buy... there is a clear benefit in the mid-range distances where 2-stream AP's will get error bound - 3 stream will extend that a bit, and there's always the benefit of that third radio chain.
 
In any event, should matter, as MU-MIMO is a dynamic feature, and perhaps the chipset will elect not to do it.
Is that should or should not matter? I'm just trying to clarify if you are pointing out a potential problem.
 

Latest threads

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top