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.
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.
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!
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...
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
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.
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).
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.