Is Anyone Using MU-MIMO?

[doczenith1]

I'll run the tests again with 4-5 feet separation. Should I add in the non MU-MIMO device this time? I forgot I have a 1x1 MU-MIMO device. Would that be a better addition than the non MU-MIMO device? Or should I attempt all 4 devices?

 

[avtella]

I think you should be fine using all 4.

 

[thiggins]

If you are trying to see whether MU provides higher total throughput, keep it simple. Just the same experiment with two MU devices, spaced farther apart.

 

[sfx2000]

Just because both the Client and AP stations are MU capable, this doesn't mean that MU will be applied.

The AP makes some decisions based on pending traffic, and group info, and make a decision accordingly - part of that is... is it worth the cost/benefit of doing a MU group based on conditions.

At a high level - there are some decisions - see below...

That assumes that a MU group is already established - and this takes two or more MU clients... and corresponding connection attributes that make sense to add a client to the group.

Then we take into consideration that most AP's are going to be running time-late with the channel state information - which is needed for beamforming - the broadcast VHT NDP announcement frame requesting data from the client stations - but that is an indication of when, not "now". It's similar for SU beamforming, and how one can tell in PCAP's - if the VHT NDP Annoucement is broadcast, it's MU, if it's directed toward a specific client, it's unicast.

Once making a decision that maybe MU frame is good - then 802.11e comes into play with the connection characteristics - QoS - one client might be doing a netflix stream, one might be checking facebook, and another might be on a VOIP call - and each of these have different needs and requirements....

It's a real mess, and computationally for many vendors, hard to do.

 

[Easy Rhino]

I tried a test and it was very inconclusive.

Router: Phicomm K3C (3x3 MU-MIMO)
Server: a desktop with hardwire ethernet
Client 1: laptop with added no-name USB wifi with RTL 8812BU chip (2x2)
Client 1: Samsung Galaxy S3 (3x3 I think?)

Anyway, the RTL 8812BU adaptor is really flakey, so I think that messed it up. I had driver problems on my laptop, it had trouble connecting sometimes, and was spitting out unusually low speeds.

I ran iperf2 from each client to the server, first one at a time, then simultaneously. The score is the average over 10 seconds.


Clients one at a time:
8812BU: 117mpbs
S8: 354mbps
Aggregate: 471 mbps

Simultaneous
8812BU: 109mpbs
S8: 368mbps
Aggregate: 477mbps

So in conclusion MU MIMO is magic! (but I my underlying network adaptor is probably too flakey to make meaningful conclusions)

 

[doczenith1]

I finally got around to running the test again but this time with the phones about ten feet apart but in the same direction from the router. They were about 3 feet apart horizontally and 2 feet apart vertically. I tested using the same Pixel XL and Pixel 2 XL with my 86U on 384.4_2. Each had a 866 link speed. I ran the test using the nPerf speed test this time as it allows me to set the duration of the test which I set at 30 seconds. Being that it takes me about a second or so to get from one phone to the other to start the test I thought a longer test would be better. The nPerf test also returns a max and average value. It was the average value that I thought would be important for this testing. I ran 6 tests and took the average of the best 5 values. Results are DL/UL in Mbps.

Testing phones one at a time to set a baseline.
Pixel XL 575/537
Pixel 2 XL 573/622

Testing phones at the same time with MU-MIMO disabled.
Pixel XL 304/239
Pixel 2 XL 301/325

After this test I "forgot" the wifi connection on each phone. I enabled MU-MIMO and rebooted the router.

Testing phones at the same time with MU-MIMO enabled.
Pixel XL 193/253
Pixel 2 XL 338 /295

I noticed that the speed graphs were somewhat flatter (less spikes) with MU-MIMO disabled. Especially the download graph.

Combined speed.
MU-MIMO disabled 605/564
MU-MIMO enabled 531/548

 

[avtella]

I wonder if Broadcom is still hampered by the ability to only use 1 client in 2x2 mode and the other in 1x1 with MU-MIMO. The QCA9984 (Netgear R7800/Asus BRT-AC828/Synology Rt2600AC) rectified that supporting 2 2x2 MU clients at once.

 

[Easy Rhino]

I tried a test and it was very inconclusive.

I tried again and it was still inconclusive.
Tried my HP laptop with intel AC8265 (2x2) and Samsung galaxy S8 (2x2).
Router was still the Phicomm K3C (3x3)

Ran 20 second tests, clients were about 9 feet apart

First trial with MUMIMO combined bandwidth was 310mbps
second trial is was 203 mbps
One trial with MUMIMO disabled showed aggregate of 243

So no clear trend. Individual test by test variability was way higher than the mimo tests.

 

[avtella]

MU-MiMO doesn’t really make sense on a 3x3 router as many of those support either 1 1x1 and 1 2x2 device or just 2 1x1 devices. Also Samsung S7/S8 use Broadcom WiFi chipsets I believe which drops them to 1x1 mode in MU not that it mattters as it’s just a phone, but in synthetic tests throughout would obviously drop.

Currently the Qualcomm QCA9984 based 4x4 routers are the only ones that do it well as far as I know.

 

[ulaganath]

I got the best wifi speed at 77MB/S or 685Mbps

It internal pci e card from Realtek and support mu mimo locally transfer is my viable option as internet pipe max out to 250mbps

So for 2x2 if I can get 77 with quad antennas I can max lan gig speed

And only way to saturate is 10gb lan or 2.5gb lan

As most nas are coming up with quad lan port and port aggregation gives 4 times close throughput based on the raid types and ram




Sent from my iPhone using Tapatalk

 

[Jim Salter]

Tim, you still looking for test cases? I have a couple el cheapo Dell laptops with MU-MIMO NICs; I think they're just single-channel IIRC. I did some informal testing quite a while back and saw some worthwhile differences with MU-MIMO enabled, but I didn't actually write what I found up like a formal post or anything. The biggest change I saw was in terms of how fairly airtime was used; when running iperf3 without the -R argument (meaning it's uploading to the test server, not downloading), without MU-MIMO one laptop would routinely pull >95% of the airtime; with MU-MIMO enabled, both laptops would get roughly 50% of the airtime, and overall throughput would increase about 20%.

This was with one of the ridiculous giant-cluster-of-doom routers, the ones with antennas all the way around on all four edges, IIRC. Either ASUS or TP-Link; I've got it around somewhere still. (edit: TP-Link Archer C5400.) The Airtime Fairness setting did absolutely nothing, but the MU-MIMO setting made an enormous difference as described above.

Again note that this was specifically on upload performance, not download; yes I'm aware that MU-MIMO is download only, so I'm not 100% sure what was going on with that!

 

[thiggins]

Thanks, Jim. I'm no longer doing anything with MU-MIMO. Stable implementations are still hard to find and manufacturers aren't helping themselves by putting it in two-stream products.
It's just another acronym to slap on the box to impress buyers who don't know better.

As to why uplink looked better, it would be due to anything other than MU-MIMO. I've often seen uplink throughput better than downlink. Seems to have to do with the difference between Rx and Tx link rates.

 

[Jim Salter]

I was referring to [ uplink with MU-MIMO disabled ] vs [ uplink with MU-MIMO enabled ].

The roughly 20% improved throughput was nice, but the massive change in how fairly the airtime was divvied up was the big win.

I never tried it again with any other router than that C5400 though; at the time there weren't that many MU-MIMO routers either (though still more than MU-MIMO STAs of course).

 

[sfx2000]

As to why uplink looked better, it would be due to anything other than MU-MIMO. I've often seen uplink throughput better than downlink. Seems to have to do with the difference between Rx and Tx link rates.

Hmmm... if it were 11n, I'd agree perhaps, but with 11ac, UL/DL links are symmetric as per the standard.

The only thing I can think of is that with a MU capable chipset, the scheduler for SU only and MU/SU is different code, so that might be something... esp. since the client STA's and the AP are likely same vendor on the chipset side (QCA).

@Jim Salter - what happens with other client STA vendors on the same AP in the same test scenario?

 

[sfx2000]

Don't know, sfx. Just did the few relatively informal evaluations with the two Dell laptops and nothing else.

Fair enough - one of the trends that has been observed by many is the interaction between client STA's and a MU capable AP - performance there has been, to put it lightly, odd... esp cross-vendor.

 

[System Error Message]

20% throughput gains are significant if MU-MIMO improves airtime control. I still think that even in a dual channel AP that MU-MIMO does make sense from a consumer standpoint where most devices are either 1x1 or 2x2 usually from the same AP having a few phones/tablets with at most 1 or 2 laptops on at the same time, so the client numbers are high but they divide decently with traffic not being an equal factor (WAN speeds and usage).

 

[sfx2000]

Like I've mentioned, MU is hard stuff....

Even on the client STA side, it's challenging, as clients may decide to fall back from 2*2:2 to 2*2:1 to get better performance depending on the use case and connection attributes - to whit, many mobile handsets that have Broadcom based chipsets, make this choice, at least from my observations - falling back from AC867 to AC433.

MU is one of the reasons why I'm following the Roaming thing so closely, as Roaming brings yet another thing into play with 11r/k/v - and this in 11ac MU along with 11e Quality of Service.

And another challenge with VHT MU-MIMO - wasting time inside the MU group...

Take for example - we have two MU groups (we'll call them A and B) - assuming all are similar coverage, and as such, using the same MCS rate, we then look at the pending traffic - MU Group A assigns STA-1, STA-2, STA-3, and STA-4, MU Group B is STA-5 and STA-6.

STA1 has pending traffic with an A-MPDU of 1,048,575, and the other STA's in the MU group have shorter lengths - so the PPDU is based on the largest A-MPDU within the group...

See the problem? In the example above, the decision was already made, as the MU group assignment was already decided at an earlier time, and latency now causes us a problem where 40 to 45 percent of aggregate airtime is wasted - MU Group B is close to ideal, as the A-MPDU's are similar size, but this is only a snapshot in time.

MU is hard....

 

[sfx2000]

20% throughput gains are significant if MU-MIMO improves airtime control.

I think much of this just goes to "better" firmware/cores in the WiFi chipset to support MU - SU gets a win there...

If one looks at the computational load, there's a lot more CPU resources being applied... many of the more capable MU chipsets have Cortex-A9 level resources - the legacy devices that do not support MU are much lower - I think Broadcom on their first gen MU AP level chipsets under estimated the need there - QCA obviously got it right...

 

[System Error Message]

I think much of this just goes to "better" firmware/cores in the WiFi chipset to support MU - SU gets a win there...

If one looks at the computational load, there's a lot more CPU resources being applied... many of the more capable MU chipsets have Cortex-A9 level resources - the legacy devices that do not support MU are much lower - I think Broadcom on their first gen MU AP level chipsets under estimated the need there - QCA obviously got it right...

Yeah i find broadcom to overly advertise their products whereas qualcomm makes better chipsets but unfortunately they've been bought out as they do make good mobile chips too.

 

[avtella]

Yeah i find broadcom to overly advertise their products whereas qualcomm makes better chipsets but unfortunately they've been bought out as they do make good mobile chips too.

Broadcom deal was blocked for national security reasons.