[18.06.4] speed fix for BT HomeHub 5a

Community Builds, Projects & Packages
8

Thanks very much for these files but I'm getting errors with your 18.06.2 image :frowning:

Invalid sysupgrade file.
Image check 'platform_check_image' failed.

9

please go to https://openwrt.ebilan.co.uk/viewtopic.php?f=7&t=1105 and report this

10

added 18.06.4 build tested by bill
also mirrored the files on my dropbox

11

Your anonfile links are getting flagged btw for HTML/ScrInject.B trojan you might want to check.
However your mirror links are working fine, i take it is a simple sysupgrade run for these files?

1 Like
12

Thanks for the heads up. I'll reupload the flagged files when I'll have some spare time.
Yes the files are simple sysupgrades

UPDATE:
please see virustotal analysis below - NO VIRUS DETECTED !
18.06.1
18.06.2
18.06.4

13

fyi, bug report raised for this old issue following new findings.
https://bugs.openwrt.org/index.php?do=details&task_id=2573

Following a suggestion by mkresin to create a new script, I thought I'd add the following 2 lines to the BOTTOM of the existing /etc/hotplug.d/net/20-smp-tune script 'seems' to work and it survives hub restarts for unmodified 18.06.4 and 19.07.0-rc1 when briefly tested.

echo 3 > /sys/class/net/eth0/queues/rx-0/rps_cpus
echo 3 > /sys/class/net/eth0/queues/tx-0/xps_cpus

I haven't looked at the wireless settings and performance

# Untested fix to restore to pre Feb 2018 values.

#  Receive Packet Steering
echo 3 >   /sys/class/net/br-lan/queues/rx-0/rps_cpus
echo 3 >   /sys/class/net/eth0.1/queues/rx-0/rps_cpus
echo 3 >   /sys/class/net/eth0.2/queues/rx-0/rps_cpus
echo 3 >   /sys/class/net/eth0/queues/rx-0/rps_cpus
echo 3 >   /sys/class/net/lo/queues/rx-0/rps_cpus
echo 0 >   /sys/class/net/wlan0/queues/rx-0/rps_cpus
echo 0 >   /sys/class/net/wlan1/queues/rx-0/rps_cpus

#  Transmit Packet Steering
echo 3 >   /sys/class/net/br-lan/queues/tx-0/xps_cpus
echo 3 >   /sys/class/net/eth0.1/queues/tx-0/xps_cpus
echo 3 >   /sys/class/net/eth0.2/queues/tx-0/xps_cpus
echo 3 >   /sys/class/net/eth0/queues/tx-0/xps_cpus
echo 3 >   /sys/class/net/lo/queues/tx-0/xps_cpus
echo 0 >   /sys/class/net/wlan0/queues/tx-0/xps_cpus
echo 0 >   /sys/class/net/wlan0/queues/tx-1/xps_cpus
echo 0 >   /sys/class/net/wlan0/queues/tx-2/xps_cpus
echo 0 >   /sys/class/net/wlan0/queues/tx-3/xps_cpus
echo 0 >   /sys/class/net/wlan1/queues/tx-0/xps_cpus
echo 0 >   /sys/class/net/wlan1/queues/tx-1/xps_cpus
echo 0 >   /sys/class/net/wlan1/queues/tx-2/xps_cpus
echo 0 >   /sys/class/net/wlan1/queues/tx-3/xps_cpus
3 Likes
14

considering that anyone can apply the speed fix via:

echo 3 > /sys/class/net/eth0/queues/rx-0/rps_cpus
echo 3 > /sys/class/net/eth0/queues/tx-0/xps_cpus

do you think it's still relevant that I compile these versions ?
please like this post if you do.
thanks

4 Likes
15

To make these settings persistent on 18.06.X and 19.07 it might make sense to add

echo 3 > /sys/class/net/eth0/queues/rx-0/rps_cpus
echo 3 > /sys/class/net/eth0/queues/tx-0/xps_cpus

to the end of /etc/hotplug.d/net/20-smp-tune as otherwise a hotplug event on eth0 will reset the values away from 3.

1 Like
16

Rather than adding the echo at the end, edit /etc/hotplug.d/net/20-smp-tune and change the set_hex_val parameters so all (non-virtual) interfaces are changed on hotplug.

for q in ${dev}/queues/rx-*; do
                set_hex_val "$q/rps_cpus" "$PROC_MASK"
                #set_hex_val "$q/rps_cpus" "$(($PROC_MASK & ~$irq_cpu_mask))"
        done

        ntxq="$(ls -d ${dev}/queues/tx-* | wc -l)"

        idx=$(($irq_cpu + 1))
        for q in ${dev}/queues/tx-*; do
                set_hex_val "$q/xps_cpus" "$PROC_MASK"
                #set_hex_val "$q/xps_cpus" "$((1 << $idx))"
                let "idx = idx + 1"
                [ "$idx" -ge "$NPROCS" ] && idx=0
        done

Though a configuration option to choose between;

  • all cores [$PROC_MASK]
  • irq handling core [0] (kernel default which disables packet steering)
  • non-irq handling cores [$(($PROC_MASK & ~$irq_cpu_mask))]
  • alternating cpu cores for multiple tx queues

Would be nice.

2 Likes
17

have you tested this solution yourself?

18

Yes, tested and running (or ran since it's a hotplug script). It'd be hard to get this simple change wrong!

Although with git head, I'm getting an odd "No such file or directory" error when trying to read or write to xps_cpus files (that are present). Looks to be a kernel or selinux issue perhaps.

19

I guess the real question is, whw are the defaults in 20_smp_tune as they are, and why do some routers/socs have issues, like the BTHH5A or the turris omnia. I think there is a common property of the problematic socs that might be detectable and might allow 20_smp_tune to do the right thing....

20

Can't speak for the BTHH5A, but the patch below (which has been with mvebu devices since Kernel 4.4) could be one of the reasons why devices using mvneta + mvebu (as is the Turris Omnia) have quirky reactions to 20_smp_tune:

Which aims to fix this: https://bugs.openwrt.org/index.php?do=details&task_id=294

From Dave Täht 19.01.2017 22:57 in FS#294:

 Also, the current code is locked to the first core.

root@linksys-1200ac:/proc/irq# cd 37
root@linksys-1200ac:/proc/irq/37# echo 2 > smp_affinity
-ash: write error: I/O error
root@linksys-1200ac:/proc/irq/37# ls
affinity_hint node smp_affinity_list
mvneta smp_affinity spurious
1 Like
21

I've created a pull request PR2553 to change the packet steering to use all CPUs but to also disable it by default. Hopefully the reasoning provided in the pull will be enough to be accepted. Essentially;

  • The non-irq CPUs for RPS just seems to come from just one Red Hat document without any actual performance testing.
  • The original packet steering patches advise that optimal settings for the CPU mask depend on architectures and cache hierarchy so one size does not fit all.
  • The original packet steering patches also advise that the overhead in processing for a lightly loaded server can cause performance degradation.
  • Proper IRQ balancing is a better option.
5 Likes
22

I have tried running irqbalance and seen a 20% improvement in iperf3 results as well as greater consistency.

23

For anyone who is interested, I ran iperf3 against LEDE 17.01.6, 18.06.4 and 19.07.0-rc2, with and without software flow offloading and fixes for 20-smp-tune script (20 line untested fix). Using Windows 10 laptops. Server connected to red WAN port (static IP) or a LAN port. Client connected to LAN port or 5 GHz wifi.

0speed1
0speed1804×390 65 KB

0iperf3-2
0iperf3-2806×410 82.8 KB

0iperf3-3
0iperf3-3818×416 78.9 KB 

Example iperf3 commands:
Single thread: iperf3 -c 192.168.111.2 -t 10 -R
Single thread: iperf3 -c 192.168.111.2 -t 10 
Multi thread: iperf3 -c 192.168.111.2 -t 10 -P 5 -R
Multi thread: iperf3 -c 192.168.111.2 -t 10 -P 5
9 Likes
24

Thanks for the time for making the above results @bill888 with the 19.07.0-RC2 builds, Did you make any changes in the settings such as

  1. WMM Mode (Did you leave enable or disabled)
  2. Did you force 40MHz under the 2,4G band
  3. 802.11w Management Frame Protection
25

No extra packages installed. Using Ch.36 and WPA2-PSK with CCMP(AES) enabled were only wifi changes.
1 - default. WMM Mode enabled.
2 - only 5 GHz 80 MHz tested. 2.4 GHz radio disabled.
3 - tbh, no idea what and where this 802.11w Management Frame Protection setting is located.

2 Likes
26

Thanks a lot for the testing. I'm not sure I get what exactly you mean by "(echo) & flow"...
Flow offload enabled + echo script is the 2 lines script from your post above?

echo 3 > /sys/class/net/eth0/queues/rx-0/rps_cpus
echo 3 > /sys/class/net/eth0/queues/tx-0/xps_cpus

or the long script version below "# Untested fix to restore to pre Feb 2018 values." ?

27

I used the 'long' 20 line 'untested fix' echo command script.

Sorry for not being clear. '(echo) & flow' was my abbreviation for using both above script and enabling software flow offloading.

2 Likes