Radxa Zero 3W - Bufferbloat with 5Ghz Wi-Fi

[carloalbertobono]

Creating a bug report/issue

• I have searched the existing open and closed issues

Required Information

• DietPi version | cat /boot/dietpi/.version

G_DIETPI_VERSION_CORE=9
G_DIETPI_VERSION_SUB=20
G_DIETPI_VERSION_RC=1
G_GITBRANCH='master'
G_GITOWNER='MichaIng'

• Distro version | echo $G_DISTRO_NAME $G_RASPBIAN

trixie

• Kernel version | uname -a

Linux cloneone 6.12.62-current-rockchip64 #1 SMP PREEMPT Fri Dec 12 17:37:22 UTC 2025 aarch64 GNU/Linux

• SBC model | echo $G_HW_MODEL_NAME or (EG: RPi3)

Radxa ZERO 3 (aarch64)
aic8800 WiFi

• Power supply used | (EG: 5V 1A RAVpower)
  Unknown

• SD card used | (EG: SanDisk ultra)

None (internal eMMC)

Steps to reproduce

1. Install DietPi on the Radxa Zero 3W by flashing the image on the eMMC
2. Configure WiFi (5Ghz)
3. Run a network-demanding job (e.g. speedtest-cli)

Expected behaviour

Local network on other machines remains usable

Actual behaviour

Local network on other machines becomes unusable

Extra details

I first noticed that the network became overall unusable after configuring Syncthing.
I then re-flashed a clean DietPi to do other systematic tests using speedtest-cli, after realizing it was not a Syncthing issue.
What I observe is possibly bufferbloat related to "network-heavy" traffic from the SBC:

1. from other machines, network becomes unusable within seconds
2. from other machines, ICMP latency explodes and packets start to get dropped
3. the SSH connection with the SBC itself becomes unusable / stops responding
   This behavior stops immediately as the network-heavy job stops. All traffic resumes normally (see example at the bottom of this message).
   This is also observed with lower-bandwidth jobs (e.g., the abovementioned Syncthing downloading data at ~500Kb/s).
   The available bandwidth measured is about 250Mbit/s both up and down.

This does seem to affect differently machines that are connected to 2.4ghz WiFi: I have some older RPi for which the ICMP traffic was unaffected.

This could be related to the router (Technicolor MediaAccess FGA2130FWB) provided by the ISP, so I would not have posted here at first.
However, I have a second, identical Radxa Zero 3W that:

1. shows the described behaviour with the same setup (clean DietPi install + speedtest-cli)
2. does not show this behaviour when using Armbian (v26.2 rolling for Radxa ZERO 3 running Armbian Linux 6.1.115-vendor-rk35xx) connected to the 5Ghz WiFi. For example, during the speedtest-cli ICMP latency rises a bit (from ~5ms to ~30ms) but the network remains usable from the other clients.

Apart loving DietPi (and not wanting to switch OS), I think that this could indicate a broader issue.
So I remain available for any testing that could help.
Ciao!

Example, ICMP from my laptop when speedtest-cli stops:

64 bytes from 8.8.8.8: icmp_seq=28410 ttl=116 time=1694.517 ms
64 bytes from 8.8.8.8: icmp_seq=28411 ttl=116 time=691.635 ms
64 bytes from 8.8.8.8: icmp_seq=28412 ttl=116 time=286.204 ms
Request timeout for icmp_seq 28414
Request timeout for icmp_seq 28415
Request timeout for icmp_seq 28416
Request timeout for icmp_seq 28417
Request timeout for icmp_seq 28418
64 bytes from 8.8.8.8: icmp_seq=28419 ttl=116 time=205.941 ms
64 bytes from 8.8.8.8: icmp_seq=28420 ttl=116 time=264.429 ms
64 bytes from 8.8.8.8: icmp_seq=28421 ttl=116 time=156.506 ms
Request timeout for icmp_seq 28422
64 bytes from 8.8.8.8: icmp_seq=28423 ttl=116 time=404.458 ms
64 bytes from 8.8.8.8: icmp_seq=28424 ttl=116 time=268.174 ms
64 bytes from 8.8.8.8: icmp_seq=28425 ttl=116 time=706.660 ms
64 bytes from 8.8.8.8: icmp_seq=28426 ttl=116 time=257.492 ms
64 bytes from 8.8.8.8: icmp_seq=28427 ttl=116 time=507.739 ms
Request timeout for icmp_seq 28428
64 bytes from 8.8.8.8: icmp_seq=28429 ttl=116 time=380.986 ms
Request timeout for icmp_seq 28430
Request timeout for icmp_seq 28431
Request timeout for icmp_seq 28432
Request timeout for icmp_seq 28433
Request timeout for icmp_seq 28434
64 bytes from 8.8.8.8: icmp_seq=28435 ttl=116 time=898.000 ms
64 bytes from 8.8.8.8: icmp_seq=28436 ttl=116 time=14.025 ms
64 bytes from 8.8.8.8: icmp_seq=28437 ttl=116 time=4.688 ms
64 bytes from 8.8.8.8: icmp_seq=28438 ttl=116 time=4.613 ms
64 bytes from 8.8.8.8: icmp_seq=28439 ttl=116 time=3.956 ms
64 bytes from 8.8.8.8: icmp_seq=28440 ttl=116 time=4.448 ms
64 bytes from 8.8.8.8: icmp_seq=28441 ttl=116 time=4.154 ms
64 bytes from 8.8.8.8: icmp_seq=28442 ttl=116 time=6.340 ms
64 bytes from 8.8.8.8: icmp_seq=28443 ttl=116 time=4.717 ms
64 bytes from 8.8.8.8: icmp_seq=28444 ttl=116 time=4.920 ms
64 bytes from 8.8.8.8: icmp_seq=28445 ttl=116 time=4.085 ms
64 bytes from 8.8.8.8: icmp_seq=28446 ttl=116 time=4.367 ms

Synchthing on:

64 bytes from 8.8.8.8: icmp_seq=27464 ttl=116 time=1559.472 ms
64 bytes from 8.8.8.8: icmp_seq=27465 ttl=116 time=704.888 ms
64 bytes from 8.8.8.8: icmp_seq=27466 ttl=116 time=1974.995 ms
Request timeout for icmp_seq 27468
Request timeout for icmp_seq 27469
64 bytes from 8.8.8.8: icmp_seq=27468 ttl=116 time=2146.434 ms
64 bytes from 8.8.8.8: icmp_seq=27469 ttl=116 time=1715.979 ms
64 bytes from 8.8.8.8: icmp_seq=27470 ttl=116 time=1835.443 ms
64 bytes from 8.8.8.8: icmp_seq=27471 ttl=116 time=1336.597 ms
64 bytes from 8.8.8.8: icmp_seq=27472 ttl=116 time=964.042 ms
Request timeout for icmp_seq 27475
Request timeout for icmp_seq 27476
Request timeout for icmp_seq 27477
Request timeout for icmp_seq 27478
Request timeout for icmp_seq 27479
64 bytes from 8.8.8.8: icmp_seq=27480 ttl=116 time=682.361 ms

Syncthing off:

64 bytes from 8.8.8.8: icmp_seq=27746 ttl=116 time=4.664 ms
64 bytes from 8.8.8.8: icmp_seq=27747 ttl=116 time=4.035 ms
64 bytes from 8.8.8.8: icmp_seq=27748 ttl=116 time=4.784 ms
64 bytes from 8.8.8.8: icmp_seq=27749 ttl=116 time=4.513 ms
64 bytes from 8.8.8.8: icmp_seq=27750 ttl=116 time=6.663 ms
64 bytes from 8.8.8.8: icmp_seq=27751 ttl=116 time=4.616 ms

[MichaIng]

Hmm, I wonder in how far WiFi traffic from one device can affect traffic from other devices on the same network/channel. I mean of course if the traffic reaches the maximum of what the router/AP or Internet connection can handle, and there is not some prioritization to keep some min bandwidth free for each connected device ...

What is the TX power?

iw dev wlan0 info | grep power

And is this different with vendor kernel (Armbian)?

Also, Armbian ships with vendor Linux which has this driver builtin, but additionally installs the driver via DKMS. The latter matches the sources we merged into mainline Linux, so to compare I wonder which of both is in use:

modinfo aic8800_fdrv

If the DKMS driver is in use, one difference is the firmware: The armbian-firmware package ships firmware blobs for this driver, but the packages installed along with the DKMS driver package provide a newer version of this firmware (though not sure whether there was any substantial change). So we could test whether replacing the firmware enhances the situation. If so, we could merge it into armbian-firmware.

[carloalbertobono]

Thank you for the response!

About the distance, since some of the machines were very close at first, I tested from some point on with 4-5 mt distance and the effect is analogous.

About the Tx power:
I can read it from DietPi:

root@cloneone:/mnt/sandisk32ch# iw dev wlan0 info
Interface wlan0
ifindex 2
wdev 0x1
addr 78:22:88:e9:a2:cb
ssid NONNO_LASER
type managed
wiphy 0
channel 100 (5500 MHz), width: 80 MHz, center1: 5530 MHz
txpower 18.00 dBm

But not from Armbian:

root@radxa-zero3:~# iw wlan0 info
Interface wlan0
ifindex 4
wdev 0x1
addr 78:22:88:e9:9c:3f
ssid NONNO_LASER
type managed
wiphy 0
channel 100 (5500 MHz), width: 80 MHz, center1: 5530 MHz

I am not sure the driver implements the method at all:

root@radxa-zero3:~# strings /lib/modules/6.1.115-vendor-rk35xx/kernel/drivers/net/wireless/aic8800_sdio/aic8800_fdrv/aic8800_fdrv.ko | grep get_tx_power
root@radxa-zero3:~#

About the driver, the version looks the same, I see differences in the srcversion and vermagic, I'm not sure they are meaningful.

DietPi output:

root@cloneone:/mnt/sandisk32ch# modinfo aic8800_fdrv
filename: /lib/modules/6.12.62-current-rockchip64/kernel/drivers/net/wireless/aic8800_sdio/aic8800_fdrv/aic8800_fdrv.ko
license: GPL
author: Copyright(c) 2015-2017 RivieraWaves RivieraWaves S.A.S
version: 6.4.3.0
description: RivieraWaves 11nac driver for Linux cfg80211
firmware: rwnx_settings.ini
import_ns: VFS_internal_I_am_really_a_filesystem_and_am_NOT_a_driver
firmware: fmacfw.bin
firmware: fmacfw.ihex
firmware: ldpcram.bin
firmware: fcuram.bin
firmware: agcram.bin
import_ns: VFS_internal_I_am_really_a_filesystem_and_am_NOT_a_driver
srcversion: AF12CE2F1543D1563ED7A73
alias: sdio:cvC8A1d2082
alias: sdio:cvC8A1d0082
alias: sdio:cvC8A1dC08D
alias: sdio:cv5449d0145
depends: cfg80211,aic8800_bsp
intree: Y
name: aic8800_fdrv
vermagic: 6.12.62-current-rockchip64 SMP preempt mod_unload aarch64
parm: tx_aggr_counter:int
parm: bustx_thread_prio:int
parm: busrx_thread_prio:int
parm: ant_div:Enable Antenna Diversity (Default: 1) (bool)
parm: ht_on:Enable HT (Default: 1) (bool)
parm: vht_on:Enable VHT (Default: 1) (bool)
parm: he_on:Enable HE (Default: 1) (bool)
parm: mcs_map:VHT MCS map value 0: MCS0_7, 1: MCS0_8, 2: MCS0_9 (Default: 2) (int)
parm: he_mcs_map:HE MCS map value 0: MCS0_7, 1: MCS0_9, 2: MCS0_11 (Default: 2) (int)
parm: he_ul_on:Enable HE OFDMA UL (Default: 0) (bool)
parm: amsdu_maxnb:Maximum number of MSDUs inside an A-MSDU in TX: (Default: NX_TX_PAYLOAD_MAX) (int)
parm: ps_on:Enable PowerSaving (Default: 1-Enabled) (bool)
parm: tx_lft:Tx lifetime (ms) - setting it to 0 disables retries (Default: 1000) (int)
parm: ldpc_on:Enable LDPC (Default: 1) (bool)
parm: stbc_on:Enable STBC in RX (Default: 1) (bool)
parm: gf_rx_on:Enable HT greenfield in reception (Default: 1) (bool)
parm: phycfg:0 <= phycfg <= 5 : RF Channel Conf (Default: 2(C0-A1-B2)) (int)
parm: uapsd_timeout:UAPSD Timer timeout, in ms (Default: 300). If 0, UAPSD is disabled (int)
parm: uapsd_queues:UAPSD Queues, integer value, must be seen as a bitfield
Bit 0 = VO
Bit 1 = VI
Bit 2 = BK
Bit 3 = BE
-> uapsd_queues=7 will enable uapsd for VO, VI and BK queues (int)
parm: ap_uapsd_on:Enable UAPSD in AP mode (Default: 1) (bool)
parm: sgi:Advertise Short Guard Interval support (Default: 1) (bool)
parm: sgi80:Advertise Short Guard Interval support for 80MHz (Default: 1) (bool)
parm: use_2040:Use tweaked 20-40MHz mode (Default: 1) (bool)
parm: use_80:Enable 80MHz (Default: 1) (bool)
parm: custregd:Use permissive custom regulatory rules (for testing ONLY) (Default: 0) (bool)
parm: custchan:Extend channel set to non-standard channels (for testing ONLY) (Default: 0) (bool)
parm: nss:1 <= nss <= 2 : Supported number of Spatial Streams (Default: 1) (int)
parm: amsdu_rx_max:0 <= amsdu_rx_max <= 2 : Maximum A-MSDU size supported in RX
0: 3895 bytes
1: 7991 bytes
2: 11454 bytes
This value might be reduced according to the FW capabilities.
Default: 2 (int)
parm: bfmee:Enable Beamformee Capability (Default: 1-Enabled) (bool)
parm: bfmer:Enable Beamformer Capability (Default: 0-Disabled) (bool)
parm: mesh:Enable Meshing Capability (Default: 1-Enabled) (bool)
parm: murx:Enable MU-MIMO RX Capability (Default: 1-Enabled) (bool)
parm: mutx:Enable MU-MIMO TX Capability (Default: 1-Enabled) (bool)
parm: mutx_on:Enable MU-MIMO transmissions (Default: 1-Enabled) (bool)
parm: roc_dur_max:Maximum Remain on Channel duration (int)
parm: listen_itv:Maximum listen interval (int)
parm: listen_bcmc:Wait for BC/MC traffic following DTIM beacon (bool)
parm: lp_clk_ppm:Low Power Clock accuracy of the local device (int)
parm: tdls:Enable TDLS (Default: 1-Enabled) (bool)
parm: uf:Enable Unsupported HT Frame Logging (Default: 0-Disabled) (bool)
parm: auto_reply:Enable Monitor MacAddr Auto-Reply (Default: 0-Disabled) (bool)
parm: ftl:Firmware trace level (Default: "") (charp)
parm: dpsm:Enable Dynamic PowerSaving (Default: 1-Enabled) (bool)
parm: country_code:string
parm: ccode_channels:string
parm: aicwf_dbg_level:int
parm: reorder_timeout:int

and Armbian:

root@radxa-zero3:~# modinfo aic8800_fdrv
filename: /lib/modules/6.1.115-vendor-rk35xx/kernel/drivers/net/wireless/aic8800_sdio/aic8800_fdrv/aic8800_fdrv.ko
license: GPL
author: Copyright(c) 2015-2017 RivieraWaves RivieraWaves S.A.S
version: 6.4.3.0
description: RivieraWaves 11nac driver for Linux cfg80211
firmware: rwnx_settings.ini
import_ns: VFS_internal_I_am_really_a_filesystem_and_am_NOT_a_driver
firmware: fmacfw.bin
firmware: fmacfw.ihex
firmware: ldpcram.bin
firmware: fcuram.bin
firmware: agcram.bin
import_ns: VFS_internal_I_am_really_a_filesystem_and_am_NOT_a_driver
srcversion: 40D91BC4A1ADCB8517F1BF5
alias: sdio:cvC8A1d0082
alias: sdio:cvC8A1dC08D
alias: sdio:cv5449d0145
depends: aic8800_bsp
intree: Y
name: aic8800_fdrv
vermagic: 6.1.115-vendor-rk35xx SMP mod_unload modversions aarch64
parm: tx_aggr_counter:int
parm: bustx_thread_prio:int
parm: busrx_thread_prio:int
parm: ant_div:Enable Antenna Diversity (Default: 1) (bool)
parm: ht_on:Enable HT (Default: 1) (bool)
parm: vht_on:Enable VHT (Default: 1) (bool)
parm: he_on:Enable HE (Default: 1) (bool)
parm: mcs_map:VHT MCS map value 0: MCS0_7, 1: MCS0_8, 2: MCS0_9 (Default: 2) (int)
parm: he_mcs_map:HE MCS map value 0: MCS0_7, 1: MCS0_9, 2: MCS0_11 (Default: 2) (int)
parm: he_ul_on:Enable HE OFDMA UL (Default: 0) (bool)
parm: amsdu_maxnb:Maximum number of MSDUs inside an A-MSDU in TX: (Default: NX_TX_PAYLOAD_MAX) (int)
parm: ps_on:Enable PowerSaving (Default: 1-Enabled) (bool)
parm: tx_lft:Tx lifetime (ms) - setting it to 0 disables retries (Default: 1000) (int)
parm: ldpc_on:Enable LDPC (Default: 1) (bool)
parm: stbc_on:Enable STBC in RX (Default: 1) (bool)
parm: gf_rx_on:Enable HT greenfield in reception (Default: 1) (bool)
parm: phycfg:0 <= phycfg <= 5 : RF Channel Conf (Default: 2(C0-A1-B2)) (int)
parm: uapsd_timeout:UAPSD Timer timeout, in ms (Default: 300). If 0, UAPSD is disabled (int)
parm: uapsd_queues:UAPSD Queues, integer value, must be seen as a bitfield
Bit 0 = VO
Bit 1 = VI
Bit 2 = BK
Bit 3 = BE
-> uapsd_queues=7 will enable uapsd for VO, VI and BK queues (int)
parm: ap_uapsd_on:Enable UAPSD in AP mode (Default: 1) (bool)
parm: sgi:Advertise Short Guard Interval support (Default: 1) (bool)
parm: sgi80:Advertise Short Guard Interval support for 80MHz (Default: 1) (bool)
parm: use_2040:Use tweaked 20-40MHz mode (Default: 1) (bool)
parm: use_80:Enable 80MHz (Default: 1) (bool)
parm: custregd:Use permissive custom regulatory rules (for testing ONLY) (Default: 0) (bool)
parm: custchan:Extend channel set to non-standard channels (for testing ONLY) (Default: 0) (bool)
parm: nss:1 <= nss <= 2 : Supported number of Spatial Streams (Default: 1) (int)
parm: amsdu_rx_max:0 <= amsdu_rx_max <= 2 : Maximum A-MSDU size supported in RX
0: 3895 bytes
1: 7991 bytes
2: 11454 bytes
This value might be reduced according to the FW capabilities.
Default: 2 (int)
parm: bfmee:Enable Beamformee Capability (Default: 1-Enabled) (bool)
parm: bfmer:Enable Beamformer Capability (Default: 0-Disabled) (bool)
parm: mesh:Enable Meshing Capability (Default: 1-Enabled) (bool)
parm: murx:Enable MU-MIMO RX Capability (Default: 1-Enabled) (bool)
parm: mutx:Enable MU-MIMO TX Capability (Default: 1-Enabled) (bool)
parm: mutx_on:Enable MU-MIMO transmissions (Default: 1-Enabled) (bool)
parm: roc_dur_max:Maximum Remain on Channel duration (int)
parm: listen_itv:Maximum listen interval (int)
parm: listen_bcmc:Wait for BC/MC traffic following DTIM beacon (bool)
parm: lp_clk_ppm:Low Power Clock accuracy of the local device (int)
parm: tdls:Enable TDLS (Default: 1-Enabled) (bool)
parm: uf:Enable Unsupported HT Frame Logging (Default: 0-Disabled) (bool)
parm: auto_reply:Enable Monitor MacAddr Auto-Reply (Default: 0-Disabled) (bool)
parm: ftl:Firmware trace level (Default: "") (charp)
parm: dpsm:Enable Dynamic PowerSaving (Default: 1-Enabled) (bool)
parm: country_code:string
parm: ccode_channels:string
parm: aicwf_dbg_level:int
parm: reorder_timeout:int

Anything I can test, I'll do!

[MichaIng]

Is the AIC8800 DKMS package and firmware installed?

dpkg -l | grep aic8800

It should be installed based on the Armbian board configs:

• https://github.com/armbian/build/blob/main/config/boards/radxa-zero3.csc#L19
• https://github.com/armbian/build/blob/main/extensions/radxa-aic8800.sh

But maybe it is skipped for the vendor kernel at some point outside of the board config and extension script.

Since the vendor kernel's driver seems to be used, good to see that the base driver version is the same. The sources for the DKMS package and which we used to implement into mainline Linux are patched to compile and work with more recent Linux versions, which should not be any functional changes, but maybe there are other differences, even that the vendor Linux sources are mostly based on Radxa as well. Would need to make some recursive diff:

• https://github.com/radxa-pkg/aic8800/tree/main/src/SDIO/driver_fw/driver/aic8800
• https://github.com/armbian/linux-rockchip/tree/rk-6.1-rkr5.1/drivers/net/wireless/aic8800_sdio

Ah is that one loaded as well?

lsmod | grep aic8800_bsp
modinfo aic8800_bsp

[carloalbertobono]

Hi again, here are the outputs for the DietPi installation:

> root@cloneone:~# dpkg -l | grep aic8800
> root@cloneone:~# lsmod | grep aic8800_bsp
> aic8800_bsp            81920  1 aic8800_fdrv
> root@cloneone:~# modinfo aic8800_bsp
> filename:       /lib/modules/6.12.62-current-rockchip64/kernel/drivers/net/wireless/aic8800_sdio/aic8800_bsp/aic8800_bsp.ko
> license:        GPL
> author:         Copyright(c) 2015-2020 AICSemi AICSemi
> version:        1.0
> description:    AIC BSP
> import_ns:      VFS_internal_I_am_really_a_filesystem_and_am_NOT_a_driver
> srcversion:     923B5947E6216C895825509
> alias:          sdio:c07v*d*
> depends:        
> intree:         Y
> name:           aic8800_bsp
> vermagic:       6.12.62-current-rockchip64 SMP preempt mod_unload aarch64
> parm:           aic_fw_path:string
> parm:           testmode:int
> parm:           adap_test:int

and Armbian installation:

> root@radxa-zero3:~# dpkg -l | grep aic8800
> ii  aic8800-firmware                   4.0+git20250410.b99ca8b6-4           all          Aicsemi aic8800 supplemental firmware
> ii  aic8800-sdio-dkms                  4.0+git20250410.b99ca8b6-4           all          dkms sources for Aicsemi aic8800 SDIO Wi-Fi driver
> root@radxa-zero3:~# lsmod | grep aic8800_bsp
> aic8800_bsp            77824  2 aic8800_btlpm,aic8800_fdrv
> root@radxa-zero3:~# modinfo aic8800_bsp
> filename:       /lib/modules/6.1.115-vendor-rk35xx/kernel/drivers/net/wireless/aic8800_sdio/aic8800_bsp/aic8800_bsp.ko
> license:        GPL
> author:         Copyright(c) 2015-2020 AICSemi AICSemi
> version:        1.0
> description:    AIC BSP
> import_ns:      VFS_internal_I_am_really_a_filesystem_and_am_NOT_a_driver
> srcversion:     7ECB260741E5BC9FC904B92
> alias:          sdio:c07v*d*
> depends:        
> intree:         Y
> name:           aic8800_bsp
> vermagic:       6.1.115-vendor-rk35xx SMP mod_unload modversions aarch64
> parm:           aic_fw_path:string
> parm:           testmode:int
> parm:           adap_test:int

[MichaIng]

Okay, so the DKMS driver is installed but unused. It would be the aic8800_fdrv_sdio (_sdio suffix) module, just checked, and that is not loaded (on Armbian), right?

lsmod | grep aic8800

The builtin driver should use the regular firmware, but maybe the more recent driver from the aic8800-firmware package works better:

cd /tmp
wget 'https://github.com/radxa-pkg/aic8800/releases/download/4.0%2Bgit20250410.b99ca8b6-5/aic8800-firmware_4.0+git20250410.b99ca8b6-5_all.deb' -O firmware.deb
dpkg-deb -x firmware.deb firmware
sudo mv /lib/firmware/aic8800/SDIO/aic8800D80 /lib/firmware/aic8800/SDIO/aic8800D80_bak
sudo mv firmware/lib/firmware/aic8800_fw/SDIO/aic8800D80 /lib/firmware/aic8800/SDIO/aic8800D80

The other way round, it would be interesting to test the DKMS driver on Armbian. E.g. stop/deconfigure the WiFi interface, then

modprobe -r aic8800_bsp aic8800_btlpm aic8800_fdrv
modprobe aic8800_bsp_sdio aic8800_btlpm_sdio aic8800_fdrv_sdio

Then re-enable WiFi. Or on reboot via configs:

echo -n | sudo tee /etc/modprobe.d/blacklist-builtin-aic8800.conf
echo -n | sudo tee /etc/modules-load.d/load-dkms-aic8800.conf
for i in aic8800_bsp aic8800_fdrv aic8800_btlpm 
do
echo "blacklist $i" | sudo tee -a /etc/modprobe.d/blacklist-builtin-aic8800.conf
echo "${i}_sdio" | sudo tee -a /etc/modules-load.d/load-dkms-aic8800.conf
done

[carloalbertobono]

On Armbian I get:

> root@radxa-zero3:~# lsmod | grep aic8800
> aic8800_fdrv          389120  0
> aic8800_btlpm          16384  0
> aic8800_bsp            77824  2 aic8800_btlpm,aic8800_fdrv

Ostensibly, yes! The firmware actually works better, in this sense:

1. the speedtest-cli resulting speeds are now comparable to the Armbian install, both around 50Mbit/s.

2. Devices connected to the 5Ghz network continue to work. The impact on ICMP traffic (again on a third, unrelated machine) is noticeable, but now manageable (see pings below).
   You can see above when the speedtest kicks in.

> 64 bytes from 8.8.8.8: icmp_seq=52532 ttl=116 time=4.588 ms
> 64 bytes from 8.8.8.8: icmp_seq=52533 ttl=116 time=4.813 ms
> 64 bytes from 8.8.8.8: icmp_seq=52534 ttl=116 time=9.383 ms
> 64 bytes from 8.8.8.8: icmp_seq=52535 ttl=116 time=4.569 ms
> 64 bytes from 8.8.8.8: icmp_seq=52536 ttl=116 time=5.031 ms
> 64 bytes from 8.8.8.8: icmp_seq=52537 ttl=116 time=4.657 ms
> 64 bytes from 8.8.8.8: icmp_seq=52538 ttl=116 time=7.525 ms
> 64 bytes from 8.8.8.8: icmp_seq=52539 ttl=116 time=3.551 ms
> 64 bytes from 8.8.8.8: icmp_seq=52540 ttl=116 time=3.909 ms
> 64 bytes from 8.8.8.8: icmp_seq=52541 ttl=116 time=4.701 ms
> 64 bytes from 8.8.8.8: icmp_seq=52542 ttl=116 time=4.272 ms
> 64 bytes from 8.8.8.8: icmp_seq=52543 ttl=116 time=43.957 ms
> 64 bytes from 8.8.8.8: icmp_seq=52544 ttl=116 time=72.313 ms
> 64 bytes from 8.8.8.8: icmp_seq=52545 ttl=116 time=43.626 ms
> 64 bytes from 8.8.8.8: icmp_seq=52546 ttl=116 time=26.745 ms
> 64 bytes from 8.8.8.8: icmp_seq=52547 ttl=116 time=10.832 ms
> 64 bytes from 8.8.8.8: icmp_seq=52548 ttl=116 time=14.720 ms
> 64 bytes from 8.8.8.8: icmp_seq=52549 ttl=116 time=9.045 ms
> 64 bytes from 8.8.8.8: icmp_seq=52550 ttl=116 time=123.466 ms
> 64 bytes from 8.8.8.8: icmp_seq=52551 ttl=116 time=16.310 ms
> 64 bytes from 8.8.8.8: icmp_seq=52552 ttl=116 time=12.056 ms
> 64 bytes from 8.8.8.8: icmp_seq=52553 ttl=116 time=41.695 ms
> 64 bytes from 8.8.8.8: icmp_seq=52554 ttl=116 time=10.589 ms
> 64 bytes from 8.8.8.8: icmp_seq=52555 ttl=116 time=4.185 ms
> 64 bytes from 8.8.8.8: icmp_seq=52556 ttl=116 time=170.708 ms
> 64 bytes from 8.8.8.8: icmp_seq=52557 ttl=116 time=30.220 ms
> 64 bytes from 8.8.8.8: icmp_seq=52558 ttl=116 time=8.798 ms
> 64 bytes from 8.8.8.8: icmp_seq=52559 ttl=116 time=90.828 ms
> 64 bytes from 8.8.8.8: icmp_seq=52560 ttl=116 time=137.156 ms
> 64 bytes from 8.8.8.8: icmp_seq=52561 ttl=116 time=303.953 ms
> 64 bytes from 8.8.8.8: icmp_seq=52562 ttl=116 time=33.608 ms

However, I cannot reproduce the same effect with the Armbian clean install (see pings below), with the two SBCs roughly in the same position.

> 64 bytes from 8.8.8.8: icmp_seq=75 ttl=116 time=4.476 ms
> 64 bytes from 8.8.8.8: icmp_seq=76 ttl=116 time=3.991 ms
> 64 bytes from 8.8.8.8: icmp_seq=77 ttl=116 time=4.788 ms
> 64 bytes from 8.8.8.8: icmp_seq=78 ttl=116 time=4.194 ms
> 64 bytes from 8.8.8.8: icmp_seq=79 ttl=116 time=4.637 ms
> 64 bytes from 8.8.8.8: icmp_seq=80 ttl=116 time=4.944 ms
> 64 bytes from 8.8.8.8: icmp_seq=81 ttl=116 time=5.354 ms
> 64 bytes from 8.8.8.8: icmp_seq=82 ttl=116 time=4.206 ms
> 64 bytes from 8.8.8.8: icmp_seq=83 ttl=116 time=4.015 ms
> 64 bytes from 8.8.8.8: icmp_seq=84 ttl=116 time=4.802 ms
> 64 bytes from 8.8.8.8: icmp_seq=85 ttl=116 time=5.325 ms
> 64 bytes from 8.8.8.8: icmp_seq=86 ttl=116 time=3.910 ms
> 64 bytes from 8.8.8.8: icmp_seq=87 ttl=116 time=4.417 ms
> 64 bytes from 8.8.8.8: icmp_seq=88 ttl=116 time=4.363 ms
> 64 bytes from 8.8.8.8: icmp_seq=89 ttl=116 time=5.354 ms
> 64 bytes from 8.8.8.8: icmp_seq=90 ttl=116 time=6.119 ms
> 64 bytes from 8.8.8.8: icmp_seq=91 ttl=116 time=7.554 ms
> 64 bytes from 8.8.8.8: icmp_seq=92 ttl=116 time=4.461 ms
> 64 bytes from 8.8.8.8: icmp_seq=93 ttl=116 time=5.090 ms
> 64 bytes from 8.8.8.8: icmp_seq=94 ttl=116 time=4.045 ms
> 64 bytes from 8.8.8.8: icmp_seq=95 ttl=116 time=4.290 ms
> 64 bytes from 8.8.8.8: icmp_seq=96 ttl=116 time=6.891 ms
> 64 bytes from 8.8.8.8: icmp_seq=97 ttl=116 time=4.485 ms
> 64 bytes from 8.8.8.8: icmp_seq=98 ttl=116 time=5.876 ms
> 64 bytes from 8.8.8.8: icmp_seq=99 ttl=116 time=6.537 ms
> 64 bytes from 8.8.8.8: icmp_seq=100 ttl=116 time=6.816 ms
> 64 bytes from 8.8.8.8: icmp_seq=101 ttl=116 time=5.184 ms
> 64 bytes from 8.8.8.8: icmp_seq=102 ttl=116 time=4.289 ms
> 64 bytes from 8.8.8.8: icmp_seq=103 ttl=116 time=4.302 ms
> 64 bytes from 8.8.8.8: icmp_seq=104 ttl=116 time=4.959 ms
> 64 bytes from 8.8.8.8: icmp_seq=105 ttl=116 time=4.526 ms
> 64 bytes from 8.8.8.8: icmp_seq=106 ttl=116 time=4.403 ms
> 64 bytes from 8.8.8.8: icmp_seq=107 ttl=116 time=4.298 ms
> 64 bytes from 8.8.8.8: icmp_seq=108 ttl=116 time=3.721 ms
> 64 bytes from 8.8.8.8: icmp_seq=109 ttl=116 time=3.491 ms
> 64 bytes from 8.8.8.8: icmp_seq=110 ttl=116 time=4.075 ms
> 64 bytes from 8.8.8.8: icmp_seq=111 ttl=116 time=4.677 ms
> 64 bytes from 8.8.8.8: icmp_seq=112 ttl=116 time=4.318 ms

About the DKMS driver:

I had no luck with the first method:

> 6: wlan0: <BROADCAST,MULTICAST> mtu 1500 qdisc mq state DOWN mode DORMANT group default qlen 1000
>     link/ether 78:22:88:e9:9c:3f brd ff:ff:ff:ff:ff:ff
>     altname wlx782288e99c3f
> root@radxa-zero3:~# modprobe -r aic8800_fdrv
> root@radxa-zero3:~# modprobe -r aic8800_btlpm
> root@radxa-zero3:~# modprobe -r aic8800_bsp
> root@radxa-zero3:~# modprobe aic8800_bsp_sdio
> root@radxa-zero3:~# modprobe aic8800_btlpm_sdio
> root@radxa-zero3:~# modprobe aic8800_fdrv_sdio
> modprobe: ERROR: could not insert 'aic8800_fdrv_sdio': No such device

I used the second method and I now get is sensibly higher speeds with Armbian (and Ethernet disconnected):

> root@radxa-zero3:~# speedtest-cli --server 50954
> Retrieving speedtest.net configuration...
> Testing from Fastweb (93.34.128.242)...
> Retrieving speedtest.net server list...
> Retrieving information for the selected server...
> Hosted by Sky Wifi (Milano) [0.90 km]: 15.981 ms
> Testing download speed................................................................................
> Download: 201.44 Mbit/s
> Testing upload speed......................................................................................................
> Upload: 236.35 Mbit/s

with marginal impact on ICMP latency:

> 64 bytes from 8.8.8.8: icmp_seq=169 ttl=116 time=3.949 ms
> 64 bytes from 8.8.8.8: icmp_seq=170 ttl=116 time=5.169 ms
> 64 bytes from 8.8.8.8: icmp_seq=171 ttl=116 time=3.513 ms
> 64 bytes from 8.8.8.8: icmp_seq=172 ttl=116 time=4.549 ms
> 64 bytes from 8.8.8.8: icmp_seq=173 ttl=116 time=4.682 ms
> 64 bytes from 8.8.8.8: icmp_seq=174 ttl=116 time=3.981 ms
> 64 bytes from 8.8.8.8: icmp_seq=175 ttl=116 time=3.982 ms
> 64 bytes from 8.8.8.8: icmp_seq=176 ttl=116 time=4.312 ms
> 64 bytes from 8.8.8.8: icmp_seq=177 ttl=116 time=8.067 ms
> 64 bytes from 8.8.8.8: icmp_seq=178 ttl=116 time=4.025 ms
> 64 bytes from 8.8.8.8: icmp_seq=179 ttl=116 time=4.784 ms
> 64 bytes from 8.8.8.8: icmp_seq=180 ttl=116 time=4.720 ms
> 64 bytes from 8.8.8.8: icmp_seq=181 ttl=116 time=4.193 ms
> 64 bytes from 8.8.8.8: icmp_seq=182 ttl=116 time=3.787 ms
> 64 bytes from 8.8.8.8: icmp_seq=183 ttl=116 time=5.517 ms
> 64 bytes from 8.8.8.8: icmp_seq=184 ttl=116 time=4.472 ms
> 64 bytes from 8.8.8.8: icmp_seq=185 ttl=116 time=17.145 ms
> 64 bytes from 8.8.8.8: icmp_seq=186 ttl=116 time=10.798 ms
> 64 bytes from 8.8.8.8: icmp_seq=187 ttl=116 time=6.013 ms
> 64 bytes from 8.8.8.8: icmp_seq=188 ttl=116 time=7.785 ms
> 64 bytes from 8.8.8.8: icmp_seq=189 ttl=116 time=10.781 ms
> 64 bytes from 8.8.8.8: icmp_seq=190 ttl=116 time=8.619 ms
> 64 bytes from 8.8.8.8: icmp_seq=191 ttl=116 time=7.967 ms
> 64 bytes from 8.8.8.8: icmp_seq=192 ttl=116 time=5.984 ms
> 64 bytes from 8.8.8.8: icmp_seq=193 ttl=116 time=13.089 ms
> 64 bytes from 8.8.8.8: icmp_seq=194 ttl=116 time=6.167 ms
> 64 bytes from 8.8.8.8: icmp_seq=195 ttl=116 time=9.676 ms
> 64 bytes from 8.8.8.8: icmp_seq=196 ttl=116 time=14.943 ms
> 64 bytes from 8.8.8.8: icmp_seq=197 ttl=116 time=30.510 ms
> 64 bytes from 8.8.8.8: icmp_seq=198 ttl=116 time=8.253 ms
> 64 bytes from 8.8.8.8: icmp_seq=199 ttl=116 time=17.654 ms
> 64 bytes from 8.8.8.8: icmp_seq=200 ttl=116 time=4.052 ms
> 64 bytes from 8.8.8.8: icmp_seq=201 ttl=116 time=5.313 ms
> 64 bytes from 8.8.8.8: icmp_seq=202 ttl=116 time=4.417 ms
> 64 bytes from 8.8.8.8: icmp_seq=203 ttl=116 time=4.678 ms
> 64 bytes from 8.8.8.8: icmp_seq=204 ttl=116 time=5.580 ms

For reference, the results that I currently observe with the DietPi install:

> root@cloneone:~# speedtest-cli --server 50954
> Retrieving speedtest.net configuration...
> Testing from Fastweb (93.34.128.242)...
> Retrieving speedtest.net server list...
> Retrieving information for the selected server...
> Hosted by Sky Wifi (Milano) [0.90 km]: 9.738 ms
> Testing download speed................................................................................
> Download: 57.44 Mbit/s
> Testing upload speed......................................................................................................
> Upload: 58.11 Mbit/s

Hope these observations could be useful, rather than confusing...

[carloalbertobono]

This probably does not add much information, but I measured the average ICMP latency on my laptop machine (ping -i 0.2 8.8.8.8) when doing "nothing", and when doing speetest-cli --server from the two SBCs:

> static1.log: Avg 5.00 ms
> static2.log: Avg 4.80 ms
> static3.log: Avg 5.04 ms
> armbian1.log: Avg 7.88 ms
> armbian2.log: Avg 7.42 ms
> armbian3.log: Avg 8.52 ms
> diet1.log: Avg 45.38 ms
> diet2.log: Avg 48.26 ms
> diet3.log: Avg 45.05 ms

Also, I am not sure that there could be an hardware issue (and both tests you suggested actually changed the behaviour on the respective SBCs!) but I see this:

DietPi setup:

> root@cloneone:~# iw wlan0 link
> Connected to 22:b0:01:ef:e0:c1 (on wlan0)
> 	SSID: NONNO_LASER
> 	freq: 5500.0
> 	RX: 296029 bytes (1332 packets)
> 	TX: 128789 bytes (1049 packets)
> 	signal: -76 dBm
> 	rx bitrate: 97.6 MBit/s VHT-MCS 2 80MHz short GI VHT-NSS 1
> 	tx bitrate: 87.8 MBit/s VHT-MCS 2 80MHz VHT-NSS 1

Armbian setup:

> root@radxa-zero3:~# iw wlan0 link
> Connected to 22:b0:01:ef:e0:c1 (on wlan0)
> 	SSID: NONNO_LASER
> 	freq: 5500.0
> 	RX: 27425 bytes (213 packets)
> 	TX: 16555 bytes (121 packets)
> 	signal: -53 dBm
> 	rx bitrate: 390.0 MBit/s VHT-MCS 8 80MHz short GI VHT-NSS 1
> 	tx bitrate: 263.3 MBit/s VHT-MCS 6 80MHz VHT-NSS 1

Which I guess could explain the impact on the overall traffic - lower signal, lower MCS, more airtime occupied?
I don't know what else could cause this difference. It seems to me they are in the very same operating conditions:

I could also flash DietPi and change the firmware on the other SBC too.
Or do anything else

[TorX-Chat]

For the record, I'm also noting a ~90% drop in WiFi speeds on the Radxa Zero 3W when upgrading from vendor kernel to 9.20.1. Not fun. So bad I wish I could downgrade to vendor.

edit:
Also, based on testing, it seems the new kernel is defaulting to the external antenna, whereas previously it defaulted to the internal antenna and relied upon overlays=external-antenna being appended to /boot/dietpiEnv.txt to utilize the external antenna.

Antenna choice however does not resolve the speed issue(I tested with antennas), but it does explain the differential in signal strength.

[MichaIng]

Okay, so Armbian ships with vendor kernel, and despite the DKMS driver and firmware being installed, the builtin driver from the vendor kernel and the old firmware from armbian-firmware is used.

Using the DKMS driver (patched into mainline Linux) with the old firmware from armbian-firmware seems to have some significant performance impact. Let's see whether the new firmware shipped along with the DKMS driver packages have an impact. To test, run this on a DietPi system:

cd /tmp
wget 'https://github.com/radxa-pkg/aic8800/releases/download/4.0%2Bgit20250410.b99ca8b6-5/aic8800-firmware_4.0+git20250410.b99ca8b6-5_all.deb' -O firmware.deb
dpkg-deb -x firmware.deb firmware
sudo mv /lib/firmware/aic8800/SDIO/aic8800D80 /lib/firmware/aic8800/SDIO/aic8800D80_bak
sudo mv firmware/lib/firmware/aic8800_fw/SDIO/aic8800D80 /lib/firmware/aic8800/SDIO/aic8800D80

Also, running the above on an Armbian system with vendor kernel would be interesting, i.e. whether this newer firmware works well with the vendor kernel driver. Since, if so, I'd just patch it into armbian-firmware our end.

[carloalbertobono]

Hi, isn't this the same firmware as above?

Things got better than before when applying to DietPi, but the behavior is different.

[MichaIng]

Ah right, so with the new firmware, for you speeds on DietPi become comparable to the one's on Armbian (with vendor kernel driver), but when using the DKMS driver on Armbian, speeds raise even more there from ~50 Mbps to ~200 Mbps, without disturbing the WiFi network (raising ICMP latency)?

When using the DKMS driver on Armbian, does iw dev wlan0 info show any txpower?

And does reducing the TX power on DietPi, does it have a positive impact on ICMP latency? E.g. to reduce it from 18 dBm to 12 dBm:

iw dev wlan0 set txpower limit 1200

And one test is still missing, AFAIK. If you find time, how does new firmware with vendor kernel driver on Armbian behave?

rm /etc/modprobe.d/blacklist-builtin-aic8800.conf
rm /etc/modules-load.d/load-dkms-aic8800.conf
cd /tmp
wget 'https://github.com/radxa-pkg/aic8800/releases/download/4.0%2Bgit20250410.b99ca8b6-5/aic8800-firmware_4.0+git20250410.b99ca8b6-5_all.deb' -O firmware.deb
dpkg-deb -x firmware.deb firmware
sudo mv /lib/firmware/aic8800/SDIO/aic8800D80 /lib/firmware/aic8800/SDIO/aic8800D80_bak
sudo mv firmware/lib/firmware/aic8800_fw/SDIO/aic8800D80 /lib/firmware/aic8800/SDIO/aic8800D80

So the situation seems to be more complex than just the driver sources. Probably the vendor kernel contains some adjustments elsewhere which have an effect on how this driver behaves.

@TorX-Chat would be great if you find time to test the new firmware as well, whether it raises speed to an acceptable level for you.

And great hint about the internal vs external antenna, this could be the missing piece of the puzzle! Here is the overlay: https://github.com/armbian/linux-rockchip/blob/rk-6.1-rkr5.1/arch/arm64/boot/dts/rockchip/overlay/radxa-zero3-external-antenna.dts

It looks like it is enabled OOTB, but the overlay changes the ping from PD3 to PD2: https://github.com/armbian/linux-rockchip/blob/rk-6.1-rkr5.1/arch/arm64/boot/dts/rockchip/rk3566-radxa-zero3.dts#L42-L53

Mainline Linux does not define this node at all:

• https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/arch/arm64/boot/dts/rockchip/rk3566-radxa-zero-3w.dts
• https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/arch/arm64/boot/dts/rockchip/rk3566-radxa-zero-3.dtsi

How did you find out that the external antenna port is utilized? Probably this also causes the disturbance if no actual antenna is attached. I'll write an overlay to add the node and set it so that it uses the internal antenna (RK_PD2). Probably this helps.

[TorX-Chat]

I had no speed improvement, or slightly less speed, with aic8800-firmware_4.0+git20250410.b99ca8b6-5_all.deb.

I deduced that external antenna is being used because I noted similar results to carloalbertobono, which is a significantly lower signal dBm when utilizing dietpi 9.20+ vs vendor kernel. This was rectified by attaching an antenna.