Ansuel
3811
So it was actually a firmware problem... Glad I didn't waste too much time tracking that
Looks like it, also they really started pushing a ton of fixes in the last few days.
So, 5.15 is gonna be a big one when it comes to ath11k.
1 Like
This RX decap patch gave me hint that now it is only working in TX direction. So I tried iperf3 with -R and I am getting 790Mbits/sec without saturating any single core. So it looks like encap offload is working but just in TX direction.
Ansuel
3814
think we will have to start using backport package based on 5.15 directly instead of backporting single patch...
Well, somebody has to make the 5.15 based backports.
I tried doing the 5.13 once and it's a world of pain as they require it to work back to some 3.x version and it's really not straightforward.
I tried doing it for 5.4 and 5.10 kernels but even getting those to compile with the new changes was too difficult.
yes encap offload is tx only
Hummm... I just tried Ansuel's offload patches on the latest source tree, and it caused kernel panic 
Here the log is: https://paste.debian.net/hidden/4a66cb9c/
1 Like
I built an image last night with this new FW and it seems to be working well (I ran it overnight). I'm now also testing that encap offload based on @castiel652's post. That being said I was already able to push near-Gigabit speeds even with SQM (fq_codel) so I'm not sure how much of a difference I'd be expecting to see other than just reduced CPU utilization.
Also, it seems I mis-characterized the memory leak. While I definitely observed it go from like 200 MB to 260 MB overnight on that first night, it seemed to have dropped down after that actually. Like after I got home from work yesterday (~18 hours of runtime) it had actually dropped down to like 220 MB; so it seems there is at least some memory being freed up periodically.
joba-1
3819
both observations exactly match my results after updating (I'm not using sqm though).
-
I get 101 Mbytes/s (~95% cpu load) and with offload in TX 111 MBytes/s (~85% cpu load).
Bottleneck seems to be cpu load for irq. TX and RX do not add up, no full duplex. Sending more streams in parallel does not help. Seems to be serialized in the network layer.
-
Memory starts at ~200-220MB free after reboots and goes down to ~60-80MB free with usually +/-40MB during the first hour where it stays.
Some extreme cases then lead to oom issues.
When using less size for ath10 and ath11 buffers/queue, normal free memory is ~20MB more.
Then I don't see oom issues while also not having a noticeable performance hit.
Final observation:
I still have roaming delays of ~150s. (I think) I applied patch series "ath11k: fix 4-addr tx failure for AP and STA modes - Patchwork". But it didn't help.
Keep up the good work - and enjoy your vacation 
1 Like
I still see some strange low performance when transferring files between my synology NAS and MacBook Air connected via wifi.
While I get very good speeds when running iperf3 between the router and my Macbook (around 101 Mbytes/s). Its only about 20 Mbytes/s between my MacBook and the NAS.
If I run iperf between Router and Synology NAS it nearly saturates the gigabit connection (around 110 Mbytes/s).
Is there anything I can tweak / provide to help finding out what's going on?
Hello,
I blocked my x3600 router with the red light.
I have the functional 232 connection I connect.
I can't write frimware I get this message
*** Warning: no boot file name; using 'C0A81F01.img'
Using eth0 device
TFTP to server 192.168.31.100; our IP address is 192.168.31.1
Filename 'C0A81F01.img'.Save address: 0x0
Save size: 0x0
Saving: *
Got TFTP_OACK: TFTP remote port: changes from 69 to 51713
0 Bytes/s
thank you very much for your work.
joba-1
3822
That does not look normal, right?
build of restart branch, I guess since the firmware commit?
make
...
Hash of the local file ath11k-firmware-2021-07-20-d4003c19.tar.xz does not match (file: 6839081bafbc56d3b8e41d30790b20813c349cbc1732e887347ef5ed3ea717e4, requested: 25c340b1dc9a8847bf86e478d95577b82bf6a5617692a2c8eaec63e4ee7d40dd) - deleting download.
ath11k-firmware-2021-07-20-d4003c19.tar.xz: Download from https://github.com/kvalo/ath11k-firmware.git failed
ath11k-firmware-2021-07-20-d4003c19.tar.xz: Wrong hash (probably caused by .gitattributes), expecting 25c340b1dc9a8847bf86e478d95577b82bf6a5617692a2c8eaec63e4ee7d40dd, got 6839081bafbc56d3b8e41d30790b20813c349cbc1732e887347ef5ed3ea717e4
Checking out files from the git repository...
Cloning into 'ath11k-firmware-2021-07-20-d4003c19'...
remote: Enumerating objects: 897, done.
remote: Counting objects: 100% (81/81), done.
remote: Compressing objects: 100% (61/61), done.
remote: Total 897 (delta 19), reused 75 (delta 15), pack-reused 816
Receiving objects: 100% (897/897), 69.85 MiB | 6.76 MiB/s, done.
Resolving deltas: 100% (447/447), done.
Note: switching to 'd4003c1921810adcc455d46f17776a3392b29436'.
You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by switching back to a branch.
If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -c with the switch command. Example:
git switch -c <new-branch-name>
Or undo this operation with:
git switch -
Turn off this advice by setting config variable advice.detachedHead to false
HEAD is now at d4003c1 QCA9074 hw1.0: 2.5.0.1: add WLAN.HK.2.5.0.1-01100-QCAHKSWPL_SILICONZ-1
Packing checkout...
build doesn't fail due to this
disable firewall on PC with TFTP server. Please also move that question into: Xiaomi AX3600 INT firmware - #570 by tlala to keep this topic for devs
Yes that’s the hash problem that was reported when I made the PR but I wasn’t able to reproduce it.
Building should be fine though.
EDIT: I tried it again now the hash is the same as yours. guess I will send another PR to fix it.
1 Like
psi-c
3826
Confirming those patches fix non-WDS roaming for me, with the APs connected via Ethernet. I can switch wifi clients between the 2 APs (one AX3600, and Asus) and no noticeable downtime anymore.
2 Likes
joba-1
3827
very promising! Then I will try this set as well. I don't have all of them right now and it does not work.
@castiel652 : do I have the correct firmware then (I think so...)?
[ 12.184486] ath11k c000000.wifi: fw_version 0x250684a5 fw_build_timestamp 2021-07-13 10:57 fw_build_id QC_IMAGE_VERSION_STRING=WLAN.HK.2.5.0.1-01100-QCAHKSWPL_SILICONZ-1
Yes that's the correct one.
1 Like
@dspalu32 Can you make a PR with those patches?
I would do it myself but I have shitty internet on vacation and no way of testing.
Roaming is quite important
Good news if those patches help wired roaming, though it's not immediately obvious to me how anything except WDS/4addr modes would be affected.
Walking around the house running Ubiquiti WiFiman on my phone, I can cause lots of roaming without any glitches in connectivity. This is switching between 3x WDS-bridged AX3600, with each running 5GHz and 2.4GHz APs all simply using the same SSID (i.e. not 802.11r). I'm very happy.
@robimarko It'll be a few days before I'm at a computer again too.
