@amteza thx for the baseline and going the extra mile for me today. Your 21.02.1 result is clearly better at T+120 forward, with less periodicity of the latency swings vs a vs airtime.
I can imagine prior to T+120 other sources of environmental noise, and osx issues also.
My fantasy is that everyone runs rrul tests all night long against the current patchset, and it doesn't crash and the noise is exposed as just that, wireless noise.....
It's the only Linux box I can stand up. The idea is to run Linux bridging the WiFi interface. This is just because you are sharing your weariness of macOS.
Apologies, sometimes I forget people don't know what I'm thinking of.
I am very happy we can actually test via OSX. I drowned my 2013 air over a year ago, and disliked the m1 replacement I got so much as to give it back. Happy also that flent works again. happy also to see solid if less than perfect long term results and no crashes and having y'all be so interested in helping.
I ran the RRUL BE tests against 3 servers. The test was repeated twice for each server. The router R7800 runs 22.03.0 RC5 image with NSS acceleration and without SQM enabled. ISP D/L speed ~ 650 Mbps / 220 Mbps. Router and client are about 50ft away from each other, with 3 dry walls in between.
Locally running on R7800 (Performance governor, NSS accelerated, no SQM)
thx @vochong - wow - gang's all here! too many variables under test. Any chance you have a seperate server you can hook up to the lan or wan port you can put netperf on, so we can just test the wifi? Or can you put the flent client on the lan port so we can just test the isp link?
The period in your second local test is suggestive...
Flent client was connected (1000Mb/s, full duplex) to a LAN port on the router R7800. The test was repeated twice against the server flent-fremont.bufferbloat.net.
Somehow I don't fully trust these public Flent servers. The graphs only look nice for people having relatively slow D/U speeds. I will connect a local Flent server on the WAN port and then LAN port and run the tests tomorrow.
Here are the wired tests against local server running on the router R7800 itself. Compare them to the similar tests (same local server) for wireless client, we just have to think of WIFI like a living beating heart and wired Ethernet like a dead flat-lined electrocardiogram. Make WIFI a livingly "lovely" tsunami, not deadly "homely" flat-liner! J/k
@amteza Thx for showing a 110Mbit loss of throughput on this simper test comparing the reference release and your patchset.
Going back to the rpm test, I see it is using 20! download streams in your 800 RPM case, and 12 in the 3600 case.
Could you repeat the ndown test with 20 flows? (working hypothesis: we are scaling badly as we add flows)
Do you have two boxes setup for this or are you reflashing the same one? Even a distance of a millimeter could be accounting for the throughput difference.
I did not monitor router CPU usage during the tests.
rrul_be WIRED test to local router/AP:
rrul_be WIFI test to local router/AP:
Client and router are in the same room. No wall in between.
"iwd" showed RSSI as -4300 which I believe translates to -43 dBm.
My Google Pixel 6 phone sitting next to the laptop showed same WiFi SSID RSSI as -38 dBm.