Bufferbloat, speedtest, flent's rtt_fair tests, and cambium

Products ePMP
1

Hi, I’m dave taht, director of the bufferbloat and make-wifi-fast project. I am under the impression that long ago, cambium actually put in some good tech to do airtime fairness well and some fair queuing things, and I’m pretty sure it’s not fq_codel. I’m cool with that (I’ve worked on many other FQ+ AQM types over the years, despite fq_codel and cake being the best known) - but I was wondering how well cambium was actually doing. The new speedtest app (just out last week) does some latency under load tests, and our flent.org tool’s rtt_fair and rrul tests are generate some useful and interesting results.

Is there anyone out there that could run these tests in an ePMP scenario and get back to me? You can see the swath of flent tests I’ve cut across various other products over the last few months in researching how well we were defeating the scourge of bufferbloat.

2 Likes
2

We’d be happy to help test, what would be required on our end?

2 Likes
3

The simplest test is rtt_fair against my cloud: One liner and some examples here: SQM on turris flent benchmarks? - Omnia HW tweaks - Turris forum - you just need a (preferably wired) client running through a cambium radio for that.

Some more complicated tests are described on the mikrotik thread on ‘quick comments on configuring cake’. (in both these cases I was trying to test “my” stuff, in the cambium case I’m trying to see how well cambium is doing by default - I try to stress “we’re all in this bloat together” - and lack the educational energy to do more that point to the explanations of the network behaviors on that particular thread)

In terms of bench testing a cambium setup, which is the most interesting and accurate, an ideal topology is:

S1 (server) → SR1 (ePMP radio) → R1, R2, R3, R4 (client radios)
C1, C2, C3, C4 - client boxes behind those ePMP radios - these can be as weak as a raspi. If you can push more than a gbit, more than one server or a heftier server might be required

Using linux for these boxes is easy, bsd, feasible, but using debian style syntax for the sake of example:

apt-get install flent irtt netperf iperf iperf3 # on all boxes

some linuxes you have to compile and install netperf yourself with ./configure --enable-demo

To browse and plot the results with flent-gui some additional libs need to be installed, but this is not needed on the servers or clients.

You can start by just testing one client to the server and run through the tcp_nup, tcp_ndown, rrul, rrul_be tests to get a baseline.

rtt_fair_var is a test of as many boxes you can setup. In terms of testing the effectiveness of ATF, one of those should have poorer quality characteristics - range/interference/a tree in the way.

2 Likes
4

In terms of catnip for network nerds, here’s 1.2Gbyte of flent data and the structure d batch tests we used for evaluating fq_codel for wifi, the APIs for which went into linux 4.12 - now supported by 7 chipsets/ That contained our ATF tests, the schedular tests, and much more.

I point to the last hop - the wifi router - as the biggest problem most have today, but in this thread I’m hoping to assuage my fears that other forms of wireless backhaul are getting this right. 5G is performing miserably - 3+sec of latency under load. Starlink, better only half second or so.

I’d also pointed at the new speedtest app to kick this off.

1 Like
5

Over here I’d eloquently explained the aggrgation and ATF problem wifi had had and the need for multi-station testing in 8 minutes:

1 Like
6

You would need a login to view the graphs and explanations here:

https://forum.mikrotik.com/viewtopic.php?t=179307

2 Likes
7

Our experience with Cambium EPMP 3000 series (802.11AC standard) was that it had substantially higher latency and jitter than Airmax AC. Perhaps this is because fq_codel is baked into Airmax but not EPMP? Would be interesting to see if this has changed with EPMP 4000 series, which uses the 802.11AX standard. Our PtP Cambium EPMP 425s all work great with regard to latency in comparison to anything else out there, but we won’t know about the PtMP performance until EPMP 4000 APs are out to market. Perhaps Cambium can put Dave in touch with the Beta testers of the EPMP 4000 APs to see if there’s opportunity to fix queuing before 4K hits the market? Getting EPMP latency and bloat reduced would make it very competitive. Latency was our main concern that held us back from deploying EPMP. Having better queuing in EPMP 4K would be really great.

2 Likes
8

Anything new on this from Cambium? :upside_down_face:

2 Likes
9

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.