HH5A slow VDSL2

Model BT Home Hub 5A
Architecture xRX200 rev 1.2
Target Platform lantiq/xrx200
Firmware Version OpenWrt 23.05.2 r23630-842932a63d / LuCI openwrt-23.05 branch git-23.306.39416-c86c256
Kernel Version 5.15.137

I have a copper pair connection to the fibre cabinet which is a mile away. As a result the speed available over DSL is never very fast but with the HH5A running openwrt it is even slower than it should be.

My point of comparison is with the DGA0122NLK router supplied by the ISP. Using this the speed is 19Mbs down / 1.1 Mbps up. Using the HH5A I only get 15 Mbps down / 1.0 Mbps up.

I am in the UK and have these settings in /etc/config/network:

config dsl 'dsl'
        option annex 'b'
        option tone 'a'
        option ds_snr_offset '0'
        option xfer_mode 'ptm'
        option line_mode 'vdsl'

config interface 'wan'
        option device 'dsl0.101'
        option proto 'pppoe'
        option username 'XXXXXXXXXXX@tml.net'
        option password 'XXXXXXXX'
        option ipv6 '0'

I tried updating the firmware to the latest version I could find, v5.9.1.4.0.7 (extracted from the image for a Fritzbox 7430) but that made it slower still, down to 11Mbps. So I reverted to the original v5.7.9.9.0.6. Following is extracted from ubus call dsl metrics:

        "api_version": "4.17.18.6",
        "firmware_version": "5.7.9.9.0.6",
        "chipset": "Lantiq-VRX200",
        "driver_version": "1.5.17.6",
        "state": "Showtime with TC-Layer sync",
        "state_num": 7,
        "annex": "B",
        "standard": "G.993.2",
        "profile": "17a",
        "mode": "G.993.2 (VDSL2, Profile 17a)",

Can anyone suggest how I can improve the speed?
Is it worth laboriously extracting the firmware from other images and trying to find a better one?
Is the question of vectoring relevant at the very low speeds I am working with, or is this only relevant at much higher speeds?

Thanks!

I dont see modem firmware being replaced in your config.
You need annex B vdsl2 with vectoring (based on you telling speed disappears with upgrade)

I think I have annex B vdsl2 using the stock firmware that came with these 2 packages:

dsl-vrx200-firmware-xdsl-a - 05.08.01.08.01.06_05.08.00.0B.01.01_osc-1
dsl-vrx200-firmware-xdsl-b-patch - 05.08.01.08.01.06_05.08.00.0B.01.01_osc-1

but I don't think that vectoring is working, judging by this:

# ubus call dsl metrics
{
	"api_version": "4.17.18.6",
	"firmware_version": "5.7.9.9.0.6",
	"chipset": "Lantiq-VRX200",
	"driver_version": "1.5.17.6",
	"state": "Showtime with TC-Layer sync",
	"state_num": 7,
	"up": true,
	"uptime": 2674,
	"atu_c": {
		"vendor_id": [
			181,
			0,
			66,
			68,
			67,
			77,
			164,
			161
		],
		"vendor": "Broadcom 164.161",
		"system_vendor_id": [
			181,
			0,
			66,
			68,
			67,
			77,
			0,
			0
		],
		"system_vendor": "Broadcom",
		"version": [
			118,
			49,
			49,
			46,
			48,
			48,
			46,
			48,
			57,
			0,
			0,
			0,
			0,
			0,
			0,
			0
		],
		"serial": [
			85,
			49,
			48,
			70,
			52,
			48,
			48,
			50,
			53,
			48,
			50,
			95,
			49,
			50,
			0,
			0,
			0,
			0,
			0,
			0,
			0,
			0,
			0,
			0,
			0,
			0,
			0,
			0,
			0,
			0,
			0,
			0
		]
	},
	"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)",
	"upstream": {
		"vector": false,
		"trellis": true,
		"bitswap": true,
		"retx": false,
		"virtual_noise": false,
		"ra_mode": "At initialization",
		"ra_mode_num": 1,
		"interleave_delay": 0,
		"inp": 0.000000,
		"data_rate": 1165000,
		"latn": 13.900000,
		"satn": 13.900000,
		"snr": 6.100000,
		"actatp": 10.300000,
		"attndr": 1165000
	},
	"downstream": {
		"vector": false,
		"trellis": true,
		"bitswap": true,
		"retx": true,
		"virtual_noise": false,
		"ra_mode": "At initialization",
		"ra_mode_num": 1,
		"interleave_delay": 820,
		"inp": 35.000000,
		"data_rate": 17155000,
		"latn": 34.500000,
		"satn": 28.700000,
		"snr": 5.800000,
		"actatp": 12.800000,
		"attndr": 16986096,
		"mineftr": 16986000
	},
	"olr": {
		"downstream": {
			"bitswap": {
				"requested": 10,
				"executed": 5,
				"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": 2,
				"executed": 1,
				"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": 0,
			"ses": 0,
			"loss": 0,
			"uas": 34,
			"lofs": 0,
			"fecs": 0,
			"leftrs": 78,
			"cv_c": 0,
			"fec_c": 0,
			"hec": 0,
			"ibe": 0,
			"crc_p": 0,
			"crcp_p": 0,
			"cv_p": 0,
			"cvp_p": 0,
			"rx_corrupted": 551,
			"rx_uncorrected_protected": 0,
			"rx_retransmitted": 0,
			"rx_corrected": 551,
			"tx_retransmitted": 0
		},
		"far": {
			"es": 27642,
			"ses": 16,
			"loss": 0,
			"uas": 34,
			"lofs": 0,
			"fecs": 2180,
			"cv_c": 31987,
			"fec_c": 2574,
			"hec": 0,
			"ibe": 0,
			"crc_p": 0,
			"crcp_p": 0,
			"cv_p": 0,
			"cvp_p": 0
		}"upstream": {
		"vector": false,
	}
}

Notice the occurence of:

"upstream": {
		"vector": false,
...
"downstream": {
		"vector": false,

Also, the website https://xdarklight.github.io/lantiq-xdsl-firmware-info/ describes this firmware version as "VDSL over ISDN/ADSL Annex B" whereas the other (later) version which I tried is described as " VDSL over ISDN incl. vectoring support/ADSL Annex B". But, as I said above, this later firmware version is even slower! And it still shows as "vector": false.

I tried an old Zyxel VMG8924-B10A and this works well (19/1.1) the same as the DGA0122NLK. It's just the HH5A which is running slowly...

I have a spare HH5A which I intend to try to see if it is perhaps a hardware issue. Both units are new (never unboxed until a few months ago) so this seems unlikely.

I tried setting the parameter:

	option ds_snr_offset '65'

because I noticed this in the dslstats for the Zyxel modem:

              SNR Margin:        Upstream 6.7 dB        Downstream 6.7 dB

but that made no difference.
Is the parameter "option tone a" worth having a play with?

No need to change option

your firmware number matches no-vector one.

Thanks Andrispe.
Do you think it likely that using firmware marked as "incl. vectoring support" might actually improve the speed? I ask because the one I tried already (v5.9.1.4.0.7) actually made it worse, which seems very strange. Do you have any idea which version in particular is known to work well in the HH5A?
Thanks

You need vectoring support to exceed 20Mbps (17mbps in your status info)
It is same xrx200, all firmwares should be valid and enable vectoring if that is provided by other line end.

If your modem(-firmware) does not support vectoring, your ISP puts you into a (slow-) fallback profile (at best), that's what you're seeing. Supply the correct vectoring enabled firmware and all should be fine.

2 Likes

1500m+ line length is a major reason for poor speeds and I suspect that vectoring is ineffective at such line lengths.

If the DGA0122NLK uses a Broadcom xDSL chipset, this difference would not be surprising as Broadcom xDSL chipsets usually get noticeably better speeds on long lines than Lantiq VRX200 chipsets.

If vectoring is ineffective as I suspect, I dont think there will be anything you can do to improve speed with the HH5A though it wouldn't hurt to try a couple of other vectoring enabled VRX200 xDSL firmware files such as 5.7.B.5.0.7 or 5.7.C.8.1.7 (the Annex A vs B choice is only significant for ADSL - for VDSL2 it selects tone sets but this can normally be left as "auto").

The only OpenWrt supported modems likely to improve speed over the HH5A are the FritzBox 7530/7520 (Lantiq VRX518 chipset) which in my experience usually get better speeds than the VRX200 chipset modems, but I suspect would still be a bit less than a Broadcom chipset modem on such a long line.

1 Like

These work well as VDSL2 modems under OpenWrt, but they do not really seem work for ADSL links, just as a general comment on the limits of the otherwise preferable vrx518 modems.

Please use go-dsl and take and post a screenshot showing the numeric information as well as the four spectra (please click the check boxes to show minimum and maximum as well as auto scale and let go-dsl run for say an hour before taking the screen shot so minimum and maximum can be expected to show some differences).

Many thanks to all who have responded.

I have now tried 10 different firmware versions including (5.7.B.5.0.7 and 5.7.C.8.1.7 as suggested by pythonic) and can report that none of them switch on vectoring. The best throughput is produced by 5.8.1.8.1.6 which is marginally better at 16.5d / 1.1u than any of the others but is still short of the 19d / 1.1u produced by the DGA0122NLK and VMG8924-B10A modems.

I am attaching the output of go-dsl as requested by moeller0. For this purpose I used 5.7.B.5.0.7 as this includes the vectoring.

I'm guessing this is probably the end of the road and I will have to make do with it (or get another openwrt compatible router) but any further ideas gratefully received!

Thanks

Talk to ypur ISP, it looks like the linecard put you in a fall back profile (caused likely by a non vectoring on the modem) the ISP should reset the port on the linecard.

1 Like

If I plug in the equipment which the ISP supplied me with, it works (i.e. 19Mbps) so they will (not unreasonably) tell me to do just that!

But you might well be correct.

When I use the DGA0122NLK or VMG8924-B10A, it takes a very long time to establish the connection. And the same is true for the HH5A BUT I can see in the log that pppd has 5 or 6 attempts which keep timing out. So, maybe if I could lengthen the timeout so that pppd was able to establish a connection on the first attempt, I might get a better connection because the linecard has not switched into the fallback profile.

Thu Jul  4 21:13:47 2024 kern.warn kernel: [22736.555612] enter showtime
Thu Jul  4 21:13:47 2024 daemon.info pppd[10156]: Plugin pppoe.so loaded.
Thu Jul  4 21:13:47 2024 daemon.info pppd[10156]: PPPoE plugin from pppd 2.4.9
Thu Jul  4 21:13:47 2024 daemon.notice pppd[10156]: pppd 2.4.9 started by root, uid 0
Thu Jul  4 21:14:02 2024 daemon.warn pppd[10156]: Timeout waiting for PADO packets
Thu Jul  4 21:14:02 2024 daemon.err pppd[10156]: Unable to complete PPPoE Discovery
Thu Jul  4 21:14:02 2024 daemon.info pppd[10156]: Exit.
Thu Jul  4 21:14:02 2024 daemon.notice netifd: Interface 'wan' is now down
Thu Jul  4 21:14:02 2024 daemon.notice netifd: Interface 'wan' is setting up now
Thu Jul  4 21:14:03 2024 daemon.info pppd[10212]: Plugin pppoe.so loaded.
Thu Jul  4 21:14:03 2024 daemon.info pppd[10212]: PPPoE plugin from pppd 2.4.9
Thu Jul  4 21:14:03 2024 daemon.notice pppd[10212]: pppd 2.4.9 started by root, uid 0
Thu Jul  4 21:14:18 2024 daemon.warn pppd[10212]: Timeout waiting for PADO packets
Thu Jul  4 21:14:18 2024 daemon.err pppd[10212]: Unable to complete PPPoE Discovery
Thu Jul  4 21:14:18 2024 daemon.info pppd[10212]: Exit.
Thu Jul  4 21:14:18 2024 daemon.notice netifd: Interface 'wan' is now down
Thu Jul  4 21:14:18 2024 daemon.notice netifd: Interface 'wan' is setting up now
Thu Jul  4 21:14:18 2024 daemon.info pppd[10325]: Plugin pppoe.so loaded.
Thu Jul  4 21:14:18 2024 daemon.info pppd[10325]: PPPoE plugin from pppd 2.4.9
Thu Jul  4 21:14:18 2024 daemon.notice pppd[10325]: pppd 2.4.9 started by root, uid 0
Thu Jul  4 21:14:33 2024 daemon.warn pppd[10325]: Timeout waiting for PADO packets
Thu Jul  4 21:14:33 2024 daemon.err pppd[10325]: Unable to complete PPPoE Discovery
Thu Jul  4 21:14:33 2024 daemon.info pppd[10325]: Exit.
Thu Jul  4 21:14:34 2024 daemon.notice netifd: Interface 'wan' is now down
Thu Jul  4 21:14:34 2024 daemon.notice netifd: Interface 'wan' is setting up now
Thu Jul  4 21:14:34 2024 daemon.info pppd[10438]: Plugin pppoe.so loaded.
Thu Jul  4 21:14:34 2024 daemon.info pppd[10438]: PPPoE plugin from pppd 2.4.9
Thu Jul  4 21:14:34 2024 daemon.notice pppd[10438]: pppd 2.4.9 started by root, uid 0
Thu Jul  4 21:14:49 2024 daemon.warn pppd[10438]: Timeout waiting for PADO packets
Thu Jul  4 21:14:49 2024 daemon.err pppd[10438]: Unable to complete PPPoE Discovery
Thu Jul  4 21:14:49 2024 daemon.info pppd[10438]: Exit.
Thu Jul  4 21:14:49 2024 daemon.notice netifd: Interface 'wan' is now down
Thu Jul  4 21:14:49 2024 daemon.notice netifd: Interface 'wan' is setting up now
Thu Jul  4 21:14:50 2024 daemon.info pppd[10551]: Plugin pppoe.so loaded.
Thu Jul  4 21:14:50 2024 daemon.info pppd[10551]: PPPoE plugin from pppd 2.4.9
Thu Jul  4 21:14:50 2024 daemon.notice pppd[10551]: pppd 2.4.9 started by root, uid 0
Thu Jul  4 21:15:05 2024 daemon.warn pppd[10551]: Timeout waiting for PADO packets
Thu Jul  4 21:15:05 2024 daemon.err pppd[10551]: Unable to complete PPPoE Discovery
Thu Jul  4 21:15:05 2024 daemon.info pppd[10551]: Exit.
Thu Jul  4 21:15:05 2024 daemon.notice netifd: Interface 'wan' is now down
Thu Jul  4 21:15:05 2024 daemon.notice netifd: Interface 'wan' is setting up now
Thu Jul  4 21:15:05 2024 daemon.info pppd[10665]: Plugin pppoe.so loaded.
Thu Jul  4 21:15:05 2024 daemon.info pppd[10665]: PPPoE plugin from pppd 2.4.9
Thu Jul  4 21:15:05 2024 daemon.notice pppd[10665]: pppd 2.4.9 started by root, uid 0
Thu Jul  4 21:15:06 2024 daemon.info pppd[10665]: PPP session is 213
Thu Jul  4 21:15:06 2024 daemon.warn pppd[10665]: Connected to 2a:8a:1c:ed:19:f6 via interface dsl0.101
Thu Jul  4 21:15:06 2024 kern.info kernel: [22815.679379] pppoe-wan: renamed from ppp0
Thu Jul  4 21:15:06 2024 daemon.info pppd[10665]: Renamed interface ppp0 to pppoe-wan
Thu Jul  4 21:15:06 2024 daemon.info pppd[10665]: Using interface pppoe-wan
Thu Jul  4 21:15:06 2024 daemon.notice pppd[10665]: Connect: pppoe-wan <--> dsl0.101
Thu Jul  4 21:15:09 2024 daemon.info pppd[10665]: CHAP authentication succeeded
Thu Jul  4 21:15:09 2024 daemon.notice pppd[10665]: CHAP authentication succeeded

Worth a try do you think? I'll research pppd and see if I can tweak the timeout.

I think these are two separate issues. Vectoring get enabled/disabled during the dsl connection establishment, while pppoe negotiations only happen after the link reached showtime state so can't really affect low level dsl properties.

Just for some giggles, I'd clone the ISP modem's WAN IP on the bthub5a's dsl interface for testing and see what happens (just make sure to have a vectoring enabled firmware active before).

Yes, I think you are right moeller0. Me clutching at straws...

I pointed dsl-gui at the Zyxel modem and compiled the attached stats. Apart from the additional ~3Mpbs in the data rate, the only other differences which strike me are in Seamless rate adaptation and Vectoring - the Zyxel just shows a hypen rather than off (or on)?

Perhaps you can spot something relevant?

Thanks for your help.

OK, that does look more like the HH5 simply has higher internal noise than the Zyxel... (the QLN quiet line noise plot supports this hypothesis)
And yes vectoring seems to be off in both cases....

There's a reason you're not getting vectoring - it's not supported by BT/Openreach in the UK but G.INP only instead. (Though a few cabinets apparently do still have vectoring enabled after their trial period last decade).

Maybe run the Zyxel or Technicolor in bridge mode to eke out the few extra Mbps while still using OpenWRT as the router.