How can we make the lantiq xrx200 devices faster

You have to use correct patches for v4 and v5.4 kernel. I would recommend to use v5.4 patches and so you need these ones.

You will need to create a new file for each patch using vim or vi or nano but do not use a simple notepad thingy and also put a new line at the end of the file.
If you have more patches that start with 09xx then you can move the numbering of the above patches further down the line as 0954 and 0956 etc. Keep in mind the file name should end up with .patch.

Also you will need to use OpenWrt source and create/copy the patches to openwrt-source/target/linux/lantiq/patches-5.4/ and then compile your firmware with necessary packages.

Thank you for explaining.

Applying /media/demo/DANE3/kompilacje/source-eb904-new-kernel-v9/openwrt/target/linux/lantiq/patches-5.4/5904-xrx200-net-smp-frags-support.patch using plaintext: 
patching file drivers/net/ethernet/lantiq_xrx200_legacy.c
Hunk #2 FAILED at 38.
Hunk #5 FAILED at 194.
Hunk #6 succeeded at 233 (offset 25 lines).
Hunk #7 succeeded at 536 (offset 25 lines).
Hunk #8 succeeded at 589 (offset 25 lines).
Hunk #9 succeeded at 604 (offset 25 lines).
Hunk #10 succeeded at 666 (offset 54 lines).
Hunk #11 succeeded at 717 (offset 54 lines).
Hunk #12 succeeded at 842 (offset 78 lines).
Hunk #13 succeeded at 855 (offset 78 lines).
Hunk #14 succeeded at 870 (offset 78 lines).
Hunk #15 FAILED at 953.
Hunk #16 succeeded at 1296 (offset 87 lines).
Hunk #17 succeeded at 1693 (offset 87 lines).
Hunk #18 succeeded at 1758 (offset 87 lines).
Hunk #19 FAILED at 1703.
Hunk #20 succeeded at 1840 (offset 98 lines).
Hunk #21 succeeded at 1928 (offset 106 lines).
Hunk #22 succeeded at 1953 (offset 106 lines).
Hunk #23 succeeded at 1994 (offset 106 lines).
Hunk #24 succeeded at 2023 (offset 106 lines).
Hunk #25 FAILED at 1967.
Hunk #26 succeeded at 2175 (offset 138 lines).
Hunk #27 succeeded at 2184 (offset 138 lines).
patch unexpectedly ends in middle of line
Hunk #28 succeeded at 2295 with fuzz 1 (offset 138 lines).
5 out of 28 hunks FAILED -- saving rejects to file drivers/net/ethernet/lantiq_xrx200_legacy.c.rej
Patch failed!  Please fix /media/demo/DANE3/kompilacje/source-eb904-new-kernel-v9/openwrt/target/linux/lantiq/patches-5.4/5904-xrx200-net-smp-frags-support.patch!
make[2]: *** [Makefile:32: /media/demo/DANE3/kompilacje/source-eb904-new-kernel-v9/openwrt/build_dir/target-mips_24kc_musl/linux-lantiq_xrx200/linux-5.4.61/.prepared_26f29cfe6b12f8531fcf8f6f2d4b2391] Error 1
make[2]: Leaving directory '/media/demo/DANE3/kompilacje/source-eb904-new-kernel-v9/openwrt/target/linux/lantiq'
make[1]: *** [Makefile:13: menuconfig] Error 2
make[1]: Leaving directory '/media/demo/DANE3/kompilacje/source-eb904-new-kernel-v9/openwrt/target/linux'
make: *** [/media/demo/DANE3/kompilacje/source-eb904-new-kernel-v9/openwrt/include/toplevel.mk:175: kernel_menuconfig] Błąd 2

The patches from @pc2005 conflict with the patches for Easybox 904 xDSL. Based on: Quallenauge's sources.

1 Like

Just a very late follow-up:

It is even doing ever so slightly better than that:
image
(assuming that dslreports is not skewing the results; measured via wifi)

1 Like

My suspicion is, that dslreports, like other speedtests, tries to remove the effect of the TCP start-up phase, so instead of returning simply the sum over all measurements flow's total transmitted volume divided by total time, they probably try to ignore the first X seconds per flow, and that leads to odd quantization effects...
I have seen this quite often, speedtest results slightly above the theoretical limit (librespeed and speedof.me typically are the worst offenders) and tend to believe this to be caused by some post-processing...
But, to be honest, that level of detail probably is not what casual speedtest users are after, so as far as I am concerned the speedtests are fine for their intended purpose...

Is it possible to implement PPE offloading support? Given the slow CPU, I don't see any other way to significantly speed up this device.

It seems the device can bridge or do IPv4 Routing on MII0, MII1, ATM and PTM. Given that this is the only VDSL device with OpenWRT, this is something important to do.

2 Likes

The first step is to switch to the mainline switch driver.

1 Like

Hi, I've just bought BTHub5A and my internet works. Installed the stable 19.07.7 on 4.14.221 kernel. Is there a built firmware on 5.4 or a commit which's proven working?
Another problem is that I'm getting only 20 out of the promised by Telekom 50Mbit/s. I suspect the vectoring driver, modem simply doesn't connect if I force G.993.5. What driver do you use on the newer firmwares?
Thanks!

Have a look at https://forum.openwrt.org/t/lantiq-vrx200-modem-firmware-with-vdsl2-vectoring-support/77613.

1 Like

Sidenote: while I liked the HH5A as a bridged modem with OpenWrt as its GUI; it never behaved sufficiently stable on my link (L3BSA O2/Telefonica, TAL operated by Deutsche Telekom) after the link was "upgrade" from plain VDSL2 to Vectoring-VDSL2 with bi-direction G.INP retransmissions; for testing I switched to a broadcom-based Zyxel modem (and so far never bothered to switch back, my OpenWrt primary router really does not care much about the brand an type of the modem at all, @takimata built a nice collectd script for monitoring, similar to what @st31ny did for the lantiq modem on the HH5A).
That said, a number of users seem to have reasonably stable vectoring links that work well with the HH5A...

1 Like

This thread is quite complicated, some stuff is outdated, some isn't. I am not really qualified to talk about this, I would like to ask, with the DSA mainline driver patch on latest master from git what works and what doesn't? The DSA driver brings full gigabit on lan and an iperf3 gives me a

[  5]   0.00-10.00  sec  58.5 MBytes  49.1 Mbits/sec  2749             sender
[  5]   0.00-10.00  sec  58.4 MBytes  49.0 Mbits/sec                  receiver

when bench marking the router. How do I improve this on the current master? What settings and what configuration changes do I need to use, do I need a specific kernel version, do I need to port patches?

Hi if you are using the actual master then you are using kernel 5.4. The patches for that kernel are here. Place it in your openwrt building folder at ~/openwrt/target/linux/lantiq/patches-5.4/. Use the names from the link 0904... and 0906....

Second speed up option is to use Software flow offloading. Go to luci --> Network --> firewall and enable it in the settings.

Some NAT benchmark (LAN<->WAN) on the BT HH5A (r16417-2b2fd8de7d) with enabled software offloading:

Test       OpenWRT driver        DSA driver         Increase
WAN->LAN   130 Mb/s              327 Mb/s           +151 %
LAN->WAN   132 Mb/s              315 Mb/s           +138 %

DSA driver PR.

3 Likes

The DSA migration is done and merged in OpenWrt master. The device should be quite a bit faster now?

Yes. They're much faster now. Currently, the results are as above. With 8W burst length I can reach almost 600 Mbps in the NAT benchmark. 8W burst length has been tested on xRX200 and newer SoCs. This week I will prepare PR for testing for older SoCs (Amazon, Danube, AR9).

1 Like

When testing the DSA driver on the BT HH5A did you see any CPU going as far as say 50%

Only the first core(VPE) deals with the processing of packets and interrupts from the network card. The load during testing is most often less than 50%.

You can also try Threaded NAPI, but it is slower. It seems that context switching between threads (VPE) costs a lot.

Will these changes be part of the 21.02 release?

No, it's way too late for that - there'll always be a next release.

http://lists.openwrt.org/pipermail/openwrt-devel/2021-June/035711.html

Fingers crossed

Some IPv6 Routing benchmark (LAN<->WAN) on the BT HH5A with enabled software offloading:

Test         1W                    8W             Increase
WAN->LAN   330 Mb/s              490 Mb/s           +48 %
LAN->WAN   338 Mb/s              590 Mb/s           +75 %

Burst length PR.

4 Likes