Cannot get BT or Plusnet to do anything about my 50% drop

Hi All,

I have 3 ADSL Lines coming into the house, I'm very far from exchange (~4km) and with 5 of us here, 2MB shared wasn't enough So I have 3 lines, 2 are with BT, one with iDNet. The internet connections provided by BT, Plusnet and iDNet.

Now for years, these lines (albeit a little unstable) have been syncing happily day in, day out at ~2.5MB (depending on weather ).

2 Lines (the BT/BT one and the iDNet/iDNet ones) are still syncing away happily at that speed and causing no issues.

However, one line, the BT/Plusnet one since March is not playing ball, it syncs at 1MB.I've been back and forth with Plusnet about this and have done all their suggestions (changing routers, cables, microfilters, plugged into test socket etc. etc.) nothing works and the line won't sync any higher.

Today I had a BT Engineer over, he checked the line anda the line itself was fault-free (no noise etc.) and on his test equipment he saw that it was only syncing at 1MB. He went to exchange and found some equipment was faulty so changed that (good as it means I won't get charged for engineer callout ) but said that my BRAS access profile was still set at 1MB and he couldn't change that and that I should call plusnet.

Of course, I did, they said they reset the profile, so I rebooted router, still only getting 1MB. They aren't really doing anything as it's between the acceptable limits for my line 1-3MB so seem reluctant to do anything else.

So I'm stuck, does anyone have any suggestions on what my best cause of action should be? Will it make a difference if i just leave plusnet and move to another isp?

Here are the router stats from the bad line

Mode ADSL_2plus
Traffic Type ATM
Status Up
Link Power State L0
Downstream Upstream
Line Coding (Trellis) On On
SNR Margin (dB) 5.7 4.8
Attenuation (dB) 62.5 37.3
Output Power (dBm) 17.8 11.8
Attainable Rate (Kbps) 1196 684
Rate (Kbps) 1066 228
MSGc (# of bytes in overhead channel message) 61 24
B (# of bytes in Mux Data Frame) 32 9
M (# of Mux Data Frames in FEC Data Frame) 4 2
T (Mux Data Frames over sync bytes) 1 2
R (# of check bytes in FEC Data Frame) 14 6
S (ratio of FEC over PMD Data Frame length) 3.8421 2.6666
L (# of bits in PMD Data Frame) 304 78
D (interleaver depth) 8 8
Delay (msec) 8 5
INP (DMT symbol) 1.00 2.00
Super Frames 221748 175515
Super Frame Errors 1 1
RS Words 3714246 1055637
RS Correctable Errors 172689 24
RS Uncorrectable Errors 1 0
HEC Errors 1 0
OCD Errors 0 0
LCD Errors 0 0
Total Cells 8970327 1915959
Data Cells 1208388 123755
Bit Errors 18 40
Total ES 1 1
Total SES 0 0
Total UAS 25 25

Have you got the stats from the good lines?

There is no spare margin there so it isn't going to jump to double the speed without something being "fixed". But, that "fix" could require BT spending a lot of man hours and potentially replacing lengths of cable and for a line that is within estimates they aren't likely to do that.

The only chance you might have would be to speak to AAISP as they might be able to help if the line was moved to them - they are more expensive but one of the few ISPs who have been known to get traction in cases like this.

Hi Ian,

THank you for your prompt reply. I'm not expecting a miracle, just to have the line back to how it was for years before something (not at my end) changed

Here are stats from one of the good lines

xDSL
xDSL
Mode ADSL_2plus
Traffic Type ATM
Status Up
Link Power State L0
Downstream Upstream
Line Coding (Trellis) On On
SNR Margin (dB) 3.4 7.5
Attenuation (dB) 62.5 36.6
Output Power (dBm) 18.3 11.8
Attainable Rate (Kbps) 3172 868
Rate (Kbps) 2777 516
MSGc (# of bytes in overhead channel message) 59 24
B (# of bytes in Mux Data Frame) 86 21
M (# of Mux Data Frames in FEC Data Frame) 2 2
T (Mux Data Frames over sync bytes) 1 2
R (# of check bytes in FEC Data Frame) 14 12
S (ratio of FEC over PMD Data Frame length) 1.9815 2.6666
L (# of bits in PMD Data Frame) 759 168
D (interleaver depth) 16 8
Delay (msec) 8 5
INP (DMT symbol) 1.00 2.00
Super Frames 17978924 14370191
Super Frame Errors 735 88031
RS Words 258334003 3005666
RS Correctable Errors 33373 2118
RS Uncorrectable Errors 231 0
HEC Errors 1693 49331
OCD Errors 0 0
LCD Errors 0 0
Total Cells 838367070 155739698
Data Cells 12677543 5845980
Bit Errors 11148 818
Total ES 183 46776
Total SES 10 1
Total UAS 60 50

For the most part the stats are similar (except the obvious speed difference). Quite possible the attenuation is much higher on the "duff" line but the router is likely displaying 62.5 as the highest number it will display rather than the "real" figure.

It could well be a joint somewhere in the network. Could also be that BT at some point swapped part of your line with someone else's causing a drop in performance - pretty difficult to prove that thought.

IT may be that others can advise on the stats further or that getting bin graphs from the good and bad line could help (but beyond my level of knowledge).

As I said before it's possible that AAISP would be able to fight for you to get resolution but it may be beyond their influence.

Please could we also have the stats from the other good line as well? And a repeat of both the others. The SNR Margins in particular are of interest, and seeing if any have changed significantly since those readings were taken.

OK Stats from all 3 lines are

Good line #1

xDSL
xDSL
Mode ADSL_2plus
Traffic Type ATM
Status Up
Link Power State L0
Downstream Upstream
Line Coding (Trellis) On On
SNR Margin (dB) 3.6 7.9
Attenuation (dB) 62.5 36.6
Output Power (dBm) 18.3 11.8
Attainable Rate (Kbps) 3196 868
Rate (Kbps) 2777 516
MSGc (# of bytes in overhead channel message) 59 24
B (# of bytes in Mux Data Frame) 86 21
M (# of Mux Data Frames in FEC Data Frame) 2 2
T (Mux Data Frames over sync bytes) 1 2
R (# of check bytes in FEC Data Frame) 14 12
S (ratio of FEC over PMD Data Frame length) 1.9815 2.6666
L (# of bits in PMD Data Frame) 759 168
D (interleaver depth) 16 8
Delay (msec) 8 5
INP (DMT symbol) 1.00 2.00
Super Frames 18185628 14533761
Super Frame Errors 738 88031
RS Words 265051868 3702286
RS Correctable Errors 33788 2212
RS Uncorrectable Errors 258 0
HEC Errors 1711 49331
OCD Errors 0 0
LCD Errors 0 0
Total Cells 860168435 159788617
Data Cells 13532742 6220561
Bit Errors 12707 818
Total ES 185 46776
Total SES 10 1
Total UAS 60 50

Good line #2

xDSL
xDSL
Mode ADSL_2plus
Traffic Type ATM
Status Up
Link Power State L0
Downstream Upstream
Line Coding (Trellis) On Off
SNR Margin (dB) 3.1 3.9
Attenuation (dB) 61.5 36.6
Output Power (dBm) 18.5 11.8
Attainable Rate (Kbps) 2392 596
Rate (Kbps) 2163 210
MSGc (# of bytes in overhead channel message) 60 19
B (# of bytes in Mux Data Frame) 66 10
M (# of Mux Data Frames in FEC Data Frame) 2 4
T (Mux Data Frames over sync bytes) 1 2
R (# of check bytes in FEC Data Frame) 10 16
S (ratio of FEC over PMD Data Frame length) 1.9525 6.4000
L (# of bits in PMD Data Frame) 590 75
D (interleaver depth) 16 1
Delay (msec) 8 2
INP (DMT symbol) 1.00 0.50
Super Frames 18267286 14453380
Super Frame Errors 62493 473
RS Words 602820399 3545147
RS Correctable Errors 14768621 8626
RS Uncorrectable Errors 123977 0
HEC Errors 76067 640
OCD Errors 7 0
LCD Errors 7 0
Total Cells 1501363770 145737487
Data Cells 657223095 54611601
Bit Errors 3297692 23592
Total ES 24597 97
Total SES 732 7
Total UAS 66 25

And finally the bad line

xDSL
xDSL
Mode ADSL_2plus
Traffic Type ATM
Status Up
Link Power State L0
Downstream Upstream
Line Coding (Trellis) On On
SNR Margin (dB) 5.8 4.7
Attenuation (dB) 62.5 37.3
Output Power (dBm) 17.8 11.8
Attainable Rate (Kbps) 1176 684
Rate (Kbps) 1066 228
MSGc (# of bytes in overhead channel message) 61 24
B (# of bytes in Mux Data Frame) 32 9
M (# of Mux Data Frames in FEC Data Frame) 4 2
T (Mux Data Frames over sync bytes) 1 2
R (# of check bytes in FEC Data Frame) 14 6
S (ratio of FEC over PMD Data Frame length) 3.8421 2.6666
L (# of bits in PMD Data Frame) 304 78
D (interleaver depth) 8 8
Delay (msec) 8 5
INP (DMT symbol) 1.00 2.00
Super Frames 585635 463521
Super Frame Errors 3 1
RS Words 9809353 1249749
RS Correctable Errors 387597 31
RS Uncorrectable Errors 6 0
HEC Errors 5 0
OCD Errors 0 0
LCD Errors 0 0
Total Cells 23690583 5064401
Data Cells 10523677 895422
Bit Errors 18 40
Total ES 3 1
Total SES 0 0
Total UAS 25 25

All 3 lines run exactly same hardware (Bipac billion 8800) and have swapped all cables, microfilters, plugged into test socket and swapped modem on the bad line, no difference.

Many thanks for your assitance

Thanks . No major change in the two we've seen previously then. That's good.

You said in your OP there is minor instability.

I think there is a small but real possibility they were stable enough long term for the DLM (Dynamic Line Management just in case you don't know that) to reduce the sync-time target noise margin from the default 6dB that the Plusnet line now has to either 4dB or 3dB. That would give a substantial increase in sync on the good two.

Given the problem that occurred, and if I'm right, it will take a few weeks for DLM to decide it is stable enough to start doing the same. Then reduce it in steps of 1dB and re-sync, with a while between each step.

That is only a hope and possibility.

Also since my first post I've looked up your posting history, and get the impression these are the same premises. In which case we can see you have been upgraded from ADSL Max to ADSL2+. That has incurred an attenuation increase of about 3dB on the downstream. This is common and occurs on most such upgrades. It depends on the actual modems at each end.

I think it highly likely that if you disable ADSL2+ but retain ADSL2 in your router (try just one of the good ones first, and do this well inside daylight hours) your attenuation will fall back to what it was on ADSL Max. Giving an increase in sync of 500-1500kbps.

The same actually applies to the Plusnet line but I can't decide whether it's best to do that now on that or wait until we see what DLM does. But thinking while I type, it might even be best to try it on that as well if the others do as I expect. I can't see it upsetting DLM even while we wait for it to get friendly!

Note! Only try the once on each line, as the effect will be obvious if it works! If it doesn't drop then forget the idea for the particular line but still try the other two.

Edited by RobertoS (Tue 28-Aug-18 17:54:36)

Just a note. If you read my post about ADSL/ADSL2+ before my edits to it, please re-read it as I made two or three significant changes. One in particular about ADSL2, which is an intermediate protocol between the others.

Hi Roberto,

Many thanks for your reply, I didn't think the DLM took that long to retrain, I assumed it was like a couple of days, not weeks! There's probably no hope of a line here staying stable for weeks

I changed one of the good connections to ADSL2 and I also changed the bad one as well (why not I wondered, it's bad already )

Here's the stats from a good line @ ADSL2

xDSL
xDSL
Mode ADSL_2
Traffic Type ATM
Status Up
Link Power State L0
Downstream Upstream
Line Coding (Trellis) On On
SNR Margin (dB) 3.0 5.0
Attenuation (dB) 57.5 36.8
Output Power (dBm) 18.4 12.2
Attainable Rate (Kbps) 2528 628
Rate (Kbps) 2263 240
K (number of bytes in DMT frame) 0 0
R (number of check bytes in RS code word) 0 0
S (RS code word size in DMT frame) 0 0
D (interleaver depth) 16 2
Delay (msec) 8 2
INP (DMT symbol) 1.00 0.50
Super Frames 18832059 14900251
Super Frame Errors 62658 474
RS Words 5369897 2581008
RS Correctable Errors 24355 43
RS Uncorrectable Errors 35 0
HEC Errors 76120 640
OCD Errors 0 0
LCD Errors 0 0
Total Cells 13779524 1458678
Data Cells 1701725 147423
Bit Errors 1308 0
Total ES 24761 98
Total SES 732 7
Total UAS 96 55

And here's the bad line @ ADSL2

xDSL
xDSL
Mode ADSL_2
Traffic Type ATM
Status Up
Link Power State L0
Downstream Upstream
Line Coding (Trellis) On On
SNR Margin (dB) 6.1 4.9
Attenuation (dB) 58.0 37.1
Output Power (dBm) 17.6 12.2
Attainable Rate (Kbps) 1336 624
Rate (Kbps) 1148 238
K (number of bytes in DMT frame) 41 7
R (number of check bytes in RS code word) 16 4
S (RS code word size in DMT frame) 4.00 4.00
D (interleaver depth) 8 4
Delay (msec) 8 5
INP (DMT symbol) 1.50 2.00
Super Frames 1149268 911475
Super Frame Errors 4 1
RS Words 6890117 1585940
RS Correctable Errors 23735 330
RS Uncorrectable Errors 0 0
HEC Errors 5 0
OCD Errors 0 0
LCD Errors 0 0
Total Cells 18200390 3771517
Data Cells 4941758 875718
Bit Errors 0 0
Total ES 4 1
Total SES 0 0
Total UAS 69 69

Openreach engineers can reset the DLM (they call it an SNR reset) which puts the target margin to 6dB which is the default. If they call BT Wholesale that can also be changed to 3dB.

However it looks like your line is already at 6dB and your max attainable isn�t as good as the other lines anyway. How far are you from the cabinet? How far is the E-side from the cabinet to the exchange? I�d be looking at changing your E-side for starters, or at least checking how things look at the cabinet. Did the engineer do that the other day?

Thank you for your reply,

I'm not actually connected to a cab, or rather, I'm connected direct to the exchange which is over 4km away (I think an engineer once told me the cable length to exchange was about 4.5k). I've absolutely no idea what e-side is though, is it something I should mention to the next engineer I get over?

No cab = no E side

An E side is the pair between cabinet and exchange.

We can see the attenuations have fallen, as I suggested they would. Unfortunately however it is critical on ADSLx to sync as I said - well inside daylight hours. (The quality of the daylight doesn't really matter as long as there aren't thunderstorms anywhere around, miles either side of the line between you and the exchange).

At the time I posted I would have said it was a bit too late. Maybe between 10am and 4pm might be best. There is a lot more electromagnetic noise when the sun is lower against the horizons. For a more detailed explanation of that and how the SNR and SNRM work together at sync time see this page.

Don't do several re-syncs on any one line several times close together, particularly the Plusnet one. One or two tomorrow perhaps then leave things.

Although as has been posted a DLM can be requested by your ISP, one may have been done after the engineer's visit. If not, then it could be helpful in clearing DLM's history of the fault. But I wasn't aware a reset could include an immediate 3dB setting of the SNRM. That would seem odd to me.

Max attainable varies with the target SNRM setting Icaras. It relates to how far either side of that the current SNRM or SNR is (whichever one the modem looks at to calculate the presented figure - it amounts to much the same thing).

If the target SNRM is changed by DLM both sync and attainable move in the same direction, though not necessarily by the same amount.

You may be confusing this with the effect when the line reaches the product cap of 8128 or 24k on BTW ADSLx, where if the SNR is high then the SNRM rockets up along with the Attainable.

Just for clarity -

a �DLM reset� is a reset of FTTC settings, nearly always managed by the engineer requesting it via an app on their work phone.

an �SNR reset� is the done on BT Wholesale broadband ADSL products by the engineer using a system known as WOOSH.

The request of a �hard pinned� profile, so the circuit will have a fixed SNR target, is done on request via a call to BT Wholesale.....

All bets are off if referring to LLU broadband.

Thanks Zarjaz .

But are you saying a complete ADSLx DLM reset can�t be done on BT Wholesale DLM? Or just hat it can�t be triggered by an engineer. (Yes, I know none of this DLM stuff applies to LLU ADSLx but steered clear of that as we know this is a Plusnet line).

Is Icarus right in saying you can actually request a fixed 3dB though? That was my main doubt. I thought this was only used to fix it above 6dB to prevent flapping. Or was that before settings below 6dB were possible and now those can also be fixed?

I thought the max attainable was what the line could sync at if it was at 0 SNR - therefore whether you currently have 3dB SNR or 6dB SNR it would be irrelevant as it would calculate based on the current SNR level. I'm not convinced it changing to a 3dB would have a significant impact on the max attainable - I could of course be wrong...

I�m certainly right in respect of its behaviour on FTTC. I see it every time my target SNRM is adjusted, in either direction. I believe I�m right on BTW ADSLx but hard for me to prove these days.

I don�t remember us being too bothered about Attainable on ADSLx. Just more basic things like sync v attenuation + SNRM and the ring wire. Plus on long lines this choosing of ADSL/ADSL2 instead of 2+. In a few cases of course ADSL turned out to be best of the three, but ADSL2 was frequently the one to go for if your sync was below 4Mbps.

In reply to a post by ian72:

I thought the max attainable was what the line could sync at if it was at 0 SNR

Thinking deeper ... (and you mean SNRM of course].

If that is correct then on the once-upon-a-time minimum setting of 6dB on BTW the Attainable would always have been 1 Mbps to 2 Mbps higher than sync on ADSL Max and 1.4Mbps to 2.5Mbps Mbps on ADSL2+. (Give or take the on-going variances in SNR which on domestic modems we only inferred from the SNRM fluctuations). I don�t think they were.

An engineer with access to the correct systems can do a reset on BTw ADSL kit.

They can also request it via a phone call.

The reset will always wipe back to 6db interleaved.

I�ve never come across a hard pinned 3db target, only 6 and above, being used, as you say, to stop flapping.

That's basically what I thought. Thanks again . (Just the engineer's methods I didn't know).

I�m sure I got them to set it to 3dB once. Maybe my memory is failing me though, or maybe it wasn�t a BT Wholesale circuit.

�Be� LLU?

A hard 3db target is inviting instability though.

I�m not even sure it was a �hard� target. More that they set it to that, but it would still go back to 6 of its own accord if problems set in.

Yes it absolutely could be done in the days of Be LLU, but the great thing about that was the user was able to log into the portal and change it back to 6 if it started dropping.