[18.06.4] speed fix for BT HomeHub 5a

I've just tested latest snapshot r12470 on a spare HH5A.

Using iperf3 multithreaded testing, the best WAN to LAN I can get is 80 Mbps. This is no better than 18.06 with 'broken' packet steering settings, and far worse than 17.01.

I re-read the description of the Commit and it states packet steering is now 'disabled by default' and

The previous netifd implementation (by default but could be configured) simply used all CPUs and this patch essentially reverts to this behaviour.

But the new commit clearly doesn't return 130+ Mbps throughput for the HH5a from my observations when compared to SMP snapshots from 2017 for the HH5a.

The new commit seems to have fixed one problem but created another ?

Update: Following tip from @mkresin

To enable packet steering, SSH into the HH5A and execute these two commands:

uci set network.globals.packet_steering=1
uci commit network

This will also add a line to the /etc/config/network file:

config globals 'globals'
	option packet_steering '1'

WAN to LAN throughput now seems to return 130 Mbps in both directions in brief testing.

2 Likes

Just installed r12629 and enabled packet_steering. However I don't see any changes, my WAN to LAN speeds are still the same ~50Mbps both directions. Any ideas to debug?

I just tried r12629. I get 100-130 Mbps WAN to LAN using iperf3 multi-threaded speeds with packet steering enabled in both directions. Only 70-80 Mbps with packet steering disabled.

Single threaded iperf3 speed tests return 90 Mbps in both directions between WAN and LAN with packet steering enabled.

50 Mbps seems awfully low. How are you measuring the speed, and is it without installing any extra packages (eg. SQM) other than LuCI ?

Stating the obvious, but did you reboot router after enabling packet steering?

Hi all,
I have a BT HomeHub 5a and I am on 19.07.2. If I understood correctly, to fix this I would need to upgrade to the current snapshot version and then enable packet steering? Thanks

Not necessarily. You may simply edit /etc/hotplug.d/net/20-smp-tune as explained in the Reiver's post above.

I am on master and I have this setting in LuCI. Does this option conflict with SQM?

Nope, SQM and packet steering are entirely separate.

There is now an option in LUCI master with commit to enable or disable packet steering under Network - Interfaces - Global Network Options. Text indicates that packet steering "May help or hinder network speed" as not one size fits all.

@bill888 Have you setup proper interrupt balancing? You need the patches from topic Xrx200 IRQ balancing between VPEs, two for kernel 4.19 or one for kernel 5.4 experimental.
EDIT: Oops misread the update that your testing returned to 130 Mbps.

1 Like

I've finally flashed OpenWrt v19.07.2 onto my BT HH5 router and everything works great except for the WAN to LAN speed which I did read up beforehand. The OpenWrt Wiki points to this forum for a fix. Skimming throught the comments I saw a mention of this being implemented into the OpenWrt 20.x.

I already compile my own firmware for the Linksys EA6350v3 and WRT1900ACS and I was wondering can I safely compile OpenWrt v19.07.2 with a patch that addresses this WAN to LAN throughput issue?

Does anybody know if there is a patch I can download and apply into my own compiled firmware please?

Many thanks in advance :blush:

I bought a used, pre-OpenWRT-ed BT HH5A (thread that helped me choose it). It's on its way. I will use it in pure modem (bridge) mode: pppoe sessions initiated from the router downstream, and possibly a VLAN on a different /24 network (on the same router WAN cable if doable) to get to the modem's management interface.

What is the minimum Lede/OpenWRT that's free from the packet steering problem and as efficient as possible in WAN<->LAN throughput? Or, better stated, how do I quickly check if any necessary patches have been applied?

I guess I'm better off making a new image when 20.x comes out. From what I read here, it seems reasonable defaults will be instated. Problem is, I don't know how old the release on my device is, and 20.x is not there yet.

I expect no packet steering issue with any openwrt version running in bridge mode.
So you can keep the one already flashed when you receive the device or update to latest 19.07.3

1 Like

So even with the performance fix for the upcoming openwrt 20.x builds, Would the WAN > LAN still be capped at 130Mbits max?

Okay I get is enough for most FTTC VDSL 2 connections as of the 80/20 profile by Openreach.

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.