AQL and the ath10k is *lovely*

Here you go (click to download flent data files, rrul_be and tcpndown 2-threaded and its tcpdump -s 128 .cap file):

Permanently a separate server, the AP is just a dumb AP.

Offloading is disabled.

It is running cubic.

Did capture with -s 128.

I can't install tc to check. Is there another way? Sorry for my naïve query.

On a side note, reviewing the source code, should we keep the contents of the else's statement like below?

@@ -2697,15 +2697,6 @@ static void sta_update_codel_params(struct sta_info *sta, u32 thr)
 	if (!sta->sdata->local->ops->wake_tx_queue)
 		return;
 
-	if (thr && thr < STA_SLOW_THRESHOLD * sta->local->num_sta) {
-		sta->cparams.target = MS2TIME(50);
-		sta->cparams.interval = MS2TIME(300);
-		sta->cparams.ecn = false;
-	} else {
-		sta->cparams.target = MS2TIME(20);
+		sta->cparams.target = MS2TIME(8);
		sta->cparams.interval = MS2TIME(100);
		sta->cparams.ecn = true;
-	}
 }

thx. you aint naive, at this point yer the most highly qualified tester fq_codel has had since @tohojo graduated.

cat /sys/kernel/debug/iee*/phy*/aqm

1 Like

Okay, see below for my quantum values:

access name value
R fq_flows_cnt 4096
R fq_backlog 0
R fq_overlimit 0
R fq_overmemory 0
R fq_collisions 235
R fq_memory_usage 0
RW fq_memory_limit 4194304
RW fq_limit 8192
RW fq_quantum 300
access name value
R fq_flows_cnt 4096
R fq_backlog 0
R fq_overlimit 0
R fq_overmemory 0
R fq_collisions 1272751
R fq_memory_usage 0
RW fq_memory_limit 16777216
RW fq_limit 8192
RW fq_quantum 300

I think 300 should be find as I'm not "CPU bounded", don't think we need to increase it to 1514. Second set is the one we are testing on (phy1).

just to be utterly certain you are testing the server... "openwrt.lan" is usually the name of the AP not a device connected to it...

Fair query:

openwrt.lan -> OpenWrt RPi4 acting as router (no wireless interface)
nanohd-downstairs.lan -> dump AP connected to openwrt.lan via 1 Gbps Ethernet
Macbook pro -> connected to nanohd-downstairs.lan wirelessly

1 Like

ok, thx, and thx especially for the caps. From which vantage point are you getting those from?

I'm capturing them on the macOS computer.

theres a pretty version (in java I think) of xplot.org for osx, that and tcptrace -G, don't require a working matplotlib. :slight_smile:

I am told these are coming along.

https://gitlab.quatermass.co.uk/jgh/tcptrace
https://gitlab.quatermass.co.uk/jgh/xplot

1 Like

on osx:

sudo netstat -l your_device -qq

and I'm calling it a day. New theory - the rpi (openwrt.lan) has something rate limiting the performance of it's stack.

Before calling it a day -see below. May I ask what you expect to find with the output of that command?

netstat output (too long to paste directly)

Going to enjoy Father's day for a little while. :wink:

heh. I gave you the wrong command. -qq -I (thats an I not an L) should show the native fq_codel stats on the osx box. and even that might be the wrong command... gimmee sec

It makes more sense now, I should realise; here you go:

@reaper$ ➜  ~ sudo netstat -I en0 -qq
en0:
     [ sched:  FQ_CODEL  qlength:    0/128 ]
     [ pkts:  124486499  bytes: 170983491083  dropped pkts:  44041 bytes: 65229549 ]
=====================================================
     [ pri: VO (1)	srv_cl: 0x400180	quantum: 605	drr_max: 8 ]
     [ queued pkts: 0	bytes: 0 ]
     [ dequeued pkts: 33377	bytes: 6044211 ]
     [ budget: 0	target qdelay: 10.00 msec	update interval:100.00 msec ]
     [ flow control: 0	feedback: 0	stalls: 0	failed: 0 	overwhelming: 0 ]
     [ drop overflow: 0	early: 0	memfail: 0	duprexmt:0 ]
     [ flows total: 0	new: 0	old: 0 ]
     [ throttle on: 0	off: 0	drop: 0 ]
     [ compressible pkts: 0 compressed pkts: 0]
=====================================================
     [ pri: VI (2)	srv_cl: 0x380100	quantum: 3028	drr_max: 6 ]
     [ queued pkts: 0	bytes: 0 ]
     [ dequeued pkts: 5842684	bytes: 8182467304 ]
     [ budget: 0	target qdelay: 10.00 msec	update interval:100.00 msec ]
     [ flow control: 355	feedback: 355	stalls: 12	failed: 0 	overwhelming: 0 ]
     [ drop overflow: 0	early: 0	memfail: 0	duprexmt:0 ]
     [ flows total: 0	new: 0	old: 0 ]
     [ throttle on: 0	off: 0	drop: 0 ]
     [ compressible pkts: 0 compressed pkts: 0]
=====================================================
     [ pri: BE (7)	srv_cl: 0x0	quantum: 1514	drr_max: 4 ]
     [ queued pkts: 0	bytes: 0 ]
     [ dequeued pkts: 118254467	bytes: 162519175698 ]
     [ budget: 0	target qdelay: 10.00 msec	update interval:100.00 msec ]
     [ flow control: 9243	feedback: 9243	stalls: 40	failed: 0 	overwhelming: 0 ]
     [ drop overflow: 0	early: 43041	memfail: 0	duprexmt:0 ]
     [ flows total: 0	new: 0	old: 0 ]
     [ throttle on: 0	off: 0	drop: 0 ]
     [ compressible pkts: 0 compressed pkts: 0]
=====================================================
     [ pri: BK (8)	srv_cl: 0x100080	quantum: 1514	drr_max: 2 ]
     [ queued pkts: 0	bytes: 0 ]
     [ dequeued pkts: 355971	bytes: 275803870 ]
     [ budget: 0	target qdelay: 10.00 msec	update interval:100.00 msec ]
     [ flow control: 3	feedback: 3	stalls: 0	failed: 0 	overwhelming: 0 ]
     [ drop overflow: 0	early: 0	memfail: 0	duprexmt:0 ]
     [ flows total: 0	new: 0	old: 0 ]
     [ throttle on: 0	off: 0	drop: 0 ]
     [ compressible pkts: 83604 compressed pkts: 34500]

enjoy your fathers day. It is labor day here... and we have labored mightily.

did you patch the kernel or the mac80211 package?

wmm_ac_be_txop_limit=32 you see on the osx box?

this was a good result from aug 4:

a tcpdump of 2 flows up woul be useful also.

I patched package/kernel/mac80211.
Update: 1:38 AEDT - I just realised my mistake, recompiling and letting it ready for re-testing tomorrow in the early morning.

Yes, Sir, see below:

But I didn't use today the below parameters, I only modified txop=32, and I used burst=0.

tx_queue_data2_aifs=1
tx_queue_data2_cwmin=7
tx_queue_data2_cwmax=15
tx_queue_data2_burst=3.0

I will do it tomorrow.

Another round.
WMM test parameters:

tx_queue_data2_aifs=3
tx_queue_data2_cwmin=15
tx_queue_data2_cwmax=63
tx_queue_data2_burst=0

wmm_ac_be_txop_limit=0

AQL test parameters:

root@nanohd-downstairs:~# cat /sys/kernel/debug/ieee80211/phy1/aql_txq_limit
AC	AQL limit low	AQL limit high
VO	5000		12000
VI	5000		12000
BE	5000		12000
BK	5000		12000
root@nanohd-downstairs:~# cat /sys/kernel/debug/ieee80211/phy1/aql_threshold
24000
root@nanohd-downstairs:~# cat /sys/kernel/debug/ieee80211/phy1/aql_enable
1

flent rrul_be test:

flent tcpn[up,down] 2-threaded test:

3 Likes

yuck.

w/aql disabled?

1 Like

Sadly, nope. You can see this in the parameters list I posted before the graphs.

Where were we in july?

"At least it doesn't crash."