I am back from seaside vacation where I was pretty much unplugged and finally reverted the NSS-DP changes
13 Likes
As to my findings, you might want to revert to nss-dp: Support "phy-handle" properties for PHY connection
as even nss-dp: edma-v1: switch to napi_gro_receive decreased performance alone with about 80Mbits in a DL PPPoE scenario.
Well, I though about that as well, but there was plenty of users reporting increased performance with NAPI GRO, that is why that was not reverted.
Maybe we should retest it, but I don't have PPPoE that does additional load.
I made this script to show GRO status in all interfaces or turn it on/off.
I'm not proficient at this, so see if it's useful for testing or change anything you want.
My idea was also to test this last build against a build without GRO and also see if turning GRO off will have the same speed, so we could turn it off if needed.
root@X2:~# cat gro.sh
#!/bin/sh
if ! ( [ -z $1 ] || [ $1 = "on" ] || [ $1 = "off" ] ) ; then
echo "./gro.sh [on|off]"
exit 5
fi
for i in br-lan eth0 eth1 eth2 eth3 lo wlan0 wlan1 wlan2; do
printf "%+7s: " $i
if [ ! -z $1 ]; then
ethtool -K $i gro $1
fi
ethtool -k $i | grep generic-receive-offload | tail -c 4
done
No prob. I reverted to what I pointed out, and that was when my speed is recovered. I also tested with the GRO patch applied, and I was not able to reach more than 860-870Mbits.
The interesting thing is how can it be, that you cannot measure these issues in your home lab with a local PPPoE server?
Yeah, I intentionally used PPoE to account for it and perf improvements were really noticeable with GRO
Is maybe a server-setting issue? Is there any way to get the connection settings from the client? Once I'm back from my vacation I can get the settings from my ISP and compare too.
Well, I am just using the default MikroTik one with custom credentials as my ISP does not use PPoE at all.
Different test results, could be from different test conditions, IRQ affinity, SW flow offloading on/off, Packet Steering on/off or even MTU.
Do you remember the max. wan-lan speed you got with PPPoE GRO on?
That is why I tested with everything on default, so no IRQ tweaks, no SW offloading, packet steering etc.
You can probably find the tests in the thread somewhere, I dont know the number of top.
@Ansuel finally, a ath11k specific branch so that ath12k does not overwhelm me with number of commits:
Some of them could be interesting
2 Likes
Yes, that explains that both have validated and correct conclusions.
I'm currently on holiday... Need to find time to create a bugzilla
Hopefully on some beach
in sardinia 
Random week in Malta
Not bad, not as good as Croatia though 
I've been to Dugi-otok a few times off season. It was wonderful.
Good choice about off-season, July and August tend to get crazy busy.
At first I want say: Thank you robinmarko and Ansuel for your Great work !!!
Question: How can i use Channel 13 on 2.4 Ghz wifi ? Yes i can use it on IoT ath10k wifi, but the ath11k wifi it's doesn't allow it. Why ?
root@OpenWrt:~# iw phy0 info | grep 24 | grep MHz
* 2412 MHz [1] (20.0 dBm)
* 2417 MHz [2] (20.0 dBm)
* 2422 MHz [3] (20.0 dBm)
* 2427 MHz [4] (20.0 dBm)
* 2432 MHz [5] (20.0 dBm)
* 2437 MHz [6] (20.0 dBm)
* 2442 MHz [7] (20.0 dBm)
* 2447 MHz [8] (20.0 dBm)
* 2452 MHz [9] (20.0 dBm)
* 2457 MHz [10] (20.0 dBm)
* 2462 MHz [11] (20.0 dBm)
* 2467 MHz [12] (20.0 dBm)
* 2472 MHz [13] (20.0 dBm)
* 2484 MHz [14] (disabled)
root@OpenWrt:~# iw phy2 info | grep 24 | grep MHz
* 2412 MHz [1] (30.0 dBm)
* 2417 MHz [2] (30.0 dBm)
* 2422 MHz [3] (30.0 dBm)
* 2427 MHz [4] (30.0 dBm)
* 2432 MHz [5] (30.0 dBm)
* 2437 MHz [6] (30.0 dBm)
* 2442 MHz [7] (30.0 dBm)
* 2447 MHz [8] (30.0 dBm)
* 2452 MHz [9] (30.0 dBm)
* 2457 MHz [10] (30.0 dBm)
* 2462 MHz [11] (30.0 dBm)
* 2467 MHz [12] (disabled)
* 2472 MHz [13] (disabled)
* 2484 MHz [14] (disabled)
root@OpenWrt:~# cat /etc/openwrt_*
DISTRIB_ID='OpenWrt'
DISTRIB_RELEASE='SNAPSHOT'
DISTRIB_REVISION='r0-7298666'
DISTRIB_TARGET='ipq807x/generic'
DISTRIB_ARCH='aarch64_cortex-a53'
DISTRIB_DESCRIPTION='OpenWrt SNAPSHOT r0-7298666'
DISTRIB_TAINTS='no-all'
r0-7298666
Hier is wifi settings:
config wifi-device 'radio0'
option type 'mac80211'
option path 'soc/20000000.pci/pci0000:00/0000:00:00.0/0000:01:00.0'
option band '2g'
option txpower '13'
option htmode 'HT40'
option cell_density '2'
option channel '6'
option country 'DE'
config wifi-device 'radio2'
option type 'mac80211'
option path 'platform/soc/c000000.wifi+1'
option band '2g'
option htmode 'HE40'
option channel 'auto'
option cell_density '0'
option txpower '24'
option greenfield '1'
option he_bss_color '8'
option log_level '0'
option he_su_beamformee '1'
option country 'DE'
p.s. I use default buld from robinmarko github repo without modification
1 Like
We can't (for now), chans >11 are blocked by incorrect info in proprietary Board Data File, that the radio FW loads and needs to work.
The default IOT radio is configured for 5Ghz AC, I don't need it and have it off.
I didn't knew the AX3600 IOT radio is a dual band qca9889 and it can be switched to 2.4Ghz. I tried and it works at 2.4Ghz. Nice
@robimarko
This is only cosmetic, but if possible maybe it could be changed to QCA9889 in LUCI:
1 Like