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

[Pete Heist]

> On Jan 31, 2017, at 12:55 AM, Dave Taht <dave.taht at 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!