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.
There's a couple different RT3200s out there... the belkin wifi 6 router? The client is on what wifi chip? Update - sorry, did not read the link to the pointer to the device...
You should be getting 100s of mbits out of this setup, but I'm confused - is HE20 a single channel, like HT20?
As much as I might advocate for minimal channel use, few folk testing ac and ax gear run below VHT80. If it's really a single channel then that's kind of near what we would expect from a wireless-n device.
But: The green BE download should not have run away with all the bandwidth, nor the ratio between down and up so poor.
What form of WPA is enabled? Update - still precoffee here - ok, WPA3. Try WPA2?
As for the wired result, pretty good, was there other traffic on the link to account for the upload loss at T+18 and T+49-T+52? (a 5 minute test is helpful for periodic checks)
the yoga's Intel Wireless AC-9560 should be fq_codel enabled in linux releases after 5.4, I think. Does it have noqueue as a qdisc and an aqm file in /sys/kernel/debug/iee*/phy*/aqm?
I think there is something else/more going on other than just a noqueue qdisc and lack of aqm on the linux client. I suspect HE20 (an 802.11ax throughput mode) might be part of it, but I don't think this explains the green BE download ending up with all the bandwidth. I do suspect other clients on the network are contributing to that.
@ka2107: simplest thing to do is retest a few times and see if the results reproduce (if possible try this with only one client on this band and then again with a few connected).
For reference, my linux kernel 5.4 laptop with an intel 7260 wifi card (noqueue qdisc, aqm file present but I cant output from it) connected to my r7500v2 on 5 GHz, channel 36, VHT80:
Multiple clients are connected to 5GHz but only the laptop is active during this test. Durring an earlier test, all the BE download streams went to near 0 Mbps at about 40s into the test for about 5 s and then recovered. This I suspect is the result of other 5GHz wifi clients network activity.
In short, @ka2107's set up should be "running circles around mine while laughing and singing happily"
FWIW, how AQL/ATF behaves with a "one" clinet flent test is useful to establish it's working as intended, nothing crashes, latency bugs are fixed, etc.; however, most use cases are with 6 to dozens of clients connected. I do still have wifi issues and I think they are related to how my AP behaves with multiple clients using it. I just don't know yet how to identify, demonstrate, or report it in a way that is "actionable" for a dev to fix it. I still suspect AQL/ATF contributing to that, but I also know its not all of it.
If there is still "fuel left in the tank" after the immediate bugs are sufficiently resolved, then maybe we could spend time on that - but I'm in no rush so take Aug. to ? off.
HE20 is 20 MHz 802.11ax (WiFi 6). In my Apt, channel 165 is the only channel that is completely free of any SSIDs. However Channel 165 is a 20 MHz only (no adjacent channels for 40 MHz or 80 MHz).
I thought with my plan speed being only 50/10 Mbps, I can get away with using only a single 20 MHz channel. My Google Pixel 6 connect to the WIFI in HE20 (802.11ax) mode and my Yoga laptop (Intel 9560) connects in VHT20 (802.11ac) mode.
# cat /sys/kernel/debug/ieee80211/phy0/aqm
access name value
R fq_flows_cnt 4096
R fq_backlog 0
R fq_overlimit 0
R fq_overmemory 0
R fq_collisions 0
R fq_memory_usage 0
RW fq_memory_limit 16777216
RW fq_limit 8192
RW fq_quantum 300
# uname -a
Linux 5.18.10-arch1-1 #1 SMP PREEMPT_DYNAMIC Thu, 07 Jul 2022 17:18:13 +0000 x86_64 GNU/Linux
