Slow VDSL speeds

buchinho · January 31, 2019, 12:13pm

I recently bought a BT Hub 5a which was already flashed on ebay.
Now that I've got it all configured, I'm wondering if it is possible to increase the speed. I was using a Fritzbox 7390 before which could achieve roughly 50mbit/s downstream.
Now with the BT Hub, even after switching to the modem blob of a 7490, I only achieve 20mbit/s.

Here is what LuCi tells me:

Line State: UP [0x0]
Line Mode: G.993.2 (VDSL2)
Line Uptime: 19m 27s
Annex: B
Profile: 17a
Data Rate: 20.532 Mb/s / 1.603 Mb/s
Max. Attainable Data Rate (ATTNDR): 22.143 Mb/s / 1.684 Mb/s
Latency: 0.14 ms / 10.0 ms
Line Attenuation (LATN): 8.3 dB / 3.8 dB
Signal Attenuation (SATN): 8.3 dB / 3.8 dB
Noise Margin (SNR): 6.2 dB / 10.9 dB
Aggregate Transmit Power(ACTATP): 12.8 dB / 10.5 dB
Forward Error Correction Seconds (FECS): 0 / 0
Errored seconds (ES): 0 / 3
Severely Errored Seconds (SES): 0 / 0
Loss of Signal Seconds (LOSS): 2 / 0
Unavailable Seconds (UAS): 1230 / 1230
Header Error Code Errors (HEC): 0 / 0
Non Pre-emtive CRC errors (CRC_P): 0 / 0
Pre-emtive CRC errors (CRCP_P): 0 / 0
ATU-C System Vendor ID: Broadcom 192.85
Power Management Mode: L0 - Synchronized

savostyanov · January 31, 2019, 12:18pm

It might be related more with your ISP line than with your device. Perhaps, try to keep it on your line and see if the speed goes up in a few days.

For information, here's my HH5a stats:

 OpenWrt 18.06.2, r7676-cddd7b4c77
 -----------------------------------------------------
root@OpenWrt:~# /etc/init.d/dsl_control status
ATU-C Vendor ID:                          Infineon 178.6
ATU-C System Vendor ID:                   45,43,49,20,74,65,6C,65
Chipset:                                  Lantiq-VRX200
Firmware Version:                         5.9.0.12.1.7
API Version:                              4.17.18.6
XTSE Capabilities:                        0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x2
Annex:                                    B
Line Mode:                                G.993.2 (VDSL2)
Profile:                                  17a
Line State:                               UP [0x801: showtime_tc_sync]
Forward Error Correction Seconds (FECS):  Near: 8318 / Far: 131808
Errored seconds (ES):                     Near: 32 / Far: 4899
Severely Errored Seconds (SES):           Near: 0 / Far: 1
Loss of Signal Seconds (LOSS):            Near: 0 / Far: 1690
Unavailable Seconds (UAS):                Near: 35 / Far: 35
Header Error Code Errors (HEC):           Near: 0 / Far: 0
Non Pre-emtive CRC errors (CRC_P):        Near: 132 / Far: 0
Pre-emtive CRC errors (CRCP_P):           Near: 0 / Far: 0
Power Management Mode:                    L0 - Synchronized
Latency [Interleave Delay]:               0.0 ms [Fast]   0.0 ms [Fast]
Data Rate:                                Down: 77.449 Mb/s / Up: 20.000 Mb/s
Line Attenuation (LATN):                  Down: 11.0 dB / Up: 9.1 dB
Signal Attenuation (SATN):                Down: 11.0 dB / Up: 9.0 dB
Noise Margin (SNR):                       Down: 6.0 dB / Up: 9.1 dB
Aggregate Transmit Power (ACTATP):        Down: -1.5 dB / Up: -1.4 dB
Max. Attainable Data Rate (ATTNDR):       Down: 77.447 Mb/s / Up: 25.899 Mb/s
Line Uptime Seconds:                      11983
Line Uptime:                              3h 19m 43s

moeller0 · January 31, 2019, 12:23pm

Without knowing all of the details this gives the impression of a vectoring conflict. I assume your DSLAM uses vectoring, but your firmware for the vdsl-modem does not support vectoring and the DSLAM put you on the fallback profile for non-vectoring capable CPE. At least deutsche telekom, does not use vectoring on the lowest 2.2MHz of the spectrum (otherwise, they would need to switch out all non-vectoring capable ADSL[1|2|2+] gear in the field with vectoring capable VDSL2 gear, probably too expensive) and any modem/CPE that does not negotiate vectoring with the DSLAM will be assigned a profile where it can only use those vectoring-free frequencies, as not to negatively interfere with the vectoring processing in the same binder.

Tl;dr: try a firmware blob that supports vectoring, and talk to your ISP as some DSLAMs need a manual port reconfigure (or similar procedure) to get a line out of the fall-back profile again.

savostyanov · January 31, 2019, 12:27pm

Basically, the speed is agreed between your router and your ISP hardware based on their joint estimate of the noise level. Your SNR seem to be a bit high, and this might lead to more conservative speeds atm. You can either wait and see if the situation improves on its own — rapid connections and disconnections of your modem may also be counted as noise and contribute to high SNR estimate. You can get in touch with your ISP to ask them manually reset the line and wipe the stats. You can also upgrade to Snapshots and use the experimental SNR parameter to try to manipulate speeds from your side. Note that snapshots are not stable and you will need to install Luci via ssh.

buchinho · January 31, 2019, 12:47pm

I've tried different firmware blobs from this xdsl site and they all do more or less the same. How can I really make sure that I'm using a VDSL vectoring firmware?

savostyanov · January 31, 2019, 12:49pm

Pick the one here which says incl. vectoring support.

buchinho · January 31, 2019, 12:50pm

Please read my message from above. I've already tried that.

savostyanov · January 31, 2019, 7:00pm

Your Luci output does not tell us which blob you are currently using. You can see it if you log in your router via ssh (putty in windows) and execute /etc/init.d/dsl_control status as shown in my example above. For example, in my example it says:

root@OpenWrt:~# /etc/init.d/dsl_control status
...
Firmware Version:                         5.9.0.12.1.7

This confirms that my blob is 5.9.0.C.1.7, which, according to the xdsl site includes vectoring support. Except my ISP does not support it yet.

moeller0 · February 1, 2019, 11:09pm

I do not know, but if the DSLAM locks you into the non-vectoring fall-back profile you will not really see whether another firmware blob will help until the profile is reset. If you still have the FB around, connect that again and report the sync bandwidth (and maybe also post the spectrum view). If the FB syncs at 50Mbps, try the openwrt box again, with a firmware blob that should support vectoring, if the FB also syncs at 22/1 call your ISP...

buchinho · January 31, 2019, 7:33pm

That did the trick!

ATU-C Vendor ID:                          Broadcom 192.85
ATU-C System Vendor ID:                   Broadcom
Chipset:                                  Lantiq-VRX200
Firmware Version:                         5.7.8.9.1.7
API Version:                              4.17.18.6
XTSE Capabilities:                        0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x2
Annex:                                    B
Line Mode:                                G.993.5 (VDSL2 with down- and upstream vectoring)
Profile:                                  17a
Line State:                               UP [0x801: showtime_tc_sync]
Forward Error Correction Seconds (FECS):  Near: 0 / Far: 0
Errored seconds (ES):                     Near: 0 / Far: 6
Severely Errored Seconds (SES):           Near: 0 / Far: 0
Loss of Signal Seconds (LOSS):            Near: 0 / Far: 0
Unavailable Seconds (UAS):                Near: 111 / Far: 111
Header Error Code Errors (HEC):           Near: 0 / Far: 0
Non Pre-emtive CRC errors (CRC_P):        Near: 0 / Far: 0
Pre-emtive CRC errors (CRCP_P):           Near: 0 / Far: 0
Power Management Mode:                    L0 - Synchronized
Latency [Interleave Delay]:               0.13 ms [Fast]   0.0 ms [Fast]
Data Rate:                                Down: 101.528 Mb/s / Up: 33.473 Mb/s
Line Attenuation (LATN):                  Down: 15.3 dB / Up: 15.1 dB
Signal Attenuation (SATN):                Down: 15.3 dB / Up: 15.2 dB
Noise Margin (SNR):                       Down: 9.3 dB / Up: 9.2 dB
Aggregate Transmit Power (ACTATP):        Down: 2.5 dB / Up: 14.4 dB
Max. Attainable Data Rate (ATTNDR):       Down: 119.374 Mb/s / Up: 35.813 Mb/s
Line Uptime Seconds:                      655
Line Uptime:                              10m 55s

Now there's still the WAN to LAN bug.

moeller0 · January 31, 2019, 7:40pm

What WAN to LAN bug?

savostyanov · January 31, 2019, 10:02pm

You may want to open a new topic to describe the other bug, if your VDSL problem is solved.

moeller0 · February 1, 2019, 1:21pm

I wonder, could you maybe add one more post to this thread explicitly noting which steps you took to actually get this working? So that others facing similar challenges might have an easier time in the future to get it fixed again? That would be great!

buchinho · February 1, 2019, 11:09pm

Ok, here's what I did:

Unplug openwrt-router
Plug in old router (fritzbox).
Fritzbox syncs @ ~100Mbit/s
Plug in openwrt and bob's your uncle!

slh · February 1, 2019, 11:10pm

Using a different device temporarily was probably enough to convince the ISP's DSLAM to reset the port and do a new full link training without fallback profile.

system · February 11, 2019, 11:10pm

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.