Low DSL DL and UL speed(BT homehub 5A)-Deutsch telekom

[dylan]

I am using deutsch telekom tariff 100Mbps, i could only get 60mbps DL, however the maximum speed is 93mbps. there is 23Mbps gap. what could be the problem?
OpenWrt 22.03.5

ubus call dsl metrics result

"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": 267,
        "atu_c": {
                "vendor_id": [
                        181,
                        0,
                        66,
                        68,
                        67,
                        77,
                        193,
                        214
                ],
                "vendor": "Broadcom 193.214",
                "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": [
                        80,
                        49,
                        48,
                        71,
                        65,
                        48,
                        48,
                        48,
                        52,
                        55,
                        52,
                        95,
                        53,
                        54,
                        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, with down- and upstream vectoring)                                                                                                                                                                                                            ",
        "upstream": {
                "vector": true,
                "trellis": true,
                "bitswap": false,
                "retx": true,
                "virtual_noise": false,
                "interleave_delay": 0,
                "data_rate": 31999000,
                "latn": 20.100000,
                "satn": 19.900000,
                "snr": 10.900000,
                "actps": -90.100000,
                "actatp": 14.500000,
                "attndr": 39249000
        },
        "downstream": {
                "vector": true,
                "trellis": true,
                "bitswap": true,
                "retx": true,
                "virtual_noise": true,
                "interleave_delay": 180,
                "data_rate": 69997000,
                "latn": 17.800000,
                "satn": 17.800000,
                "snr": 12.600000,
                "actps": -90.100000,
                "actatp": 9.600000,
                "attndr": 93798400
        },
        "errors": {
                "near": {
                        "es": 0,
                        "ses": 0,
                        "loss": 0,
                        "uas": 271,
                        "lofs": 0,
                        "fecs": 0,
                        "hec": 0,
                        "ibe": 0,
                        "crc_p": 0,
                        "crcp_p": 0,
                        "cv_p": 0,
                        "cvp_p": 0,
                        "rx_corrupted": 0,
                        "rx_uncorrected_protected": 0,
                        "rx_retransmitted": 0,
                        "rx_corrected": 0,
                        "tx_retransmitted": 0
                },
                "far": {
                        "es": 10,
                        "ses": 3,
                        "loss": 1,
                        "uas": 271,
                        "lofs": 0,
                        "fecs": 61533,
                        "hec": 0,
                        "ibe": 0,
                        "crc_p": 0,
                        "crcp_p": 0,
                        "cv_p": 0,
                        "cvp_p": 0,
                        "rx_corrupted": 1082210,
                        "rx_uncorrected_protected": 974491,
                        "rx_retransmitted": 0,
                        "rx_corrected": 107719,
                        "tx_retransmitted": 813265
                }
        },
        "erb": {
                "sent": 715,
                "discarded": 0
        }
}</>

[slh]

Did you enable software flow-offloading (lantiq is rather slow as a SOC, this is necessary to get beyond ~80 MBit/s)?

Beyond that, DTAG is very sensitive to line-/ modem restarts, it may take up to 10-12 days after a modem reboot (or hardware change), before you get back to full speed.

[moeller0]

You are likely limited by Deutsche Telekom's DLM system (Ex Assia DSLExpresse*), this system tries to stabilize links with 'too many' errors or proto-errors, mostly by setting the DSLAM's synchronization limits independently for every line... These limits tend to be nice round numbers, like 70.0 Mbps and 32.0 Mbps, a modem syoncing will get something <= to that hard limit, in your case the Data Rate values of 69.997/31.999 is a strong hint that this DLM system intervened and limitsyour sync. To improve your rates you need to figure out why the DLM down-gradsed your sync rates and try to change those factors, if the numbers the DLM decides on improve, so will your sync and data rates (up to the hard maximal profiles which would be around 116.8/46.0 IIRC).
I wold recommend to use the go-dsl GUI application and collect some data (enable the min max dislay and the automatic scaling checkboxes) over some time (if possible for a full day) and then save and post a screenshot here. If you are lucky we might be come up with some ideas what to try...

*) 'Ex' because Assia sold the DSLExpresse product recently to DZS which now markets it as DZS Expresse...

[slh]

Btw., for these reasons (Assia, as explained by moeller0), it does make sense to use a dedicated modem (which may very well run OpenWrt itself) - that way you can reboot (upgrade) your router as often as you like, just don't let the modem disconnect unnecessarily.

[dylan]

OK. it's my first time use DSL in Germany, before i am using Cable broadband from VF, there are no such issue. i will try to install the tools to collect the data

[moeller0]

@dylan

i will try to install the tools to collect the data

Excellent, maybe also take screenshot directly after starting the tool and postbit here. A ~24 hour plot is quite useful (especially as go-dsl will show the error time series over the last 24 hours) but often even a first plot witout error history indicates what might be problematic...

And yes DSL typically has a different set of challenges than DOCSIS/cable

[dylan]

Hi Moerller0
i enocounter some problem which use go-dsl tools. if you can help figure it out?

[moeller0]

I think you can leave ´PrivateKeyPath` empty and set KnownHostsPath to 'IGNORE' it should then ask for the password and once you type that in you should be set, assuming it is an issue with automatic login... that said I never tried the windows version og go-dsl so have no first-hand experience to share.
Maybe we can politely ask @janh to have a look at the issue? (We are lucky that we have go-dsl's creator active in this forum).
Or maybe you can install ´luci-mod-dsl´ (´opkg update , opkg install luci-mod-dsl´ assuming this already exists for your OpenWrt version) which also gives you some quick SNR, Bitloading, Hlog and QLN spectra that might help assessing the quality of your link (note personally Ilike go-dsl better).

[dylan]

Hi, it works.
here is the first result, btw i downgrade the openwrt version to 21.02. instead of 22.03
dsl_20230730_114722.zip

[moeller0]

Mmmh, so you are on a reasonably long link, which might explain why even the optimistically estimated Attainable net data rate stays below the maximum of 116.8 Mbps. The sync limit in upload direction seems to be 32.000 Kbps (actual sync typically is a few units below rthe DLM-set upper limit) and for download this smells like 63.680 Kbps limit, which is the upper limit for the VDSL50 tarif. That is, the DLM considers your link to be too unstable to allow higher sync rates.
IIRC only OpüenWrt22 and 23 contain fixes to the vectoring drivers, before that the xrx200 did not sent error samples back to the DSLAM resulting link quality deteriorating over time with the gain from vectoring being lost and relatively many resyncs (these resyncs in turn keep DLM active and the synd rate limits low).
I might be spoiled by never having had a really long line, but to me it looks like there is not enough vectoring gain, that is SNR (and as a consequence bitloading) drop too steeply with increasing sunbcarrier frequency. But as I said, this might not be an issue with your link but simply my lack of experience.
BTW, was there a fourth spectrum called "Channel characteristic (dB)"? For completeness that might be interesting as well. Also please let this run for 24 hours and the post the error-over-time plots from the bottom of the window. You can manually resize the window so it shows the numbers on the left and the spectra on the right, so you can cover most everything in two screenshots, one for text and spectra, and a second one for the error-over-time graphs. Here is an example how this could look:

Note there is some overlap between the two screenshots, but they show all plots...

[pythonic]

2 things stand out to me from my own experience:

• your downstream impulse noise protection value of 71 symbols is much higher than I've ever seen (<50, usually around 43), though I note that @moeller0's example has 69 symbols so this might be fairly standard in .de
• the bit loading and SNR graphs show classic signs of downstream power backoff below 2.2MHz (tone 512) - IIRC this is for co-existence with ADSL in the street wiring infrastructure

The downstream power backoff is probably costing you about 10Mbps in downstream in theoretical speed - that's what I gained when ADSL co-existence was turned off here (Australia) though I'm on a very long line (~1150m according to the stats from the cabinet end, ~950m from my end according to AVM firmware; my FB7530 is only syncing at 49000/8800 kbps).

[moeller0]

@pythonic

• the bit loading and SNR graphs show classic signs of downstream power backoff below 2.2MHz (tone 512) - IIRC this is for co-existence with ADSL in the street wiring infrastructure

Yes, and this is unlikely to go away (any quicker than DSL/copper in general)... This is used for ADSL variants, as well as allowing non vectoring-capable VDSL-modems still to get some internet access (to avoid having to exchange all non-vectoring ADSL modem with vectoring friendly ones, the incumbent opted to simply exclude the frequencies ADSL uses from the set of sub carriers used with /for vectoring). The current plan is to convert the country over to FTTH by 2030 (IIRC, such target dates are occasionally adjusted) so I expect no major changes in the existing POTS/copper access network.

[dylan]

Hi here is the 22hours result, the max speed is going down obviously. i will upgrade the fw to 22.03.05 and try again.
dsl_20230801_054841.zip

[moeller0]

This looks rather insuspicious, mostly like a relative long link and/or relatively thin wires.
To test the error samples hypothesis, could you please force a resync (e.g. by rebooting the homehub) and get a go-dsl screenshot immediately after the connection is working again?

[dylan]

Hi moeller0
i upgrade to FW to 22.03.05 and this is the latest result

[moeller0]

The SNR plot looks a bit better*, as if vectoring works a tad better and the estimated Attainable net data rate for the download increased from 80 to 96 Mbps. If this stays like this I am cautiously optimistic that in 7-14 days Deutsche Telekom's DLM system might decide to increase the sync limits a bit... this really depends on how many errors and proto errors the DSLAM records for your link in that time.

But this still is a long link so the DLM system might never go back to no limit (which might result in a sync of 80-90 Mbps)

*) With OpenWrt21 the initial SNR plot looked OK, but after a day the download bands showed a clear drop (while the uplink bands SNR did not change) with OpenWrt22 now after 24 hours the downlink SNR still looks decent.

[dylan]

Many thanks. Let's see what happen in next 2 weeks.

[slh]

Just avoid rebooting the bthub5 in the mean time (which can be inconvenient at times).

[moeller0]

Please post a new screen shot after 1 week and after 2 weeks. And note that DLM interventions that affect the syncrate come with an ISP-side initiated resync...

[dylan]

improved performance now. i think DSL line resync happen , i will keep observing