I guess I will just have to wait for G.Fast (FTTP) to fix that.

G.FAST is not FTTP Tim. It is a faster form of FTTC. And native FTTP is almost certainly many years away.

Edited by RobertoS (Tue 28-Mar-17 09:13:32)

Looking at your graphs again, there is very little you can do to improve downstream - just keep any electronics and power supplies away from the incoming line.

In the U2 band the attenuation is not shown on Hlog for a number of tones - I have no idea why but it is definitely a little odd. Can you access the full data - in your local DSLstats under <Telnet Data> <Hlog> there is a list of ones and values. In the range of tones from 2500 to 2600 there will be values from -50 to -60 normally, what other extreme values can you see? And then under <SNR> what are the corresponding vales?

xdslctl info --stats
xdslctl: ADSL driver and PHY status
Status: Showtime
Last Retrain Reason: 1
Last initialization procedure status: 0
Max: Upstream rate = 12462 Kbps, Downstream rate = 46990 Kbps
Bearer: 0, Upstream rate = 12466 Kbps, Downstream rate = 43986 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.3 5.9
Attn(dB): 19.9 0.0
Pwr(dBm): 11.2 7.3

VDSL2 framing
Bearer 0
MSGc: 17 26
B: 239 237
M: 1 1
T: 64 56
R: 0 16
S: 0.1737 0.6071
L: 11056 3347
D: 1 1
I: 240 127
N: 240 254

Counters
Bearer 0
OHF: 3911902 1284491
OHFErr: 1460 0
RS: 0 3176421
RSCorr: 0 0
RSUnCorr: 0 0

Bearer 0
HEC: 143 0
OCD: 0 0
LCD: 0 0
Total Cells: 922925712 0
Data Cells: 5112350 0
Drop Cells: 0
Bit Errors: 0 0

ES: 20554 3
SES: 21 2
UAS: 380 359
AS: 10913

Bearer 0
INP: 0.00 0.00
INPRein: 0.00 0.00
delay: 0 0
PER: 2.78 8.53
OR: 65.96 30.00
AgR: 44051.92 12495.84

Bitswap: 746/782 2/2

Total time = 17 hours 38 min 14 sec
FEC: 0 150
CRC: 41409 1
ES: 20554 3
SES: 21 2
UAS: 380 359
LOS: 2 0
LOF: 13 0
LOM: 0 0
Retr: 2
Latest 15 minutes time = 8 min 14 sec
FEC: 0 0
CRC: 73 0
ES: 65 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Retr: 0
Previous 15 minutes time = 15 min 0 sec
FEC: 0 0
CRC: 128 0
ES: 113 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Retr: N/A
Latest 1 day time = 17 hours 38 min 14 sec
FEC: 0 150
CRC: 41409 1
ES: 20554 3
SES: 21 2
UAS: 380 359
LOS: 2 0
LOF: 13 0
LOM: 0 0
Retr: 2
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
Retr: 0
Since Link time = 3 hours 1 min 53 sec
FEC: 0 0
CRC: 1460 0
ES: 1273 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Retr: 0
NTR: mipsCntAtNtr=0 ncoCntAtNtr=0

Here is the output from DSLStats Telnet and Matt has said the line has failed an extended test so it has been raised to Openreach who will look at my line.

So Uno has told me BT Wholesale are seeing excessive errors on the line so we have kicked off 24 hours of monitoring in the test socket.

BT want to send an SFI Engineer to the property which I have my reservations about.

BT want to send an SFI Engineer to the property which I have my reservations about.

Seems like a reasonable suggestion rather than just bodging a DLM reset out of Openreach and masking an issue

Its just the charges and disputing them is all. I dont like confrontation.

Anyway see what 24hr monitoring in the test socket turns up.

Its just the charges and disputing them is all. I dont like confrontation.

If it tests duff in the test jack, then there should be no charges, end of ...

I suspect the drop wire which is underground put in in the 80s, thick grey cable but thats just a guess.

In reply to a post by Zarjaz:

Seems like a reasonable suggestion rather than just bodging a DLM reset out of Openreach and masking an issue

Not "bodging" and relevant to the fault seen on that line specifically. Sometimes you have to go outside of the norm to get things done. Much like with earl ADSL Max days where BTW stated that turning DLM off wasn't possible when DLM would cause havoc - yet could be done by speaking to the right people.

Matt