Kitz Forum
Broadband Related => FTTC and FTTP Issues => Topic started by: russellhq on October 07, 2018, 01:06:10 AM
-
My line used to sync around 62mbps, but it dropped recently and is now around 55mbs. I'm wondering if there's anything in the line stats which might give a clue? I'm a total noob to all this!
xdslcmd info --stats
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 0
Last initialization procedure status: 0
Max: Upstream rate = 22424 Kbps, Downstream rate = 59516 Kbps
Bearer: 0, Upstream rate = 17000 Kbps, Downstream rate = 54999 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): 7.7 9.1
Attn(dB): 13.7 0.0
Pwr(dBm): 12.7 3.9
VDSL2 framing
Bearer 0
MSGc: -6 -6
B: 227 163
M: 1 1
T: 0 0
R: 12 12
S: 0.1319 0.3047
L: 14562 4621
D: 4 2
I: 240 176
N: 240 176
Q: 4 2
V: 0 1
RxQueue: 130 115
TxQueue: 26 23
G.INP Framing: 18 18
G.INP lookback: 26 23
RRC bits: 24 24
Bearer 1
MSGc: 122 58
B: 0 0
M: 2 2
T: 2 2
R: 16 16
S: 8.0000 16.0000
L: 32 16
D: 1 1
I: 32 32
N: 32 32
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
Counters
Bearer 0
OHF: 0 0
OHFErr: 0 0
RS: 179503564 626834
RSCorr: 76 183
RSUnCorr: 0 0
Bearer 1
OHF: 369867 371068
OHFErr: 0 0
RS: 2958443 1484273
RSCorr: 0 5
RSUnCorr: 0 0
Retransmit Counters
rtx_tx: 94475512 148
rtx_c: 4 2855069
rtx_uc: 0 4181232
G.INP Counters
LEFTRS: 0 7884
minEFTR: 55003 16997
errFreeBits: 4984492 3914870058
Bearer 0
HEC: 0 0
OCD: 0 0
LCD: 0 0
Total Cells: 628341263 0
Data Cells: 5821565 0
Drop Cells: 0
Bit Errors: 0 0
Bearer 1
HEC: 0 0
OCD: 0 0
LCD: 0 0
Total Cells: 0 0
Data Cells: 0 0
Drop Cells: 0
Bit Errors: 0 0
ES: 0 0
SES: 0 0
UAS: 26 26
AS: 5939
Bearer 0
INP: 54.00 55.00
INPRein: 1.00 1.00
delay: 0 0
PER: 0.00 0.00
OR: 0.01 0.01
AgR: 55120.28 17156.70
Bearer 1
INP: 2.00 4.00
INPRein: 2.00 4.00
delay: 0 0
PER: 16.06 16.06
OR: 63.75 31.87
AgR: 63.75 31.87
Bitswap: 3095/3095 415/416
Total time = 1 hours 39 min 25 sec
FEC: 76 183
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 26 26
LOS: 0 0
LOF: 0 0
LOM: 0 0
Latest 15 minutes time = 9 min 25 sec
FEC: 3 13
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Previous 15 minutes time = 15 min 0 sec
FEC: 5 25
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Latest 1 day time = 1 hours 39 min 25 sec
FEC: 76 183
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 26 26
LOS: 0 0
LOF: 0 0
LOM: 0 0
Previous 1 day time = 0 sec
FEC: 0 0
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Since Link time = 1 hours 38 min 57 sec
FEC: 76 183
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
#
-
Welcome, russellhq!
-
Welcome Russellhq,
It looks as if you've been banded, but with a downstream snr 7.7 you should start to see heathly improvements in the near(ish) future.
It's really just a waiting game :(
-
Unfortunately there's insufficient stats to say what may have happened, as the modem appears to have been recently rebooted. However, what I can say is that your line appears to have 'retransmission high' in regards to error correction on both downstream and upstream as well as banding on both downstream and upstream. This could indicate that your modem re-synced (lost connection with the cabinet and retrained) many times in a short timeframe.
I would first try to determine if there's a fault with your line, although it could intermittent, or that your modem is unstable for some reason (given the fact it appears to have been rebooted recently based on the counters).
Welcome to the forum.
-
Thanks all and hello also :)
I just bought this modem along with a HH5a running OpenWrt, before this it was a PlusNet hub one. It took me a while to get the set-up working how I wanted which meant a lot of disconnects and resyncing... So I would put the disconnects down to this rather than a fault.
So sounds like my line should support higher speeds but because of all the disconnects it's sitting artificially low.
Any idea how long it should take to recover and is there any way to fast track this process like tuning a setting or something?
-
Connection stats update after being stable for the night:
xdslcmd info --stats
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 0
Last initialization procedure status: 0
Max: Upstream rate = 23171 Kbps, Downstream rate = 57692 Kbps
Bearer: 0, Upstream rate = 17000 Kbps, Downstream rate = 54999 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): 7.2 9.4
Attn(dB): 13.7 0.0
Pwr(dBm): 12.7 3.9
VDSL2 framing
Bearer 0
MSGc: -6 -6
B: 227 163
M: 1 1
T: 0 0
R: 12 12
S: 0.1319 0.3047
L: 14562 4621
D: 4 2
I: 240 176
N: 240 176
Q: 4 2
V: 0 1
RxQueue: 130 115
TxQueue: 26 23
G.INP Framing: 18 18
G.INP lookback: 26 23
RRC bits: 24 24
Bearer 1
MSGc: 122 58
B: 0 0
M: 2 2
T: 2 2
R: 16 16
S: 8.0000 16.0000
L: 32 16
D: 1 1
I: 32 32
N: 32 32
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
Counters
Bearer 0
OHF: 0 0
OHFErr: 0 0
RS: 1310950184 2501303
RSCorr: 715 1187
RSUnCorr: 0 0
Bearer 1
OHF: 2700824 614039
OHFErr: 0 2
RS: 21606101 2254831
RSCorr: 1 47
RSUnCorr: 0 0
Retransmit Counters
rtx_tx: 94475672 701
rtx_c: 35 2855622
rtx_uc: 0 4181232
G.INP Counters
LEFTRS: 0 7884
minEFTR: 54989 16994
errFreeBits: 36397464 3924567014
Bearer 0
HEC: 0 0
OCD: 0 0
LCD: 0 0
Total Cells: 293434897 0
Data Cells: 109501649 0
Drop Cells: 0
Bit Errors: 0 0
Bearer 1
HEC: 0 0
OCD: 0 0
LCD: 0 0
Total Cells: 0 0
Data Cells: 0 0
Drop Cells: 0
Bit Errors: 0 0
ES: 0 0
SES: 0 0
UAS: 26 26
AS: 43380
Bearer 0
INP: 54.00 55.00
INPRein: 1.00 1.00
delay: 0 0
PER: 0.00 0.00
OR: 0.01 0.01
AgR: 55120.28 17156.70
Bearer 1
INP: 2.00 4.00
INPRein: 2.00 4.00
delay: 0 0
PER: 16.06 16.06
OR: 63.75 31.87
AgR: 63.75 31.87
Bitswap: 17936/17936 2895/2899
Total time = 12 hours 3 min 26 sec
FEC: 715 1187
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 26 26
LOS: 0 0
LOF: 0 0
LOM: 0 0
Latest 15 minutes time = 3 min 26 sec
FEC: 14 9
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Previous 15 minutes time = 15 min 0 sec
FEC: 22 36
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Latest 1 day time = 12 hours 3 min 26 sec
FEC: 715 1187
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 26 26
LOS: 0 0
LOF: 0 0
LOM: 0 0
Previous 1 day time = 0 sec
FEC: 0 0
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Since Link time = 12 hours 2 min 59 sec
FEC: 715 1187
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
#
-
Any idea how long it should take to recover and is there any way to fast track this process like tuning a setting or something?
In my experience, it will take as long as it takes which could be a matter of days or some weeks. My line speed fell from 79 to 69 overnight,and G.INP/interleaving has kicked in. I can see no reason for it but, rather than fiddle, I will just sit back and wait. There was talk a while ago about ISPs being allowed to initiate a line re-set but I am not sure whether this has been rolled out.
-
The downstream is capped at 55Mb.
The Max Attainable varies between the 2 sets of stats posted so the line should achieve somewhere between 57-59Mb without the cap.
The upstream may also be capped, it certainly looks like it.
The upstream should get the full 20Mb but it's capped at 17Mb.
Both downstream/upstream have Retransmission High.
With the up/down banding this suggests there has been an issue in the lines past. The upstream has had thousands of LEFTERS at some point.
Banding/capping has a tendency to be "sticky".
DLM should remove it fairly promptly if the line remains stable but we see it frequently remain for months (years on some lines).
Banding is usually caused by many resyncs in a short period of time. Testing new modems and those resyncing the line over and over unaware of the workings of DLM are most vulnerable to banding.
What is the ISP? Some ISP's can now request a DLM reset on FTTC lines.
I would be attempting to get this done.
I also advise running DslStats (http://dslstats.me.uk) on the line. This will catch any issues causing bursts of errors or multiple resyncs.
It also gives graphs of the lines Hlog/QLN/Bitloading which would all be great to attach to the thread for us to see and look for physical issues on the line.
-
Thanks John. I've attached the graphs from dslstats which might give more insight?
My ISP is PlusNet
[Moderator edited to detach the truncated graph.]
-
Welcome to the Kitz forum. :)
A VDSL2 (G.993.2), Profile 17a, circuit (as deployed by Openreach in the UK) uses a total of 4096 sub-carriers (a.k.a. "tones") numbered from 0 to 4095. Unfortunately you have not configured DSLstats to display all of the sub-carriers, as the plot you have shown is truncated at sub-carrier 1250. Go to one of the displays which have the frequency (i.e. sub-carriers or tones) as the X-axis (e.g. Hlog, QLN or Bitloading) and you will see a button labelled "Change tone range". Left-click on it, select the "Custom" option and adjust the slider so that full 4096 sub-carriers are shown.
The two plots that I would always first examine are those of the Hlog and QLN. They give a good indication of the health of the physical infrastructure.
-
I though I'd attached those but I think I attached them over the top of each other instead of clicking "more attachments" :-[
That should be the 3 of them attached with the wider tone range.
-
Ah, I wondered why you referred to "attached [the] graphs" when only one was present. :D
So, infrastructure wise, there is nothing obviously wrong with the circuit. The Hlog plot shows a very slight "lazy roll" that begins in DS2 and continues through US2. It's certainly nothing to worry about. The QLN plot shows the usual RFI from broadcast transmitters, a significant notch due to the DSPBO and then a number of "flying gulls" ((tm) kitz) as a result of crosstalk from other circuits within the D-side cable.
As for the Bitloading plot, I see nothing that concerns me . . . but I would rather wait for j0hn (or A.N.Other) to pronounce upon what can be deduced.
-
I reported my drop in speed to Plus.net and they are going to send out an engineer. They also ran a test on my line and said there is no cap on it. I'm not sure what to make of the results (attached)
-
I reported my drop in speed to Plus.net and they are going to send out an engineer. They also ran a test on my line and said there is no cap on it. I'm not sure what to make of the results (attached)
Looking at the GEA Test result I can see no obvious reason why Plusnet have requested an Openreach visit. b*cat is puzzled. ???
-
Sigh, this again.
There IS a cap.
The GEA Test Plusnet is running shows a line profile which is 13 days out of date, as is every single GEA Test line profile that Plusnet run.
There is absolutely no need for a engineer. They may not even issue a DLM reset, which is what you need.
Plusnet can request this without the need to book an engineer.
-
Thanks j0hn. I will get back in touch with Plus.net and as for a DLM reset. I don't want to end up paying for an engineer visit if they end up not finding a fault.
Out of interest, how were you able to tell the line profile was 13 days out of date?
Also, would a cap make my max rate look lower than what could be achieved? I know that I used to sync at 65mbps, but my max rate suggests this would no longer be possible ???
-
From comparing multiple Plusnet GEA tests, we concluded some time ago that the line profile shown on these tests was using old data.
This was narrowed down by a members recent GEA test that was repeated a number of times over a number of days, during which time the line profile changed numerous times.
I came to the observation that ALL Plusnet GEA tests show a DLM line profile that was in use on the line 13 days prior.
If the line profile hasn't changed in those 13 days then it will look correct.
I've no idea if this happens with all GEA tests with all ISP's.
Plusnets willingness to run GEA tests on demand and publish these means it was easier to come to that conclusion with them.
-
An engineer was out today and performed a reset on the line. The speed is up from 55mbps to 60mbps and the the upload from 17mbps to 20mbps. So seems like an improvement but not as fast as it was before ???
I've attached the charts from dslstats following the reset in case there is anything to be found from them.
Also, I've copied the telnet data below as well. It looks like I'm getting a lot more CRC errors than before (it was 0 before). I'm starting to wonder if there is a problem with my line that's not letting me get above 60mbps ???
xdslcmd info --stats
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 1
Last initialization procedure status: 0
Max: Upstream rate = 21456 Kbps, Downstream rate = 59532 Kbps
Bearer: 0, Upstream rate = 19999 Kbps, Downstream rate = 60735 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.1 6.3
Attn(dB): 13.7 0.0
Pwr(dBm): 12.6 4.3
VDSL2 framing
Bearer 0
MSGc: -6 26
B: 243 237
M: 1 1
T: 0 42
R: 10 16
S: 0.1279 0.3781
L: 15884 5374
D: 8 1
I: 254 127
N: 254 254
Q: 8 0
V: 0 0
RxQueue: 48 0
TxQueue: 16 0
G.INP Framing: 18 0
G.INP lookback: 16 0
RRC bits: 0 24
Bearer 1
MSGc: 122 -6
B: 0 0
M: 2 0
T: 2 0
R: 16 0
S: 8.0000 0.0000
L: 32 0
D: 1 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
Counters
Bearer 0
OHF: 0 1504964
OHFErr: 0 434
RS: 1231078864 1507528
RSCorr: 1812 2505
RSUnCorr: 0 0
Bearer 1
OHF: 2460824 0
OHFErr: 0 0
RS: 19686101 0
RSCorr: 2 0
RSUnCorr: 0 0
Retransmit Counters
rtx_tx: 94489035 42760
rtx_c: 1527 2913211
rtx_uc: 106081 4272374
G.INP Counters
LEFTRS: 27 7921
minEFTR: 60726 17000
errFreeBits: 2322890391 4281355376
Bearer 0
HEC: 0 0
OCD: 0 0
LCD: 0 0
Total Cells: 321659861 0
Data Cells: 57230841 0
Drop Cells: 0
Bit Errors: 0 0
Bearer 1
HEC: 0 0
OCD: 0 0
LCD: 0 0
Total Cells: 0 0
Data Cells: 0 0
Drop Cells: 0
Bit Errors: 0 0
ES: 21 351
SES: 21 0
UAS: 103 82
AS: 39528
Bearer 0
INP: 48.00 0.00
INPRein: 0.00 0.00
delay: 0 0
PER: 0.00 3.98
OR: 0.01 64.22
AgR: 60797.09 20063.54
Bearer 1
INP: 2.00 0.00
INPRein: 2.00 0.00
delay: 0 0
PER: 16.06 0.01
OR: 63.75 0.01
AgR: 63.75 0.01
Bitswap: 9428/9428 3746/3748
Total time = 1 days 36 min 48 sec
FEC: 41103 174708
CRC: 1107 434
ES: 21 351
SES: 21 0
UAS: 103 82
LOS: 2 0
LOF: 18 0
LOM: 0 0
Latest 15 minutes time = 6 min 48 sec
FEC: 7 8
CRC: 0 3
ES: 0 3
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Previous 15 minutes time = 15 min 0 sec
FEC: 15 41
CRC: 0 13
ES: 0 11
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Latest 1 day time = 36 min 48 sec
FEC: 23 71
CRC: 0 23
ES: 0 21
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Previous 1 day time = 24 hours 0 sec
FEC: 4671 12193
CRC: 549 411
ES: 10 330
SES: 10 0
UAS: 37 27
LOS: 1 0
LOF: 9 0
LOM: 0 0
Since Link time = 10 hours 58 min 47 sec
FEC: 1812 2505
CRC: 0 434
ES: 0 351
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
#
-
That's an odd DLM reset.
It has removed the banding but kept G.INP active.
I've never seen that before.
The line may drop to a 3dB target SNRM in the next week or 2. If it does it could give you another 10MB or so.
-
The line seems to have been running OK for the last couple of weeks, but no sign of the speed increasing or the SNR margin dropping. I got a call back from Plus.net asking how the connection had been, I said the speed wasn't great and if there was anything else that could be done, I suggested the 3dB SNRM option. The guy on the phone didn't have a clue and made something up about that only applying to ADSL lines and not fibre lines like I am on ::) He said as I was getting above the minimum speed that there's pretty much nothing else they will do :(
I rebooted the modem at the weekend and the speed dropped a bit to 57.5Mbps, which is frustratingly just above what they guarantee (57.3Mbps).
xdslcmd info --stats
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 0
Last initialization procedure status: 0
Max: Upstream rate = 20839 Kbps, Downstream rate = 56748 Kbps
Bearer: 0, Upstream rate = 20000 Kbps, Downstream rate = 57507 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.5 6.5
Attn(dB): 13.7 0.0
Pwr(dBm): 12.6 4.3
VDSL2 framing
Bearer 0
MSGc: -6 26
B: 235 237
M: 1 1
T: 0 45
R: 12 16
S: 0.1306 0.3782
L: 15191 5373
D: 8 1
I: 248 127
N: 248 254
Q: 8 0
V: 1 0
RxQueue: 48 0
TxQueue: 16 0
G.INP Framing: 18 0
G.INP lookback: 16 0
RRC bits: 0 24
Bearer 1
MSGc: 122 -6
B: 0 0
M: 2 0
T: 2 0
R: 16 0
S: 8.0000 0.0000
L: 32 0
D: 1 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
Counters
Bearer 0
OHF: 0 161971
OHFErr: 0 11
RS: 21019896 2992002
RSCorr: 64 22
RSUnCorr: 0 0
Bearer 1
OHF: 42957 0
OHFErr: 0 0
RS: 343159 0
RSCorr: 0 0
RSUnCorr: 0 0
Retransmit Counters
rtx_tx: 94492748 0
rtx_c: 0 0
rtx_uc: 0 0
G.INP Counters
LEFTRS: 0 0
minEFTR: 57495 0
errFreeBits: 605130 0
Bearer 0
HEC: 0 0
OCD: 0 0
LCD: 0 0
Total Cells: 76278146 0
Data Cells: 3491292 0
Drop Cells: 0
Bit Errors: 0 0
Bearer 1
HEC: 0 0
OCD: 0 0
LCD: 0 0
Total Cells: 0 0
Data Cells: 0 0
Drop Cells: 0
Bit Errors: 0 0
ES: 0 11
SES: 0 0
UAS: 27 27
AS: 690
Bearer 0
INP: 49.00 0.00
INPRein: 0.00 0.00
delay: 0 0
PER: 0.00 4.27
OR: 0.01 59.93
AgR: 57598.81 20059.81
Bearer 1
INP: 2.00 0.00
INPRein: 2.00 0.00
delay: 0 0
PER: 16.06 0.01
OR: 63.75 0.01
AgR: 63.75 0.01
Bitswap: 151/151 36/36
Total time = 11 min 57 sec
FEC: 64 22
CRC: 0 11
ES: 0 11
SES: 0 0
UAS: 27 27
LOS: 0 0
LOF: 0 0
LOM: 0 0
Latest 15 minutes time = 11 min 57 sec
FEC: 64 22
CRC: 0 11
ES: 0 11
SES: 0 0
UAS: 27 27
LOS: 0 0
LOF: 0 0
LOM: 0 0
Previous 15 minutes time = 0 sec
FEC: 0 0
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Latest 1 day time = 11 min 57 sec
FEC: 64 22
CRC: 0 11
ES: 0 11
SES: 0 0
UAS: 27 27
LOS: 0 0
LOF: 0 0
LOM: 0 0
Previous 1 day time = 0 sec
FEC: 0 0
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Since Link time = 11 min 29 sec
FEC: 64 22
CRC: 0 11
ES: 0 11
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
#
-
I also seem to be getting more CRC errors than before (before it was 0)
-
I got a call back from Plus.net asking how the connection had been, I said the speed wasn't great and if there was anything else that could be done, I suggested the 3dB SNRM option. The guy on the phone didn't have a clue and made something up about that only applying to ADSL lines and not fibre lines like I am on ::)
The ISP can only change this on ADSL.
DLM on FTTC is entirely automated.
Capping the line has been known to "nudge" DLM in to lowering the target SNRM.