<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jan 31, 2017, at 12:21 AM, Dave Taht <<a href="mailto:dave.taht@gmail.com" class="">dave.taht@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">A backstory of how I got involved in the bufferbloat effort was that I<br class="">deployed some shiny "new" and "faster" wireless-n radios (6 years<br class="">ago)... and my WISP network in Nicaragua collapsed in rain - which was<br class="">about 6 months after I'd made the cutover from g and from motorola's<br class="">radios. The signal strength was within expected parameters, the<br class="">achieved rates were half to 1/3 what they were dry, but latencies<br class="">climbed to over 30 seconds in some cases. I had *no* idea what was<br class="">going wrong at the time, and it wasn't until 6 months after I closed<br class="">the business that I ran into Jim Gettys, and the rest is history.<br class=""></div></div></blockquote><div><br class=""></div><div>Quite an interesting story, could be in the project background somewhere. :)</div><br class=""><blockquote type="cite" class=""><div class=""><div class="">I never got around to writing it up, I just gave a couple talks on the<br class="">subject and moved onto fixing bufferbloat thoroughly. We got<br class="">distracted by trying to solve it on the ISP backbones before tackling<br class="">wifi in this past year.<br class=""></div></div></blockquote><div><br class=""></div><div>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:</div><div><br class=""></div><div>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</div><div>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.</div><div><br class=""></div><div>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.</div><div><br class=""></div><div>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).</div><div><br class=""></div><blockquote type="cite" class=""><div class=""><div class="">... As for the performance of openmesh being pretty good... they were<br class="">the first group to test the fq_codel intermediate queues and ATF code<br class="">way back in september, :) - it's not clear to me if that's what you<br class="">were testing or not or they shipped an update yet.<br class=""></div></div></blockquote><div><br class=""></div><div>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.</div><br class=""><blockquote type="cite" class=""><div class=""><div class="">A good test to run is to lower the mcs rates (set the rateset<br class="">manually, or add distance, and/or rain) and to see how flat latency<br class="">remains. This is also a better test of real-world conditions, if you<br class="">can get some reports back on the actual mcs rates being achieved in<br class="">the field, and use those.<br class=""></div></div></blockquote><div><br class=""></div><div>This, I’m definitely going to try.</div><div><br class=""></div><div>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.</div><br class=""><blockquote type="cite" class=""><div class=""><div class="">It would be my hope that 802.11e is off (rrul will show this, and we<br class="">still do badly with it on)<br class=""></div></div></blockquote><br class=""><div>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.</div><br class=""><blockquote type="cite" class=""><div class=""><div class="">You can probably within this deployment shape the uplinks to some<br class="">fairly low value and get good performance more the time.<br class=""><br class="">I do not have any real hope for being able to make wifi better with<br class="">soft-shapers. It's a gordian knot - you need to respond rapidly to<br class="">changes in rate, both up and down, and mix up flows thoroughly,<br class="">optimize your aggregates to go to one station at a time and switch to<br class="">the next, and that's what we got with codel close to the hardware as<br class="">it is now in lede. [1]<br class=""><br class="">If it helps any, this is the best later talk I've given on these subjects:<br class=""><br class=""><a href="https://www.youtube.com/watch?v=Rb-UnHDw02o" class="">https://www.youtube.com/watch?v=Rb-UnHDw02o</a><br class=""></div></div></blockquote><div><br class=""></div><div>I understand. Enjoyed that talk thoroughly, thanks!</div><br class=""><blockquote type="cite" class=""><div class=""><div class="">UBNT's gear (commonly used by wisps) has some neat tricks to manage<br class="">things better, when I last took apart their qos system it was an<br class="">insane set of sfqs with sf’s.<br class=""></div></div></blockquote><div><br class=""></div><div>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.</div><div><br class=""></div></div></body></html>