[Make-wifi-fast] Flent results for point-to-point Wi-Fi on LEDE/OM2P-HS available

[Pete Heist]

> On Jan 31, 2017, at 12:21 AM, Dave Taht <dave.taht at gmail.com> wrote:
> 
> A backstory of how I got involved in the bufferbloat effort was that I
> deployed some shiny "new" and "faster" wireless-n radios (6 years
> ago)... and my WISP network in Nicaragua collapsed in rain - which was
> about 6 months after I'd made the cutover from g and from motorola's
> radios. The signal strength was within expected parameters, the
> achieved rates were half to 1/3 what they were dry, but latencies
> climbed to over 30 seconds in some cases. I had *no* idea what was
> going wrong at the time, and it wasn't until 6 months after I closed
> the business that I ran into Jim Gettys, and the rest is history.

Quite an interesting story, could be in the project background somewhere. :)

> I never got around to writing it up, I just gave a couple talks on the
> subject and moved onto fixing bufferbloat thoroughly. We got
> distracted by trying to solve it on the ISP backbones before tackling
> wifi in this past year.

Yeah, I also don’t want to waste too much time trying to improve latency in their point-to-point Wi-Fi backhaul links unless it’s going to help. I suppose the questions are:

1) Are their backhaul links stable enough in all conditions to hold a steady enough rate that soft rate limiting is practical without sacrificing too much throughput AND
2) Is the sfq setup Ubiquiti has in their gear “good enough” in managing bufferbloat that it wouldn’t make much of a difference anyway.

As for the final connection to my residence, it's 3km NLOS through some deciduous trees close to me, so I have a better signal in winter with no leaves. While it’s pretty good all things considered (actual 20 Mbps up, 30 Mbps down when things are well), bitrate can vary maybe 20% because of the link, and more because of other network load. So even if fq_codel with soft rate limiting does help, which it does, it’s not as practical for my final connection to do it. Just thought of it now, but I wonder if I can run LEDE on my PowerBeam M5-400.

Anyway, that’s why I thought backhaul links are a better candidate for soft rate limiting (since they’re usually line-of-sight), if it even helps at all (TBD).

> ... As for the performance of openmesh being pretty good... they were
> the first group to test the fq_codel intermediate queues and ATF code
> way back in september, :) - it's not clear to me if that's what you
> were testing or not or they shipped an update yet.

Just to be clear, I was only testing LEDE on OM2P-HS. I’d like to test Chaos Calmer (or Open Mesh’s stock firmware), so I’m not mixing the testing of the ath9k changes with the qdiscs, but I’ll see if I get to this along with the Ubiquiti testing.

> A good test to run is to lower the mcs rates (set the rateset
> manually, or add distance, and/or rain) and to see how flat latency
> remains. This is also a better test of real-world conditions, if you
> can get some reports back on the actual mcs rates being achieved in
> the field, and use those.

This, I’m definitely going to try.

Although I can’t make it rain in my office :) I can use ‘iw dev wlan0 set bitrates ht-mcs-2.4 X’, where X is the MCS level. This appears to be effective, and I could even write a “rain.sh" and change it on the fly to see what happens.

> It would be my hope that 802.11e is off (rrul will show this, and we
> still do badly with it on)

802.11e is on, as it’s the default in LEDE and I didn’t change it. I can certainly turn that off and compare.

> You can probably within this deployment shape the uplinks to some
> fairly low value and get good performance more the time.
> 
> I do not have any real hope for being able to make wifi better with
> soft-shapers. It's a gordian knot - you need to respond rapidly to
> changes in rate, both up and down, and mix up flows thoroughly,
> optimize your aggregates to go to one station at a time and switch to
> the next, and that's what we got with codel close to the hardware as
> it is now in lede. [1]
> 
> If it helps any, this is the best later talk I've given on these subjects:
> 
> https://www.youtube.com/watch?v=Rb-UnHDw02o <https://www.youtube.com/watch?v=Rb-UnHDw02o>

I understand. Enjoyed that talk thoroughly, thanks!

> UBNT's gear (commonly used by wisps) has some neat tricks to manage
> things better, when I last took apart their qos system it was an
> insane set of sfqs with sf’s.

So that was one of my questions, is that setup “good enough” that external rate limiting and shaping isn’t worth it, even with a stable connection. TBD.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/make-wifi-fast/attachments/20170131/d20dbcdd/attachment.html>