[18.06.4] speed fix for BT HomeHub 5a

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

What does the error mean?

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.

1 Like

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

???

Thanks for helping us :slight_smile:

that's correct

@maurer thank you for your answer.
in the mean time i installed the latest snapshot, and it seems these lines are already present...

Thanks for letting me know about this :+1:have you done any speeds test on the new snapshot builds?

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.

See also: https://gist.github.com/Flashtekuk/2c264de3a1431bc6b9ef3413007c1d12

1 Like

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.