I installed the r15373 snapshot a few days ago. I found that packet steering was already set to 1 in /etc/config/network.
I was curious about what the SMP hotplug script was doing so I set DEBUG=yes in the script hoping to see the debug output, but couldn't find any output anywhere (I have syslog sending to an external server and I see netifd messages in that stream, but none of the debug messages showed up). I modified the hotplug script to send output to /tmp/20-smp and then found this:
set_hex_val /sys/class/net/eth0/queues/tx-0/xps_cpus = 3
sh: write error: No such file or directory
set_hex_val /sys/class/net/eth0/queues/rx-0/rps_cpus = 3
set_hex_val /sys/class/net/wlan0/queues/tx-0/xps_cpus = 3
sh: write error: No such file or directory
set_hex_val /sys/class/net/wlan0/queues/rx-0/rps_cpus = 3
set_hex_val /sys/class/net/wlan1/queues/tx-0/xps_cpus = 3
sh: write error: No such file or directory
set_hex_val /sys/class/net/wlan1/queues/rx-0/rps_cpus = 3
The files do exist:
-rw-r--r-- 1 root root 4096 Jan 1 14:12 /sys/class/net/eth0/queues/tx-0/xps_cpus
-rw-r--r-- 1 root root 4096 Jan 1 14:12 /sys/class/net/wlan0/queues/tx-0/xps_cpus
-rw-r--r-- 1 root root 4096 Jan 1 14:12 /sys/class/net/wlan1/queues/tx-0/xps_cpus
I had also set "-l 5 -d 15" in /etc/init.d/network to try to get debug output from netifd but found nothing new in syslog.
Found that I needed to do: procd_set_param stderr 1
in /etc/init.d/network so I did that and also did: procd_set_param stdout 1
and I now see extra logging from netifd, but still see no messages from the SMP script.
Hello,
so at this day what is finally the patch to apply ?? this is very confusing, for people landing here from the openwrt wiki for the BTHH5A.
Do we just have to replace the content of /etc/hotplug.d/net/20-smp-tune
with :
for q in ${dev}/queues/rx-*; do
set_hex_val "$q/rps_cpus" "$PROC_MASK"
done
for q in ${dev}/queues/tx-*; do
set_hex_val "$q/xps_cpus" "$PROC_MASK"
done
I applied the tweak to the 20-smp-tune script prompted by @shdf . Did make around a 10-15% difference in throughput for me... I then enabled the software and hardware offloading... that made things MUCH better.
Has anybody else had issues with this fix on WLAN? I've found that turning on packet steering does indeed improve throughput to a machine connected via Ethernet cable, but not when connected wirelessly.
I'm on an 80/20 VDSL connection. When connected via Ethernet, I get 40 Mbps down with network.globals.packet_steering=0 and 80 Mbps with network.globals.packet steering=1. But on either 2.4G or 5G wireless I get 40 Mbps regardless of the packet_steering value.
Checking /proc/interrupts, I see that interrupts 72 vrx200_rx and 73 vrx200_tx both increment with network traffic over Ethernet, but not over WiFi.
On WiFi I can restore the full 80 Mbps throughput by enabling software flow offloading in the firewall settings. But I'd like to use SQM which is incompatible with this solution.
It looks like your CPU0 core is overloaded with interrupts coming from WLAN and Ethernet adapters simultaneously .
You can try to use SMP affinity to redistribute the load.
have you done any speeds test on the new snapshot builds?