AQL and the ath10k is *lovely*

Yes, sorry about that.

@dtaht, just now on 21.02.1:

==== SUMMARY ====
Upload capacity: 34.483 Mbps
Download capacity: 237.941 Mbps
Upload flows: 16
Download flows: 12
Responsiveness: High (3622 RPM)
Base RTT: 11
Start: 11/7/2022, 1:25:24 pm
End: 11/7/2022, 1:25:37 pm
OS Version: Version 12.4 (Build 21F79)

@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.....

1 Like

Happy to do that for you tonight with lates rc5 withour remove patches 334 and 335 if you wish. I will try to do it in a Linux ARM64 QEMU VM.

1 Like

RPM 3600 w 12 flows. That's awesome.

and 800 with w 12 flows on the latest patchset?

ok, well, trying --te=download_streams=4 with a capture next? I'm really haunted by that fq bug but the behavior here doesn't look like that.

not sure how a vm helps in testing wifi.

@dtaht Is netperf-east.bufferbloat.net alive? I tried running Flent test to it from "my" setup here in USA (not the Macbook sitting in India).

Flent log for netperf-east.bufferbloat.net : https://gist.github.com/KA2107/87dac2b00a882db431f4c86dcffea01a

Router/AP: Belkin RT3200 running OpenWrt 22.03.0-rc5
ISP: Comcast Xfinity (USA), DOCSIS 3.1, 50/10 Mbps Plan, IPv4 + IPv6
Location: (near) Chicago, Illinois, USA

SQM on WAN: CAKE + layer_cake.qos, Download 50150, Upload 11134, Ingress options "ingress docsis besteffort nat dual-dsthost", Egress options "egress docsis diffserv4 nat dual-srchost ack-filter", no other overhead options defined

WIFI Settings: 5 GHz, Band 165, HE20, WPA3-SAE H2E, 802.11w mandatory, Beacon Interval 100, DTIM Interval 5

Client: Lenovo Thinkpad X1 Yoga
OS: Arch Linux x86_64
WIRED: Intel Ethernet I219-V
WIFI: Intel Wireless AC-9560 160 MHz (only upto 802.11ac / WiFi 5, does not support 802.11ax / WiFi 6)

Client and router are in the same room.

rrul_be test WIRED result for flent-newark.bufferbloat.net:

rrul_be-2022-07-10T221802.426248.flent_

rrul_be test WIFI result for flent-newark.bufferbloat.net:

rrul_be-2022-07-10T223716.028943.flent_

Correct. But, I'd like to insist rc5 minus patches 334 and 335. This is something to keep in consideration.

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.

1 Like

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.

3 Likes

you get a faster download from wifi than wired? :boggle: Don't know how that is possible. hmm...

I'm not responsible for netperf-east. atlanta, dallas, fremont, toronto (.starlink.taht.net) I maintain. I'll ping rich..

what's the ethernet driver on the yoga?

# lspci -v

00:14.3 Network controller: Intel Corporation Comet Lake PCH-LP CNVi WiFi
	Subsystem: Intel Corporation Device 0030
	Flags: bus master, fast devsel, latency 0, IRQ 16, IOMMU group 7
	Memory at ea238000 (64-bit, non-prefetchable) [size=16K]
	Capabilities: [c8] Power Management version 3
	Capabilities: [d0] MSI: Enable- Count=1/1 Maskable- 64bit+
	Capabilities: [40] Express Root Complex Integrated Endpoint, MSI 00
	Capabilities: [80] MSI-X: Enable+ Count=16 Masked-
	Capabilities: [100] Latency Tolerance Reporting
	Capabilities: [164] Vendor Specific Information: ID=0010 Rev=0 Len=014 <?>
	Kernel driver in use: iwlwifi
	Kernel modules: iwlwifi

00:1f.6 Ethernet controller: Intel Corporation Ethernet Connection (10) I219-V
	Subsystem: Lenovo Device 2292
	Flags: bus master, fast devsel, latency 0, IRQ 167, IOMMU group 12
	Memory at ea200000 (32-bit, non-prefetchable) [size=128K]
	Capabilities: [c8] Power Management version 3
	Capabilities: [d0] MSI: Enable+ Count=1/1 Maskable- 64bit+
	Kernel driver in use: e1000e
	Kernel modules: e1000e

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.

SPEEDTEST (same client location as when running flent)

speedtest


SERVER: locally running on the router (R7800, performance governor)



SERVER: netperf-west.bufferbloat.net



SERVER: flent-fremont.bufferbloat.net



2 Likes

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...

but the rest is so darn noisy.

1 Like

Wow! Looks like today I'm in a roll...

21.02.1 baseline:

Summary of tcp_ndown test run from 2022-07-11 05:12:50.762651
  Title: 'flent_tcp_ndown_60s_openwrt_v21.02.1_mt76'

                             avg       median          # data pts
 Ping (ms) ICMP   :        19.80        21.50 ms             1400
 TCP download avg :       141.10          N/A Mbits/s        1400
 TCP download sum :       564.41          N/A Mbits/s        1400
 TCP download::1  :       157.18       151.26 Mbits/s        1400
 TCP download::2  :       144.03       144.43 Mbits/s        1400
 TCP download::3  :       124.73       129.23 Mbits/s        1400
 TCP download::4  :       138.47       139.84 Mbits/s        1400

flent tcp_ndown 4x streams 21.02.1 (click me to download)

22.03.0-rc (minus patches 334 and 335):

Summary of tcp_ndown test run from 2022-07-11 05:23:29.328235
  Title: 'flent_tcp_ndown_60s_openwrt_v22.03.0-rc5_mt76'

                             avg       median          # data pts
 Ping (ms) ICMP   :        22.30        23.85 ms             1400
 TCP download avg :       113.68          N/A Mbits/s        1400
 TCP download sum :       454.72          N/A Mbits/s        1400
 TCP download::1  :       114.57       115.62 Mbits/s        1400
 TCP download::2  :       108.56       111.56 Mbits/s        1400
 TCP download::3  :       118.48       118.65 Mbits/s        1400
 TCP download::4  :       113.11       114.43 Mbits/s        1400

flent tcp_ndown 4x streams 22.03.0-rc5 (minus patches 334 and 335) (click me to download)

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 :slight_smile:

@amteza are you removing patches 334/335 because it actually makes a difference, or just because I recommended it for a specific test a while back?

@vochong - I don't trust those specific servers at these speeds either. It's my hope that the new cloud is better.

Moving to your wired lan result with induced latency ~12ms, the current record-holder is cake on the APU2: AQL and the ath10k is *lovely* - #621 by sebastian_de

Which clocks in at 1.5ms or so. I have always been kind of curious (is this a nss enabled build? Validating NSS fq_codel's correctness - #58 by KONG) what happens on this test with just

tc qdisc replace dev your_lan_interface root nssfq_codel limit 4096 flows 1024 quantum 1514 target 5ms interval 100ms set_default

Going to the wifi result... yuck! How distant from the AP are you?

@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.

1 Like

@dtaht I have setup local netperf and irtt server in my Belkin RT3200 router (thanks to @anon98444528 AQL and the ath10k is *lovely* - #608 by nmrh for the instructions). I also installed iperf and irtt in my Arch Linux setup. Those packages were not installed during the previous tests AQL and the ath10k is *lovely* - #674 by ka2107 (netperf was installed though) and ran both WIRED and WIFI rrul_be tests:

Router (also AP) and Client setup: AQL and the ath10k is *lovely* - #674 by ka2107

I did not monitor router CPU usage during the tests.

rrul_be WIRED test to local router/AP:

rrul_be-2022-07-11T114042.151627.flent_

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.

rrul_be-2022-07-11T114655.740175.flent_