<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=""><div class="">Thanks for the hint Jonathon. In general, this appears to be effective, at least for the flent rrul test.</div><div class=""><br class=""></div><div class="">Below are flent rrul_noclassification run graphs (flent.gz files available) and the script I used to set up fq_codel. I see close to link rate with iperf3 tests, which test throughput in only one direction, yet can still control the queue reasonably well when there’s bidirectional traffic. For example, I’ve got the total rate limited to 90 Mbit, and each average flow in a flent rrul test runs around 10 Mbit. There are four in each direction, eight total, so I see around 80 Mbit of TCP throughput along with the low rate traffic at around 6 ms latency, which is not bad.</div><div class=""><br class=""></div><div class="">If you set up fq_codel like this on both ends of the link, it doesn’t perform quite as well- latency goes up and throughput down a bit. There are probably some "unwanted interactions" when you do this. So it’s best to set it up on only end end of the link, probably the end whose egress heads towards the Internet if applicable, but I’m still thinking that through.</div><div class=""><br class=""></div><div class="">Again, for those reading this later, it would be best to just run fq_codel (or Cake but I’ll get to that next) on the egress right on the hardware with the WiFi interface attached. The interface will rate limit the queue automatically when there’s bidirectional traffic, and account for variable speed, so that should be a superior configuration. But this is a solution for when that isn’t possible, and the AQM has to be run on separate hardware, connected via Ethernet.</div><div class=""><br class=""></div><div class="">I still want to do more testing for my WISP, both with Cake and the new LEDE builds as well, in various configurations, so I hope to do that next and will start a new thread when there are results. For now, this “half duplex rate limiting” by running AQM on a common IFB interface may help people in some situations!</div><div class=""><br class=""></div><div class=""><a href="https://dl.dropboxusercontent.com/u/71551878/bufferbloat/fq_codel_90mbit.png" class="">https://dl.dropboxusercontent.com/u/71551878/bufferbloat/fq_codel_90mbit.png</a></div><div class=""><br class=""></div><div class=""></div><div class=""><a href="https://dl.dropboxusercontent.com/u/71551878/bufferbloat/fq_codel_90mbit_both.png" class="">https://dl.dropboxusercontent.com/u/71551878/bufferbloat/fq_codel_90mbit_both.png</a></div><div class=""><br class=""></div><div class=""><a href="https://dl.dropboxusercontent.com/u/71551878/bufferbloat/qos.sh" class="">https://dl.dropboxusercontent.com/u/71551878/bufferbloat/qos.sh</a></div><div class=""><br class=""></div><div><blockquote type="cite" class=""><div class="">On Dec 9, 2016, at 1:37 PM, Phineas Gage <<a href="mailto:phineas919@gmail.com" class="">phineas919@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">Ok, I had not realized that, thanks. :)</div><div class=""><br class=""></div><div class="">I’ve not seen this done anywhere, has anyone tried it? Otherwise I’ll give it a try and write back what I find.</div><div class=""><br class=""></div><div class="">In this case, the throughput for the backhaul links “should” be mostly stable, and we’ll just accept any variation as “no worse than before”.</div><div class=""><br class=""></div><div class="">It's true, I also want to try Cake (anywhere I wrote fq_codel that could be substituted with Cake), and I see from here (<a href="https://www.bufferbloat.net/projects/codel/wiki/Cake/#installing-cake-out-of-tree-on-linux" class="">https://www.bufferbloat.net/projects/codel/wiki/Cake/#installing-cake-out-of-tree-on-linux</a>) that it should work on the 3.16.7 kernel I need to target. Voyage Linux doesn’t install with kernel sources, but I should be able to get that compiled with their SDK.</div><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Dec 9, 2016, at 12:39 PM, Jonathan Morton <<a href="mailto:chromatix99@gmail.com" class="">chromatix99@gmail.com</a>> wrote:</div><div class=""><div class=""><br class=""><blockquote type="cite" class="">On 9 Dec, 2016, at 12:12, Phineas Gage <<a href="mailto:phineas919@gmail.com" class="">phineas919@gmail.com</a>> wrote:<br class=""><br class="">Given the half-duplex nature of 802.11 WiFi, is it possible to use fq_codel with software rate limiting on separate hardware from the WiFi radio, while still allowing at or near the full WiFi link rate?<br class=""></blockquote><br class="">Given that you can’t reliably predict the actual wifi throughput from userspace, and that it will vary over time due to external interference and path attenuation, that would be difficult.<br class=""><br class="">However, you *can* loop both the ingress and egress traffic through a common IFB interface, and shape that - using Cake, even.  That sounds like what you’re trying to experiment with.<br class=""><br class=""> - Jonathan Morton<br class=""><br class=""></div></div></blockquote></div><br class=""></div></div></blockquote></div><br class=""></body></html>