Hmm I don't know, getting my ~ 500 Mbits here with a dumb AP via LAN server. (my wan cannot provide such high data rates, lan can).
Maybe try completely disabling ipv6 in /etc/sysctl.conf. That gave my whole network a boost I didn't understand because every other component was configured ipv6 off.
fyi: I've updated my first post to include OpenWrt 21.02.0-rc4 with @sammo 's "iw phy phy1 set txq memory_limit 8388608" fix to be tested.
thanks Catfriend1
Hi all,
I have an Archer C7 V5 running 21.02-rc4. I am seeing messages in the system log about "firmware crashed" followed by "device successfully recovered" every couple of days. Wifi seems fine and I haven't noticed any disconnects or drops in service.
Has anyone else noticed this?
Thanks
Sun Aug 8 14:04:14 2021 kern.err kernel: [69875.666428] ath10k_pci 0000:00:00.0: firmware crashed! (guid 61f8daa6-7918-4497-b34e-557e3678ef50)
Sun Aug 8 14:04:14 2021 kern.info kernel: [69875.675871] ath10k_pci 0000:00:00.0: qca988x hw2.0 target 0x4100016c chip_id 0x043202ff sub 0000:0000
Sun Aug 8 14:04:14 2021 kern.info kernel: [69875.685503] ath10k_pci 0000:00:00.0: kconfig debug 0 debugfs 1 tracing 0 dfs 1 testmode 0
Sun Aug 8 14:04:14 2021 kern.info kernel: [69875.697802] ath10k_pci 0000:00:00.0: firmware ver 10.1-ct-8x-__fH-022-ecad3248 api 2 features wmi-10.x,mfp,txstatus-noack,wmi-10.x-CT,ratemask-CT,regdump-CT,txrate-CT,flush-all-CT,pingpong-CT,ch-regs-CT,nop-CT,set-special-CT,get-temp-CT,tx-rc-CT,cust-stats-CT,retry-gt2-CT,txrate2-CT,beacon-cb-CT,wmi-block-ack-CT crc32 1b2a161c
Sun Aug 8 14:04:14 2021 kern.info kernel: [69875.727824] ath10k_pci 0000:00:00.0: board_file api 1 bmi_id N/A crc32 bebc7c08
Sun Aug 8 14:04:14 2021 kern.info kernel: [69875.735409] ath10k_pci 0000:00:00.0: htt-ver 2.2 wmi-op 2 htt-op 2 cal file max-sta 128 raw 0 hwcrypto 1
Sun Aug 8 14:04:14 2021 kern.err kernel: [69875.745324] ath10k_pci 0000:00:00.0: firmware register dump:
Sun Aug 8 14:04:14 2021 kern.err kernel: [69875.751193] ath10k_pci 0000:00:00.0: [00]: 0x4100016C 0x00000000 0x0099483D 0x930F9A72
Sun Aug 8 14:04:14 2021 kern.err kernel: [69875.759404] ath10k_pci 0000:00:00.0: [04]: 0x0099483D 0x00060130 0x00000000 0x00000001
Sun Aug 8 14:04:14 2021 kern.err kernel: [69875.767607] ath10k_pci 0000:00:00.0: [08]: 0x00000000 0x009BB400 0x00426CE0 0x0042C43C
Sun Aug 8 14:04:14 2021 kern.err kernel: [69875.775865] ath10k_pci 0000:00:00.0: [12]: 0x00000009 0x00000000 0x0095808C 0x009580A2
Sun Aug 8 14:04:14 2021 kern.err kernel: [69875.784132] ath10k_pci 0000:00:00.0: [16]: 0x00958080 0x0094085D 0x00000000 0x00000000
Sun Aug 8 14:04:14 2021 kern.err kernel: [69875.792381] ath10k_pci 0000:00:00.0: [20]: 0x4099483D 0x0040AC34 0x00000002 0x004F9A62
Sun Aug 8 14:04:14 2021 kern.err kernel: [69875.800608] ath10k_pci 0000:00:00.0: [24]: 0x80995012 0x0040AC94 0x00000000 0xC099483D
Sun Aug 8 14:04:14 2021 kern.err kernel: [69875.808867] ath10k_pci 0000:00:00.0: [28]: 0x809960A0 0x0040AD14 0x0041E524 0x00426CE0
Sun Aug 8 14:04:14 2021 kern.err kernel: [69875.817081] ath10k_pci 0000:00:00.0: [32]: 0x80997EC9 0x0040ADB4 0x0041E524 0x00426CE0
Sun Aug 8 14:04:14 2021 kern.err kernel: [69875.825326] ath10k_pci 0000:00:00.0: [36]: 0x809AF249 0x0040AEE4 0x004259F8 0x00000002
Sun Aug 8 14:04:14 2021 kern.err kernel: [69875.833605] ath10k_pci 0000:00:00.0: [40]: 0x80940F18 0x0040AF14 0x00000005 0x004039E4
Sun Aug 8 14:04:14 2021 kern.err kernel: [69875.841867] ath10k_pci 0000:00:00.0: [44]: 0x80940EEA 0x0040AF44 0x00400000 0x00000000
Sun Aug 8 14:04:14 2021 kern.err kernel: [69875.850097] ath10k_pci 0000:00:00.0: [48]: 0x80940F31 0x0040AF64 0x00401C10 0x00400600
Sun Aug 8 14:04:14 2021 kern.err kernel: [69875.858333] ath10k_pci 0000:00:00.0: [52]: 0x40940024 0x0040AF84 0x004068E8 0x004068E8
Sun Aug 8 14:04:14 2021 kern.err kernel: [69875.866532] ath10k_pci 0000:00:00.0: [56]: 0x00000000 0x0040AFA4 0x009BB001 0x00040020
Sun Aug 8 14:04:14 2021 kern.err kernel: [69875.874784] ath10k_pci 0000:00:00.0: Copy Engine register dump:
Sun Aug 8 14:04:14 2021 kern.err kernel: [69875.880946] ath10k_pci 0000:00:00.0: [00]: 0x00057400 7 7 3 3
Sun Aug 8 14:04:14 2021 kern.err kernel: [69875.887620] ath10k_pci 0000:00:00.0: [01]: 0x00057800 4 4 6 7
Sun Aug 8 14:04:14 2021 kern.err kernel: [69875.894288] ath10k_pci 0000:00:00.0: [02]: 0x00057c00 59 59 58 59
Sun Aug 8 14:04:14 2021 kern.err kernel: [69875.900953] ath10k_pci 0000:00:00.0: [03]: 0x00058000 8 8 10 8
Sun Aug 8 14:04:14 2021 kern.err kernel: [69875.907623] ath10k_pci 0000:00:00.0: [04]: 0x00058400 1155 1155 107 67
Sun Aug 8 14:04:14 2021 kern.err kernel: [69875.914465] ath10k_pci 0000:00:00.0: [05]: 0x00058800 26 26 25 26
Sun Aug 8 14:04:14 2021 kern.err kernel: [69875.921131] ath10k_pci 0000:00:00.0: [06]: 0x00058c00 26 26 26 26
Sun Aug 8 14:04:14 2021 kern.err kernel: [69875.927798] ath10k_pci 0000:00:00.0: [07]: 0x00059000 0 0 0 0
Sun Aug 8 14:04:14 2021 kern.warn kernel: [69875.934732] ath10k_pci 0000:00:00.0: debug log header, dbuf: 0x411a98 dropped: 0
Sun Aug 8 14:04:14 2021 kern.warn kernel: [69875.942576] ath10k_pci 0000:00:00.0: [0] next: 0x411ab0 buf: 0x40f8fc sz: 1500 len: 212 count: 8 free: 0
Sun Aug 8 14:04:14 2021 kern.err kernel: [69875.952463] ath10k_pci 0000:00:00.0: ath10k_pci ATH10K_DBG_BUFFER:
Sun Aug 8 14:04:14 2021 kern.err kernel: [69875.958874] ath10k: [0000]: 2AE34304 025C0014 4CF84300 488B9B00 6EB545B2 A9E10000 01000000 2AE34304
Sun Aug 8 14:04:14 2021 kern.err kernel: [69875.968228] ath10k: [0008]: 574C0010 88991071 908A4300 00B49B00 11000000 2AE34304 574C0014 908A4300
Sun Aug 8 14:04:14 2021 kern.err kernel: [69875.977580] ath10k: [0016]: 80CE4300 00000000 0C000000 8E1D0000 2AE34304 574C0014 908A4300 48B49B00
Sun Aug 8 14:04:14 2021 kern.err kernel: [69875.986937] ath10k: [0024]: 13000000 00000000 223D0000 2AE34304 574C0014 908A4300 90B49B00 06000000
Sun Aug 8 14:04:14 2021 kern.err kernel: [69875.996383] ath10k: [0032]: 0C000000 023D0000 2AE34304 574C0010 88991071 908A4300 D8B49B00 10000000
Sun Aug 8 14:04:14 2021 kern.err kernel: [69876.005766] ath10k: [0040]: 2AE34304 4B4C0010 6A492108 00003C84 21080000 3C846A49 2AE34304 0100FC17
Sun Aug 8 14:04:14 2021 kern.err kernel: [69876.015184] ath10k: [0048]: 00000000 A7190000 24AB4000 6C010041 FFFF0F00
Sun Aug 8 14:04:14 2021 kern.err kernel: [69876.022143] ath10k_pci 0000:00:00.0: ATH10K_END
Sun Aug 8 14:04:14 2021 kern.warn kernel: [69876.026914] ath10k_pci 0000:00:00.0: [1] next: 0x411a98 buf: 0x40feec sz: 1500 len: 0 count: 0 free: 0
Sun Aug 8 14:04:14 2021 kern.warn kernel: [69876.041728] ath10k_pci 0000:00:00.0: failed to set preamble for vdev 0: -143
Sun Aug 8 14:04:14 2021 kern.warn kernel: [69876.049181] ath10k_pci 0000:00:00.0: failed to set mgmt tx rate -143
Sun Aug 8 14:04:14 2021 kern.warn kernel: [69876.071457] ath10k_pci 0000:00:00.0: failed to send pdev bss chan info request: -143
Sun Aug 8 14:04:14 2021 kern.warn kernel: [69876.084617] ath10k_pci 0000:00:00.0: failed to send pdev bss chan info request: -143
Sun Aug 8 14:04:14 2021 kern.warn kernel: [69876.098520] ath10k_pci 0000:00:00.0: failed to send pdev bss chan info request: -143
Sun Aug 8 14:04:14 2021 kern.warn kernel: [69876.131746] ath10k_pci 0000:00:00.0: failed to send pdev bss chan info request: -143
Sun Aug 8 14:04:14 2021 kern.warn kernel: [69876.142864] ath10k_pci 0000:00:00.0: failed to send wmi nop: -143
Sun Aug 8 14:04:14 2021 kern.warn kernel: [69876.149318] ath10k_pci 0000:00:00.0: could not request stats (type -268435456 ret -143 specifier 1)
Sun Aug 8 14:04:14 2021 kern.warn kernel: [69876.159150] ath10k_pci 0000:00:00.0: removing peer, cleanup-all, deleting: peer c406c08a vdev: 0 addr: 3c:84:6a:49:21:08
Sun Aug 8 14:04:14 2021 kern.info kernel: [69876.271109] ieee80211 phy0: Hardware restart was requested
Sun Aug 8 14:04:15 2021 kern.warn kernel: [69877.215578] ath10k_pci 0000:00:00.0: 10.1 wmi init: vdevs: 4 peers: 128 tid: 256
Sun Aug 8 14:04:15 2021 kern.info kernel: [69877.232244] ath10k_pci 0000:00:00.0: wmi print 'P 129 V 8 T 411'
Sun Aug 8 14:04:15 2021 kern.info kernel: [69877.238551] ath10k_pci 0000:00:00.0: wmi print 'msdu-desc: 1424 sw-crypt: 0 ct-sta: 0'
Sun Aug 8 14:04:15 2021 kern.info kernel: [69877.246861] ath10k_pci 0000:00:00.0: wmi print 'alloc rem: 24512 iram: 41204'
Sun Aug 8 14:04:15 2021 kern.warn kernel: [69877.309836] ath10k_pci 0000:00:00.0: pdev param 0 not supported by firmware
Sun Aug 8 14:04:15 2021 kern.warn kernel: [69877.318655] ath10k_pci 0000:00:00.0: set-coverage-class, phyclk: 88 value: 0
Sun Aug 8 14:04:15 2021 kern.info kernel: [69877.327230] ath10k_pci 0000:00:00.0: rts threshold -1
Sun Aug 8 14:04:16 2021 kern.info kernel: [69878.334436] ath10k_pci 0000:00:00.0: device successfully recovered
@chadneufeld Sorry ,you did not use my build with the non-ct drivers.
. Your log says you've used some other image with ct drivers.
I'm using DAWN, 802.11r/k/v and the full-htt version of the Ath10k driver; ath10k-firmware-qca988x-ct-full-htt on 3 access points with roaming.
I thought the non-ct version didn't support r/k/v as well as the full-htt? Do you know if that's true?
I can try switching to the non-ct version.
I don't know. Had it on my list for long to take a look at dawn. Until now, I'm just doing dirty band forcing by blocking macs on my 2.4 ghz ssid and allowing them on the 5ghz one.
Thanks for the help.
I do know that -ct firmware doesn't support r/k/v operation as the wifi refuses to start. Both the non-ct and ct-full-htt seem to support r/k/v. Wifi starts up with both firmware versions.
I'm only running 5 GHz but with 3 access points. I'm not worried about band-steering from 2.4 to 5 GHz but I want to have seamless roaming and switching between the different access points. I did a bunch of testing today and my subjective opinion is that roaming between access points is better with the ...-ct-full-htt firmware. Roaming worked okay with the non-ct but the switch to a new access point took much longer.
The firmware never crashed with the non-ct drivers. The firmware crash might be an issue with the ct-full-ht firmware. The interesting thing is that even with firmware crashes, I never actually lose Wifi like a lot of people do with the Archer C7s.
Confirmed, I believe. After roughly 20 years of a WRAP board serving my humble needs I got me brand new v5, installed 19.07.8 and found the 5Ghz band stall on me consistently after half a day of service or so. Replaced the -ct packages as described above, and it's been "smooth sailing" for 2 days now.
Hi everyone,
After 10+ years with dd-wrt, I bit the bullet and moved my Archer C7 v2 to openwrt. First time with openwrt over here and very excited with getting 21.02-rc4 going. I got ipv6 and sqm up in no time along with my pihole setup (running in docker in a LAN NAS) and all was going perfectly: it was such a pleasure to see kernel 5.4 purring in this hardware.
While trying to figure out the performance boundaries, I first moved from ath10k-firmware-qca988x-ct/kmod-ath10k-ct firmware/driver to non-ct firmware/driver and saw some improvement on WLAN↔︎LAN iperf3 bandwidth to the NAS. On the WAN side, sqm got my connection in ship shape and pass the dslreports' bufferbloat testing with flying colors.
As things were going well, I went ahead and installed banip, vnstat, and statistics to see where it broke. And broke it did: overnight things went south with lots of oom-kill action, the last of which killed hostapd. That was probably responsible for a no-wifi wake-up call.
Since then, I uninstalled the three packages I was trying out and set vm.min_free_kbytes to 1024 as it was 16 MB.
Because of the memory situation, esp. since there is no swap, I was wondering why uhttpd (luci) is kept running all the time and is not launched on demand by the likes of inetd.
Any other hints/tips for using the Archer C7 v2 as a home router where the WAN is a measly 10/1 Mbit/s ADSL but LAN↔︎WLAN should be able to move 400 Mbit/s are more than welcome!
I love you
Sounds like you're doing pretty good on your own...
Possibly playing with the more advanced settings on Cake SQM, (read down the 3 layers of SQM docs on the main OpenWrt site) to squeeze out a bit more performance and fairness results. One thing you would probably benefit from would be the ack-filtering on egress, reducing some traffic load on that 1Mbit upload.
Thanks. After some sleuthing, I added option eqdisc_opts 'nat dual-srchost ack-filter' but I am not sure it made a big difference in dslreports.com. It was cool to learn why it is important on very asymmetric links.
One thing that I have been wondering is the link layer adaption per packet overhead, but that would require a good bout of measuring ping times so I'm leaving it at 44 for the time being.
Yep... I'd add nat dual-dsthost ingress on the ingress side, to have the same kind of flow fairness behavior in both directions. I don't know if the ingress keyword is going to help much or not, but it's suggested.
Tuning the shaping speeds, of course, to find the maximums before the bloat starts to rise is the main thing, seeing where your sweet spot is for the link adaptation less so, but still worth it at some point.
You could use tc -s qdisc on the command line, to see a reporting of how Cake is configured and what it's doing, (and that you didn't do a typo in the optional lines, causing it not to set up an interface at all!) including how many acks are filtered.
Yup, that went in along with the egress options I mentioned.
I did check that while setting things up and several hours later, I can see the effect of ack-filter:
Bulk Best Effort Voice
thresh 59368bit 950Kbit 237496bit
target 307ms 19.2ms 76.7ms
interval 614ms 114ms 172ms
pk_delay 0us 13.6ms 9.4ms
av_delay 0us 7.88ms 1.53ms
sp_delay 0us 1.24ms 95us
backlog 0b 1393b 0b
pkts 0 6259880 52208
bytes 0 677996170 7181345
[...]
ack_drop 0 1155234 0
[...]
It does not look bad to me (~18% of packets!), but it's still a little arcane.
Wow... much higher % rate than I've ever seen!! And, I guess you can say, the packets get more important (losing a packet when you have less total per second), the slower the rate. So, that would be a LOT of functional bandwidth you've gained back in your uplink!
fast.com and dslreports.com/speedtest do not notice a big increase in uplink bandwidth, but as you said, I may need to retune the threshold. I decided to try diffserv8 on both ingress and egress. Here are the egress stats:
Tin 0 Tin 1 Tin 2 Tin 3 Tin 4 Tin 5 Tin 6 Tin 7
thresh 950Kbit 831248bit 727336bit 636416bit 556864bit 487256bit 426344bit 373048bit
target 19.2ms 21.9ms 25ms 28.6ms 32.7ms 37.4ms 42.7ms 48.8ms
interval 114ms 117ms 120ms 124ms 128ms 132ms 138ms 144ms
pk_delay 0us 5.52s 30.9ms 0us 1.27ms 0us 82.7ms 7.33ms
av_delay 0us 550ms 3.12ms 0us 38us 0us 20ms 1.52ms
sp_delay 0us 46us 120us 0us 23us 0us 26us 18us
backlog 0b 0b 0b 0b 0b 0b 0b 0b
pkts 0 2020 4915228 0 56 0 22568 89207
bytes 0 652192 1201575283 0 5040 0 5392798 12372145
way_inds 0 0 150564 0 0 0 0 903
way_miss 0 6 259935 0 56 0 14 18295
way_cols 0 0 0 0 0 0 0 0
drops 0 242 169933 0 0 0 1396 0
marks 0 0 3605 0 0 0 0 0
ack_drop 0 961 1056227 0 0 0 10165 0
sp_flows 0 1 1 0 1 0 1 1
bk_flows 0 0 1 0 0 0 0 0
un_flows 0 0 0 0 0 0 0 0
max_len 0 25738 68970 0 90 0 36336 590
quantum 300 300 300 300 300 300 300 300
There is really a lot of ack_drops (~20% of pkts).
Up to now I'm not unhappy.
Hmm, never tried diffserv8. Seems that it dosen't have class names so it's hard to know what they are. I usually have it set for diffserv4 or the default 3, and they have names for the tins. Looks like what would be the "best effort" tin is empty?
Overall, I'd guess that perhaps even if you don't see a big speed difference with the ack filtering on, more of the available pipeline is composed of YOUR data rather than acks and the time they take, so the responsiveness and speed that files get there is probably improved.
Yes indeed.
It's interesting to see 5 tins being used and I am definitely not doing anything on the DSCP marking front. Also, tried some video, online conferencing, etc and couldn't quite see a direct correlation while looking at these numbers.
For the time being, I'll let good enough be good enough 