On Mon, Nov 19, 2018 at 3:56 PM Ben Greear <greearb@xxxxxxxxxxxxxxx> wrote: > > On 11/19/2018 03:47 PM, Dave Taht wrote: > > On Mon, Nov 19, 2018 at 3:30 PM Simon Barber <simon@xxxxxxxxxxxxxx> wrote: > >> > >> > >> > >> On Nov 19, 2018, at 2:44 PM, Toke Høiland-Jørgensen <toke@xxxxxxx> wrote: > >> > >> Dave Taht <dave@xxxxxxxx> writes: > >> > >> Toke Høiland-Jørgensen <toke@xxxxxxx> writes: > >> > >> Felix Fietkau <nbd@xxxxxxxx> writes: > >> > >> On 2018-11-14 18:40, Toke Høiland-Jørgensen wrote: > >> > >> This part doesn't really make much sense to me, but maybe I'm > >> misunderstanding how the code works. > >> Let's assume we have a driver like ath9k or mt76, which tries to keep a > >> > >> …. > >> > >> > >> Well, there's going to be a BQL-like queue limit (but for airtime) on > >> top, which drivers can opt-in to if the hardware has too much queueing. > >> > >> > >> Very happy to read this - I first talked to Dave Taht about the need for Time Queue Limits more than 5 years ago! > > > > Michal faked up a dql estimator 3 (?) years ago. it worked. > > > > http://blog.cerowrt.org/post/dql_on_wifi_2/ > > > > As a side note, in *any* real world working mu-mimo situation at any > > scale, on any equipment, does anyone have any stats on how often the > > feature is actually used and useful? > > > > My personal guess, from looking at the standard, was in home > > scenarios, usage would be about... 0, and in a controlled environment > > in a football stadium, quite a lot. > > > > In a office or apartment complex, I figured interference and so forth > > would make it a negative benefit due to retransmits. > > > > I felt when that part of the standard rolled around... that mu-mimo > > was an idea that should never have escaped the lab. I can be convinced > > by data, that we can aim for a higher goal here. But it would be > > comforting to have a measured non-lab, real-world, at real world > > rates, result for it, on some platform, of it actually being useful. > > We're working on building a lab with 20 or 30 mixed 'real' devices > using various different /AC NICs (QCA wave2 on OpenWRT, Fedora, realtek USB 8812au on OpenWRT, Fedora, > and some Intel NICs in NUCs on Windows, and maybe more). I'm not actually sure if that realtek > or the NUCs can do MU-MIMO or not, but the QCA NICs will be able to. It should be at least somewhat similar > to a classroom environment or coffee shop. In the last 3 coffee shops I went to, I could hear over 30 APs on competing SSIDs, running G, N, and AC, occupying every available channel. > I'll let you know what we find > as far as how well MU-MIMO improves things or not. Thank you. My lab is shut down and I'm selling off the gear, so all I can do anymore is be grumpy. > > At least in simple test cases (one 1x1 stations, one 2x2 station, with 4x4 MU-MIMO AP), > it works very well for increased download throughput. Is that a UDP or TCP test? My specific "most important" benchmark for wifi is web PLT with lots of stations. That's the most common wifi use case, IMHO. Some videoconferencing, voip, ssh, etc. One big upload, one big download, going on somewhere, sometimes. Slashdot for me is 78 separate ssl'd tcp flows, a dozen + dns lookups, over 2.2 seconds. bulk downloads rarely figure in except for streaming video, and that peaks out generally at 20Mbit/sec for most people. So while I do like the potential in mu-mimo to, schedule lower service times on a per station basis, I see too many variable rates and interference in the real world, and not enough simultaneity between schedulable stations, and a ton of acks, for me to imagine there's much of a real-world difference from mu-mimo in anything other than a well managed office or stadium. People going for the max download throughput with the max number of stations... PLT, PLT is a way better benchmark. I can certainly be convinced by data, and I look forward to your experiments. > In home setups, I'd guess that the DSL or Cable Modem or other uplink is the bottleneck Offices too. Wifi - aside from interference and range issues lowering the rate, only becomes the bottleneck at internet speeds > 40Mbits/sec. We are certainly starting to see wifi become more of the bottleneck, while running at rates, generally, far lower than what people bench at. > way more often than the wifi is, even if your are just running /n. But, maybe that is just > my experience living out at the end of a long skinny phone line all these years. Fiber networks and newer cable connections now crack 100mbits, and there you do see all that nifty fq_codel-ly chocolatey goodness kicking in.... but I do tend to think the optimization focus should be at low rates with lots of stations for plt more than bandwidth. > Thanks, > Ben > > > > -- > Ben Greear <greearb@xxxxxxxxxxxxxxx> > Candela Technologies Inc http://www.candelatech.com > -- Dave Täht CTO, TekLibre, LLC http://www.teklibre.com Tel: 1-831-205-9740
