> On Jan 31, 2017, at 12:55 AM, Dave Taht <dave.t...@gmail.com> wrote: > > * Question #16: Is there any other testing anyone would like to see > while I have this rig up? > > 1) ECN on on both sides. > 2) A voip test > 3) P2MP (3 or more stations, rtt_fair_var* tests) > 4) Lowered MCS rates or distance or rain
Ok, I’ll see what I can do on 1, 2 and 4. #3 might be for another day, another site (Open Mesh at an outdoor camp, another story), but I’d like to get to it. > * Question #15: FreeNet's link to the Internet is 1 Gbps, and AFAIK > does not experience saturation. The e1000 ethernet driver that the > Internet router uses supports BQL. Is there any sense in running > fq_codel or similar on the router, if it does not become saturated? > > You don't need queue management until you need queue management. A > basic flaw of mrtg's design in your graph here is that it takes > samples in 5 minute windows. If you are totally nuking your link for 1 > sec out of 5 and the rest nearly idle, you won't see it. A flent test > in their offices to somewhere nearby over that link will be revealing. > > In general, applying fq_codel on a BQL enabled system is always a > goodness, it costs next to nothing in CPU to do it that way. > (outbound). Depending on your measurement of what happens on inbound, > you might want to do inbound rate shaping…. Ok, I’ll see if they’re game to try that. That would be great if it helped. > The gains are relative to the bandwidth and the amount of fixed > buffering in the radio. For example, I can get 320Mbits/sec out of the > archer c7v2's ath10k, with 10ms latency, at 8 feet. 20 feet, and > through a wall, it's 200Mbit/100ms latency. I don't like the initial > shape of that curve! (what I typically see happen on 802.11ac is it > hitting a wall and not working at all) My testing was actually through one wall also (drywall). I didn’t have the radios right next to one another. But I’m at 2.4 Ghz and I think you’re at 5 GHz, so walls are going to affect that setup more, of course. I’m surprised how much of a latency hit you see through one wall. > I happen to like ubnt's gear, although their default firmware only > lasts 5 minutes for me these days. They have very good throughput and > latency characteristics with decent signal strength. I look forward to > a benchmark of what you can get from them. (I am still looking for a > good upgrade from the nanostation M5s) My PowerBeam M5-400 has been very stable. I think I’ve only rebooted it for config changes or on general principle. > Question #12: What's the reason for Cake's occasional sudden > throughput shifts, and why do its latencies tend to be higher than > fq_codel? > > We are still debugging cake. Recently the API got a bit wacked. The > AQM is tuned for DSL speeds. More data is needed. Ok, there’s plenty of Cake data in my results to mine, or if Jonathan asks I’ll try something else. > * On the pfifo analysis - I really enjoyed the rush song and it was > very appropriate for how pfifo misbehaves! > > * Question #9: Does my assertion make sense, that it's "better" to do > half-duplex queueing on only one end of the link? The side towards the > Internet? > > Usually the stuff coming from the internet dominates the traffic by a > 8-20 figure, so coming from might be a worthwhile place to shape. > > I ran out of time before tackling 8-1.... Thanks for all the help. After I test more from your suggestions, I’ll re-post with results and any remaining questions, but a lot of it’s clearing up for me! _______________________________________________ Cake mailing list Cake@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cake