DLM Reset - Banded to 60Mbs

[#1]

Hello guys, 

I've been successful in the past to get my DLM reset after changing routers and I do hope that this time someone from the awesome Plusnet support  is going to help me with this banded profile.

I have been banded for about a year to 60Mbs and I've decided to get one of the Zyxel gateway which is on the approved Openreach list of modems.

The issue I am having is that even after I've changed to Zyxel my profile band has remained on, obviously the DLM is broken in my case and it might require a manual reset.

By looking at the SNR per tone distribution graphs nothing goes over 6 but my SNRM has remained stubborn at 9db for ages.

There are also transient FEC error event spikes upping at around 6400 per minute, just for one minute a day, without a disconnection but I guess this is down to the copper.

I cam provide logs and screenshots of needed, my wholesale IP profile is at 58.02. G.INP is working as intended, no vectoring though.

It would be amazing if I could get this line back to the 6dbm SNRM and get rid of the 60Mbs banded issue.

xdslctl: ADSL driver and PHY status
Status: Showtime
Last Retrain Reason: 0
Last initialization procedure status: 0
Max: Upstream rate = 15841 Kbps, Downstream rate = 73479 Kbps
Bearer: 0, Upstream rate = 15844 Kbps, Downstream rate = 60000 Kbps
Bearer: 1, Upstream rate = 0 Kbps, Downstream rate = 0 Kbps
Link Power State: L0
Mode: VDSL2 Annex B
VDSL2 Profile: Profile 17a
TPS-TC: PTM Mode(0x0)
Trellis: U:ON /D:ON
Line Status: No Defect
Training Status: Showtime
Down Up
SNR (dB): 9.4 5.5
Attn(dB): 19.1 0.0
Pwr(dBm): 12.7 6.6

[#2]

Hi Justinian.

I've passed your circuit details to one of my colleagues in our faults team to request a DLM reset.

As it's just a trial I can't guarantee this will be successful.

From previous experience if successful it may take about a week for the banding to be removed. It's worth noting that G.INP would likely also be removed as part of the process and isn't something we can influence/bring back manually.

Let me know soon if you decide not to go ahead with the reset.

Cheers.

Anoush

[#3]

Thanks Anoush,

As far as I remember G.INP has been applied couple of days after the last fault we got on this line when the downstream was declared as impacted. I hope it will come back this time as well. Any ideas about the high FEC error events ? Last spikes has happened today around 14.57 and 15.06.

We can go ahead with the DLM reset.

Regards,

Justinian

[#4]

No problems Justinian.
Fingers crossed the DLM reset works in your favour.
To be honest, I don’t fully understand FEC errors. It’s something that we don’t see from our test results. IIRC testing your line earlier today wasn’t flagging any issues.

Apart from the speed issue, do you experience any connection problems?

[#5]

Hello guys,

So 14 hours ago the DLM reset kicked in and I must thank you for that, looks like the trial is working, but while my SNRM dropped from 9 to 6.6 the banding remained and there is no speed increase even if max attainable is 14 Mbs over the connection synch. I can fit another DSL line in that 14Mbs. Also as warned G.INP went off which in turn is going to increase the error rate which in turn it is going to impact even more the DSLAM configs for my line.

The stats right now are:

Status: Showtime
Last Retrain Reason: 1
Last initialization procedure status: 0
Max: Upstream rate = 15837 Kbps, Downstream rate = 73943 Kbps
Bearer: 0, Upstream rate = 15788 Kbps, Downstream rate = 59822 Kbps

Link Power State: L0
Mode: VDSL2 Annex B
VDSL2 Profile: Profile 17a
TPS-TC: PTM Mode(0x0)
Trellis: U:ON /D:ON
Line Status: No Defect
Training Status: Showtime
Down Up
SNR (dB): 6.6 6.0
Attn(dB): 19.3 0.0
Pwr(dBm): 12.6 6.6

[#6]

You were warned that G.Inp would be removed if you went ahead with the DLM reset and that's what has happened.

I don't think the line is banded anymore as the sync is no longer exactly 60Mbps, unfortunately the sync is now below that speed.

All you can hope for is that G.Inp will return quickly, but it seems to be rather unpredictable and can take from a couple of days to several months!

It is unlikely that you will ever get the Maximum rate of around 74 Mbps because that is a theoretical figure calculated by the modem which can sometimes be over estimated, particularly if interleaving is active on the line. Hopefully when G.Inp returns you should see some improvement in the download speed.

[#7]

By the numbers and 10000% increase in the FEC errors without G.INP I really think that the DLM is going to either band me again and set the SNRM target at 9db (or worse) or both. Hoping for the best but I know it is useless with Openreach.

[#8]

Don't worry about FEC errors, they are corrected and do not influence DLM, the ones to watch are CRCs and Error Seconds (ES). There's nothing you can do about the DLM system apart from wait and see what happens!

[#9]

I'm glad to hear something is happening.

From experience it generally can take about a week for a DLM reset to fully work.

As I requested the reset towards to the end of last week, it wasn't sent over to our suppliers until yesterday.

[#10]

Thanks guys,

No more banding, yay.

Awesome Plusnet support as ever the case. G.INP is now back, number of CRC and ES is back to acceptable levels and I had also got a speed bonus:

xdslctl info --stats
xdslctl: ADSL driver and PHY status
Status: Showtime
Last Retrain Reason: 1
Last initialization procedure status: 0
Max: Upstream rate = 15799 Kbps, Downstream rate = 72660 Kbps
Bearer: 0, Upstream rate = 15799 Kbps, Downstream rate = 70118 Kbps
Bearer: 1, Upstream rate = 0 Kbps, Downstream rate = 0 Kbps
Link Power State: L0
Mode: VDSL2 Annex B
VDSL2 Profile: Profile 17a
TPS-TC: PTM Mode(0x0)
Trellis: U:ON /D:ON
Line Status: No Defect
Training Status: Showtime
Down Up
SNR (dB): 6.6 6.0
Attn(dB): 19.3 0.0
Pwr(dBm): 12.6 6.6

VDSL2 framing
Bearer 0
MSGc: -6 23
B: 243 237
M: 1 1
T: 0 64
R: 10 16
S: 0.0000 0.4792
L: 18338 4240
😧 8 1
I: 254 127
N: 254 254
Q: 8 0
V: 0 0
RxQueue: 57 0
TxQueue: 19 0
G.INP Framing: 18 0
G.INP lookback: 19 0
RRC bits: 0 24
Bearer 1
MSGc: 154 -6
B: 0 0
M: 2 0
T: 2 0
R: 16 0
S: 6.4000 0.0000
L: 40 0
😧 3 0
I: 32 0
N: 32 0
Q: 0 0
V: 0 0
RxQueue: 0 0
TxQueue: 0 0
G.INP Framing: 0 0
G.INP lookback: 0 0
RRC bits: 0 0

BT IP Profile managed to catch-up at 67.8, speedtest not quite yet:

speedtest.py 

Retrieving speedtest.net configuration...

Testing from Plusnet (81.174.249.31)...

Retrieving speedtest.net server list...

Selecting best server based on ping...

Hosted by Cybersmart Pty Ltd (London) [13.28 km]: 21.955 ms

Testing download speed................................................................................

Download: 53.66 Mbit/s

Testing upload speed................................................................................................

Upload: 14.28 Mbit/s

[#11]

Being able to resolve this without an engineer visit is awesome, the trial looks successful in this case.

[#12]

That's looking good now that G.Inp has returned, your speed has increased significantly.

[#13]

Hi @Justinian,

Thank you very much for confirming that this has resolved the issue. Please don't hesitate to get back in touch if there's anything else that we can help with.

[#14]

I thought I'd pop back on here too.

Cheers for letting us know @Justinian

I'm glad to hear the DLM reset request did the trick.

[#15]

Thanks Anoush,

Not a big problem but I think I've discovered some interference on couple of the high VDSL2 tones, there are a couple of tones hardly usable:

   3180         5

   3181         5

   3182         5

   3183         5

   3184         5

   3185         5

   3186         4

   3187         4

   3188         4

   3189         3

   3190         0

   3191         0

   3192         2

   3193         3

   3194         4

   3195         4

   3196         4

   3197         4

   3198         3

   3199         5

   3200         5

   3201         5

   3202         5

At the same time the number of bit-swaps happening on those tones is as high as possible.

Not sure if this is another VDSL line crosstalk or some kind of other problem on the copper on that frequencies:

tone 3190/13756.875Khz

and

tone 3191/13761.1875Khz