VR9 is vectoring capable and the 5.9.1.4.0.7 firmware supports vectoring, so if the line has vectoring enabled it should be used when the connection is established.
Maybe there is point there, I just have a hunch that the cpu is unable to support speed much over 100mbit anyway. Would probably require a more powerful router.
When I was still using my HH5a I initially tried to use it as all in one DSL router under OpenWrt but I clearly was already challenged to properly work for may then 50/10 Mbps access plan. I then configured the HH5a as bridged modem in front of my OpenWrt router and there is achieved close to 100 Mbps performance (for unidirectional traffic I achieved the expected throughput, only for bidirectionally saturating traffic I see less aggregate traffic than expected (and yes, I already did account for the expected throughput used by the reverse ACK traffic for both directions, still the HH5a was not delivering the full close For my needs this was A-OK as bidirectionally saturating loads are rare enough for me to ignore)). I later switched from a HH5a to an FB7520 (again acting as bridged modem under OpenWrt) which does not seem to have the same throughput limitation.
Just as a feedback. I still use the 21.07 with my FB3370. I get around 70 Mbit/s down with an iperf3 test on the device and 95 Mbit/s down on my E350 Desktop PC behind. Software Offloading and Hardware Offloading is active.
My line syncs with 102/35 .
Unfortunately the line still gets resync once or twice a day…
I was thinking if a 7412 which lays around could work more stable or my BB5HA…
You have been told the solution to that particular problem several times by several people. If, for whichever reasons, you still insist on running a version that does not contain relevant fixes, then that's on you I'm afraid.
What else can we (try to) help you with?
1 Like
First of all, I wanna say thank you to all of you for your efforts.
Unfortunately I have no physical touch to this my remote device.
So that’s the major problem to an upgrade to newer version.
My config is not made for the new DSA design and Gemini (Google AI) told me about serveral issue’s for this device's with newer versions, especially Offloading. So at the moment my device dives my Ubuntu-PC E350 still 93 Mbit/s down and 34 up.
So that’s not for sure with never versions ad I read.
And I'm still unsure if it really helps when vectorungs should already be enabled as discussed…
So what I expect or wanna try to find out if the sync problems get for sure solved with a newer OpenWrt Version.
That is what we are tying to tell you in so many words. Old versions of OpenWrt come with a DSL driver that is not working properly on lines using vectoring...
When vectoring is used, the DSLAM needs repeated measurements from the customer-side modems to make sure that the "pre-distortion" the DSLAM performs for all downstream signal waveforms is correct that after the physically unavoidable cross talk of all customer lines close to the DSLAM the signal is closer to the desired waveform (and that waveform is aiming for a no modems active/no cross-talk condition). Since the amount of cross talk that needs to be accounted for changes during the course of a day (temperature, different numbers of modems active/powered up) the DSLAM needs to adjust its pre-distortion over the course of a day and needs veridical information from all modems. But old modems running old OpenWrt do not sent this information back to the DSLAM at all, as a consequence Vectoring works fine after a resync, as modem and DSLAM found a working set, but slowly with changing conditions DSLAM and modem get out of alignment so to speak, resulting in an increased likelihood of loosing sync and hence more frequent resync events.
The solution is also well known, switch to a different driver for the modem e.g. the one in more recent OpenWrt versions.
That is unfortunate. I would consider getting another OpenWrt capable modem and configure that at home as replacement and test as much as you can, and then send to his to the remote location and ask your helping hands there to simply switch the modems, if this works you are set, if not the helping hands should be able to simply switch back to the old BTHH5a (occasional resyncs are still better than no sync at all).
Which might be correct or a wild invention, Gemini does not know this it just regurgitates stuff from its training set, so if you believe that random posts on the internet about that topic are on average correct Gemini might have a chance of catching that, but if the majority of posts are confused, why would an AI be anything but confused itself? When using AI always try to account for the model type use and allow for the respective problems, for LLMs one of these is, that they have no concept of correct or incorrect.
1 Like
Even if that isn't feasible (thinking shipping costs cross borders, customs fun, etc.), you can also configure this a/b replacement device remotely to some extent (from prepared uci-defaults previously tested on other hardware, etc). Obviously this is harder to accomplish, more complex and might need a few iterations, but at least the remote hands won't have to (be able to) do much more than switching two cables over. Been there, done that, it is frustrating for both ends (waiting for the other party to do things), but it requires very little expertise from the remote hands and always allows an easy way back to a working setup (at a flick of two cables), so it's fail-safe in that regard.
Just to be clear, unless there are major obstacles, going the physical/ postal route will always be easier - but there are alternatives with 'reasonable' interaction from remote hands (at least if they are family, have a sensible frustration tolerance and are not on the clock).
1 Like
As expected with a new owrt performance is much more decreased… no more than 80 Mbit/s even with SFO and packet steering….
BusyBox v1.36.1 (2025-12-17 21:08:22 UTC) built-in shell (ash)
_______ ________ __
| |.-----.-----.-----.| | | |.----.| |_
| - || _ | -__| || | | || _|| _|
|_______|| __|_____|__|__||________||__| |____|
|__| W I R E L E S S F R E E D O M
-----------------------------------------------------
OpenWrt 24.10.5, r29087-d9c5716d1d
-----------------------------------------------------
root@OpenWrt:~# iperf3 -sDp 5205
root@OpenWrt:~# iperf3 -c speedtest.wtnet.de -p 5202 -R -4
Connecting to host speedtest.wtnet.de, port 5202
Reverse mode, remote host speedtest.wtnet.de is sending
[ 5] local 2.204.63.26 port 32930 connected to 213.209.106.95 port 5202
[ ID] Interval Transfer Bitrate
[ 5] 0.00-1.00 sec 8.88 MBytes 74.3 Mbits/sec
[ 5] 1.00-2.00 sec 9.75 MBytes 81.8 Mbits/sec
[ 5] 2.00-3.00 sec 8.88 MBytes 74.5 Mbits/sec
[ 5] 3.00-4.00 sec 9.25 MBytes 77.6 Mbits/sec
[ 5] 4.00-5.00 sec 8.38 MBytes 70.2 Mbits/sec
[ 5] 5.00-6.00 sec 9.25 MBytes 77.6 Mbits/sec
[ 5] 6.00-7.00 sec 9.12 MBytes 76.5 Mbits/sec
[ 5] 7.00-8.00 sec 9.38 MBytes 78.7 Mbits/sec
[ 5] 8.00-9.00 sec 9.25 MBytes 77.6 Mbits/sec
[ 5] 9.00-10.00 sec 9.25 MBytes 77.6 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.02 sec 93.9 MBytes 78.6 Mbits/sec 51 sender
[ 5] 0.00-10.00 sec 91.4 MBytes 76.6 Mbits/sec receiver
iperf Done.
root@OpenWrt:~# /etc/init.d/dsl_control dslstat
{
"api_version": "4.17.18.6",
"firmware_version": "5.9.1.4.0.7",
"chipset": "Lantiq-VRX200",
"driver_version": "1.5.17.6",
"state": "Showtime with TC-Layer sync",
"state_num": 7,
"up": true,
"uptime": 4558,
"atu_c": {
"vendor_id": [
181,
0,
66,
68,
67,
77,
194,
120
],
"vendor": "Broadcom 194.120",
"system_vendor_id": [
181,
0,
66,
68,
67,
77,
0,
0
],
"system_vendor": "Broadcom",
"version": [
118,
49,
50,
46,
48,
52,
46,
49,
50,
48,
32,
32,
32,
32,
32,
0
],
"serial": [
101,
113,
32,
110,
114,
32,
112,
111,
114,
116,
58,
48,
52,
32,
32,
111,
101,
109,
105,
100,
32,
115,
111,
102,
116,
119,
97,
114,
101,
114,
101,
118
]
},
"power_state": "L0 - Synchronized",
"power_state_num": 0,
"xtse": [
0,
0,
0,
0,
0,
0,
0,
2
],
"annex": "B",
"standard": "G.993.2",
"profile": "17a",
"mode": "G.993.2 (VDSL2, Profile 17a, with down- and upstream vectoring)",
"upstream": {
"vector": true,
"trellis": true,
"bitswap": true,
"retx": true,
"virtual_noise": false,
"ra_mode": "At initialization",
"ra_mode_num": 1,
"interleave_delay": 0,
"inp": 29.000000,
"data_rate": 34697000,
"latn": 19.600000,
"satn": 19.500000,
"snr": 7.100000,
"actatp": 14.400000,
"attndr": 34697000,
"mineftr": 34630000
},
"downstream": {
"vector": true,
"trellis": true,
"bitswap": true,
"retx": true,
"virtual_noise": false,
"ra_mode": "At initialization",
"ra_mode_num": 1,
"interleave_delay": 140,
"inp": 27.000000,
"data_rate": 99327000,
"latn": 17.600000,
"satn": 17.600000,
"snr": 6.400000,
"actatp": 7.200000,
"attndr": 101138432,
"mineftr": 63314000
},
"olr": {
"downstream": {
"bitswap": {
"requested": 4438,
"executed": 2219,
"rejected": 0,
"timeout": 0
},
"sra": {
"requested": 0,
"executed": 0,
"rejected": 0,
"timeout": 0
},
"sos": {
"requested": 0,
"executed": 0,
"rejected": 0,
"timeout": 0
}
},
"upstream": {
"bitswap": {
"requested": 614,
"executed": 307,
"rejected": 0,
"timeout": 0
},
"sra": {
"requested": 0,
"executed": 0,
"rejected": 0,
"timeout": 0
},
"sos": {
"requested": 0,
"executed": 0,
"rejected": 0,
"timeout": 0
}
}
},
"errors": {
"near": {
"es": 2,
"ses": 2,
"loss": 0,
"uas": 103,
"lofs": 0,
"fecs": 0,
"leftrs": 1,
"cv_c": 0,
"fec_c": 0,
"hec": 0,
"ibe": 0,
"crc_p": 0,
"crcp_p": 0,
"cv_p": 0,
"cvp_p": 0,
"rx_corrupted": 8944,
"rx_uncorrected_protected": 387,
"rx_retransmitted": 0,
"rx_corrected": 8557,
"tx_retransmitted": 75
},
"far": {
"es": 190,
"ses": 58,
"loss": 0,
"uas": 103,
"lofs": 0,
"fecs": 96504,
"leftrs": 2605,
"cv_c": 1699,
"fec_c": 21748,
"hec": 0,
"ibe": 0,
"crc_p": 0,
"crcp_p": 0,
"cv_p": 0,
"cvp_p": 0,
"rx_corrupted": 12382647,
"rx_uncorrected_protected": 12025029,
"rx_retransmitted": 0,
"rx_corrected": 357618,
"tx_retransmitted": 371525985
}
},
"erb": {
"sent": 32638,
"discarded": 0
}
}
root@OpenWrt:~#
You did an iperf3 test on the modem and now you get roughly 80 Mbit/s down. Isn't that an improvement?
No. It was 95 and now it’s around 70-75. The gross rate is around 99. So I think there is some part of hw acceleration working in 19.07 and not anymore in 24.10.
I double checked that software-Offloading and packed-sterring and irqbalance is activated.
Update
Hey guys, I now get with software offloading 91Mbit/s down and without 58Mbit/s.
You need to optimize your rc.local and set chmod +x /etc/rc.local
#!/bin/sh
# --- HH5A PERFORMANCE TUNING 2026 ---
# 1. IRQ Affinity: Hardware-Last auf Kerne verteilen
# DSL-Modem (PTM) auf CPU1 (Kern 2)
echo 2 > /proc/irq/96/smp_affinity
# Ethernet/Switch auf CPU0 (Kern 1)
echo 1 > /proc/irq/72/smp_affinity
echo 1 > /proc/irq/73/smp_affinity
# WLAN (ath10k) auf CPU0 (Kern 1)
echo 1 > /proc/irq/144/smp_affinity
# 2. RPS/XPS: Software-Packet-Steering auf BEIDE Kerne (Maske 3)
echo "3" > /sys/class/net/eth0/queues/rx-0/rps_cpus
echo "3" > /sys/class/net/dsl0/queues/rx-0/rps_cpus
echo "3" > /sys/class/net/lan1/queues/rx-0/rps_cpus
echo "3" > /sys/class/net/eth0/queues/tx-0/xps_cpus
echo "3" > /sys/class/net/dsl0/queues/tx-0/xps_cpus
# 3. Optimierung der Bridge-Filterung (entlastet die CPU)
sysctl -w net.bridge.bridge-nf-call-arptables=0
sysctl -w net.bridge.bridge-nf-call-ip6tables=0
sysctl -w net.bridge.bridge-nf-call-iptables=0
# --- END TUNING ---
exit 0
Here is my dslstat after 10h of sync
root@OpenWrt:~#
root@OpenWrt:~# nft list ruleset | grep flowtable
flowtable ft {
root@OpenWrt:~#
root@OpenWrt:~#
root@OpenWrt:~#
root@OpenWrt:~#
root@OpenWrt:~# /etc/init.d/dsl_control dslstat
{
"api_version": "4.17.18.6",
"firmware_version": "5.9.1.4.0.7",
"chipset": "Lantiq-VRX200",
"driver_version": "1.5.17.6",
"state": "Showtime with TC-Layer sync",
"state_num": 7,
"up": true,
"uptime": 36067,
"atu_c": {
"vendor_id": [
181,
0,
66,
68,
67,
77,
194,
120
],
"vendor": "Broadcom 194.120",
"system_vendor_id": [
181,
0,
66,
68,
67,
77,
0,
0
],
"system_vendor": "Broadcom",
"version": [
118,
49,
50,
46,
48,
52,
46,
49,
50,
48,
32,
32,
32,
32,
32,
0
],
"serial": [
101,
113,
32,
110,
114,
32,
112,
111,
114,
116,
58,
48,
52,
32,
32,
111,
101,
109,
105,
100,
32,
115,
111,
102,
116,
119,
97,
114,
101,
114,
101,
118
]
},
"power_state": "L0 - Synchronized",
"power_state_num": 0,
"xtse": [
0,
0,
0,
0,
0,
0,
0,
2
],
"annex": "B",
"standard": "G.993.2",
"profile": "17a",
"mode": "G.993.2 (VDSL2, Profile 17a, with down- and upstream vectoring)",
"upstream": {
"vector": true,
"trellis": true,
"bitswap": true,
"retx": true,
"virtual_noise": false,
"ra_mode": "At initialization",
"ra_mode_num": 1,
"interleave_delay": 0,
"inp": 29.000000,
"data_rate": 34697000,
"latn": 19.600000,
"satn": 19.500000,
"snr": 7.100000,
"actatp": 14.400000,
"attndr": 34806000,
"mineftr": 34317000
},
"downstream": {
"vector": true,
"trellis": true,
"bitswap": true,
"retx": true,
"virtual_noise": false,
"ra_mode": "At initialization",
"ra_mode_num": 1,
"interleave_delay": 140,
"inp": 27.000000,
"data_rate": 99327000,
"latn": 17.600000,
"satn": 17.600000,
"snr": 6.900000,
"actatp": 7.200000,
"attndr": 102547456,
"mineftr": 63314000
},
"olr": {
"downstream": {
"bitswap": {
"requested": 11968,
"executed": 5983,
"rejected": 1,
"timeout": 0
},
"sra": {
"requested": 0,
"executed": 0,
"rejected": 0,
"timeout": 0
},
"sos": {
"requested": 0,
"executed": 0,
"rejected": 0,
"timeout": 0
}
},
"upstream": {
"bitswap": {
"requested": 1790,
"executed": 895,
"rejected": 0,
"timeout": 0
},
"sra": {
"requested": 0,
"executed": 0,
"rejected": 0,
"timeout": 0
},
"sos": {
"requested": 0,
"executed": 0,
"rejected": 0,
"timeout": 0
}
}
},
"errors": {
"near": {
"es": 4,
"ses": 3,
"loss": 0,
"uas": 103,
"lofs": 0,
"fecs": 0,
"leftrs": 2,
"cv_c": 11,
"fec_c": 0,
"hec": 0,
"ibe": 0,
"crc_p": 0,
"crcp_p": 0,
"cv_p": 0,
"cvp_p": 0,
"rx_corrupted": 17216,
"rx_uncorrected_protected": 782,
"rx_retransmitted": 0,
"rx_corrected": 16434,
"tx_retransmitted": 629
},
"far": {
"es": 190,
"ses": 58,
"loss": 0,
"uas": 103,
"lofs": 0,
"fecs": 96723,
"leftrs": 2605,
"cv_c": 1699,
"fec_c": 21788,
"hec": 0,
"ibe": 0,
"crc_p": 0,
"crcp_p": 0,
"cv_p": 0,
"cvp_p": 0,
"rx_corrupted": 12383187,
"rx_uncorrected_protected": 12025029,
"rx_retransmitted": 0,
"rx_corrected": 358158,
"tx_retransmitted": 371534352
}
},
"erb": {
"sent": 254988,
"discarded": 0
}
}
root@OpenWrt:~#
So looking back, my HH5A already did not robustly and reliably work as all in one DSL-router under OpenWrt at 50/10 Mbps*, so I am not at all surprised that you have issues reaching close to 100. I personally interpreted this as a hint that the router might be a bit under-powered and decided to forego the all-in-one approach and converted that BTHH5A into a pure bridged modem in front of another OpenWrt router, lo and behold that way I got close to DSL line rate even in bidirectional tests (well in bidirectional tests the aggregate rate up+down was a bit below expectations, but then the CPU was maxed out).
Now, your network, your rules applies obviously, yet maybe consider either accepting the throughput sacrifice or work around it by either relegating the HH5A to do pure bridged modem duty or replace it by the somewhat beefier vrx518 (fritzbox 7520/30)?
P.S.: If I recall correctly the xrx200's design preceded the nowadays usual bidirectional vectoring and G.INP (and especially bidirectional G.INP was really just an after thought) so it is not all that surprising that a SoC designed for dsl rates in the 50 maybe up to 80 Mbps range struggles a bit when pushed to do 116.7...
*) I admit though that my testing for robustness is harsh, running a bidirectional flent test over the DSL link while also stressing the WiFi and I was using sqm on the WAN side.
Quick estimate of what is actually achievable:
99.327 * 64/65 * ((1500-8-20-20) / (1500-8+34)) = 93.1 Mbps.
So maybe run htop on the router the next time you run an iperf3 test to see whether the CPU(s) are maxed out. Or better yet, simply do not run iperf3 on the router itself, but on a machine in your network... (as that better corresponds to normal usage, or do you run a file server on your router?).