Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Wireless Ethernet Dispatch #8

Open
hpx502766238 opened this issue Mar 22, 2024 · 2 comments
Open

Wireless Ethernet Dispatch #8

hpx502766238 opened this issue Mar 22, 2024 · 2 comments

Comments

@hpx502766238
Copy link

When connected to a 5G wifi and conducting a test with a download speed of 800Mbps, the top command revealed a CPU utilization rate ranging from 1% to a high of 56%.
However, with the official miwifi firmware, the sirq usage was consistently below 5%, with the overall CPU usage never exceeding 10%.
I believe this is one of the reasons for the occasional instability in wireless throughput.
Mem: 143668K used, 89208K free, 1908K shrd, 56K buff, 38796K cached
CPU: 0% usr 11% sys 0% nic 44% idle 0% io 1% irq 42% sirq
Load average: 1.03 0.55 0.26 6/85 10344
PID PPID USER STAT VSZ %VSZ %CPU COMMAND
611 2 root RW 0 0% 7% [napi/mtk_eth-4]
10 2 root SW 0 0% 2% [ksoftirqd/0]
6940 2 root IW 0 0% 1% [kworker/u4:4-nf]
20 2 root IW 0 0% 1% [kworker/u4:1-nf]
6939 2 root IW 0 0% 1% [kworker/u4:3-nf]
610 2 root SW 0 0% 0% [napi/mtk_eth-3]
650 2 root IW 0 0% 0% [kworker/0:9-eve]
10344 10336 root R 1256 1% 0% top
7 2 root IW 0 0% 0% [kworker/u4:0-nf]

@hpx502766238
Copy link
Author

It seems lack of WED(Wireless Ethernet Dispatch).

@hpx502766238
Copy link
Author

hpx502766238 commented Mar 31, 2024

I conducted a comprehensive wireless performance test in WWAN networking mode. Below are the test conditions:

  1. I used a PC1 equipped with a Killer WiFi 6E AX1675i (211NGW) network card to create a hotspot, simulating public WiFi signals. The card provides an approximate throughput of 800M after excluding interference factors affecting card performance.
  2. Iperf3 -s was run on PC1 as the test server with the IP address 192.168.137.1.
  3. The router connected to the PC1 hotspot through its 5G apclii0 interface, negotiating a rate of 1.1G.
  4. The router's physical LAN port was connected to the test PC2, forming an internal network with the subnet 192.168.31.x/24.
    Below are the test results for wireless throughput and CPU utilization under different firmware:
    1. Regular firmware without Fast-NAT Support (using openwrt-mediatek-mt7622-xiaomi_redmi-router-ax6s-22.03.3-squashfs-sysupgrade.bin)
    1.1 Router as iperf client, testing throughput and CPU utilization.
direct up iperf direct up cpu

1.2 Router as iperf client, Reverse mode (server sending data), testing throughput and CPU utilization.
direct down iperf
direct down cpu

1.3 PC2 as iperf client, testing throughput and CPU utilization.
NAT up iperf
NAT up cpu

1.4 PC2 as iperf client, Reverse mode, testing throughput and CPU utilization.
NAT down iperf
NAT down cpu

2. Firmware with Fast-NAT Support (WHNAT) (using openwrt-mediatek-mt7622-xiaomi_redmi-router-ax6s-22.03.6-squashfs-sysupgrade.bin)
2.1 Router as iperf client, testing throughput and CPU utilization.
directup iperf
directup cpu

2.2 Router as iperf client, Reverse mode (server sending data), testing throughput and CPU utilization.
directdown iperf
directdown cpu

2.3 PC2 as iperf client, testing throughput and CPU utilization.
NAT up iperf
NAT up cpu

2.4 PC2 as iperf client, Reverse mode, testing throughput and CPU utilization.
NAT down iperf
NAT down cpu

Test conclusions:
a. Comparing 1.1 and 1.2, we can see that high throughput is achieved in both directions for wireless Layer 2 forwarding, but CPU utilization is high, especially for soft interrupts (sirq). This indicates that wed (wireless ethernet dispatch) is not enabled, and wireless and switch packets are forwarded through CPU software.
b. Comparing 1.2 and 1.4, we can see that there is approximately 100M loss in downstream throughput when using Openwrt's built-in Hardware NAT, while upstream throughput remains almost unchanged.
c. Comparing tests 1 and 2, we find that in the firmware with WHNAT enabled, CPU utilization is significantly reduced (to single digits) only when the router handles NAT upstream forwarding traffic. For other forwarding traffic, soft interrupt utilization remains high, suggesting WED may not cover all scenarios.
d. There is also a serious bug where downstream throughput seems to be locked below 200M according to tests 2.2 and 2.4, which needs to be fixed.
e. I have also been studying the hwnat code myself but have only concluded that WED is part of WHNAT in the driver code. I'm not very familiar with hardware and am just a network engineer who has played with 51 microcontrollers before. I hope these tests can help you and that you will maintain your passion for technology.

@hpx502766238 hpx502766238 changed the title Unstable wireless throughput:High CPU Usage,mostly sirq. Wireless Ethernet Dispatch Mar 31, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant