Poor FTTC - Stats included please look

Hi, looking for a bit of advice here.
Had FTTC installed by plusnet on 14th October, estimated speeds were 21 - 14.9Mbps clean or 18 - 8.7 impacted.
I first synced at 7.5 and after a couple of days raised a ticket. Since then I've had 3 engineer visits (1st & 3rd were same guy) and on the last visit he found an earth fault and swapped my pair from the cab to the DP.He supposedly performed a DLM reset but I never noticed any difference after.
However in his report to Plusnet he remarked that as I'm 500mtrs from the DP in his opinion the line is working as well as it can. Now the total length of copper to the cab from my address is 1500mtrs and the DP is 500mtrs from me and so obviously 1000mtrs from the cab.
Plusnet support closed my ticket on the strength of this engineer report and since then I've been stuck between 5 and 6Mbps.
I've just got my hands on a HG612 (was originally given an ECI) and have flashed it and here's what it came up with.
Would someone who understands have a look and see if there's anything obvious amiss and/or anything I can do to make FTTC work better for me.
Thanks

EDIT; oh and btw the engineer told me that my cab Chapel St Leonards cab 1 has vectoring enabled

BusyBox v1.9.1 (2014-01-21 16:44:38 CST) built-in shell (ash)
Enter 'help' for a list of built-in commands.

# xdslcmd info --state
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 0
Last initialization procedure status: 0
Max: Upstream rate = 1120 Kbps, Downstream rate = 13544 Kbps
Bearer: 0, Upstream rate = 797 Kbps, Downstream rate = 7896 Kbps



# xdslcmd info --pbParams
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 0
Last initialization procedure status: 0
Max: Upstream rate = 1120 Kbps, Downstream rate = 13592 Kbps
Bearer: 0, Upstream rate = 797 Kbps, Downstream rate = 7896 Kbps

Discovery Phase (Initial) Band Plan
US: (7,32) (871,1205) (1972,2782)
DS: (33,859) (1216,1961) (2793,3959)
Medley Phase (Final) Band Plan
US: (7,32)
DS: (33,856)
VDSL Port Details Upstream Downst
ream
Attainable Net Data Rate: 1120 kbps 13592 kbps
Actual Aggregate Tx Power: 10.5 dBm 10.6 dBm
================================================================================
====
VDSL Band Status U0 U1 U2
U3 U4 D1 D2 D3
Line Attenuation(dB): 17.5 N/A N/A N/A N/A 32.5 N/A
N/A
Signal Attenuation(dB): 17.5 N/A N/A N/A N/A 54.3 N/A
N/A
SNR Margin(dB): 15.8 N/A N/A N/A N/A 11.3
N/A N/A
TX Power(dBm): 10.5 N/A N/A N/A N/A 10.6
N/A N/A
#
ATP>sh


BusyBox v1.9.1 (2014-01-21 16:44:38 CST) built-in shell (ash)
Enter 'help' for a list of built-in commands.

# xdslcmd info --stats
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 0
Last initialization procedure status: 0
Max: Upstream rate = 1120 Kbps, Downstream rate = 13544 Kbps
Bearer: 0, Upstream rate = 797 Kbps, Downstream rate = 7896 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): 11.2 15.7
Attn(dB): 32.5 0.0
Pwr(dBm): 10.6 10.5
VDSL2 framing
Bearer 0
MSGc: 102 26
B: 31 31
M: 1 1
T: 64 34
R: 10 0
S: 0.1280 1.2427
L: 2624 206
D: 253 1
I: 42 32
N: 42 32
Counters
Bearer 0
OHF: 1717162 417874
OHFErr: 8 0
RS: 659359610 3768192
RSCorr: 21345 0
RSUnCorr: 153 0

Bearer 0
HEC: 25 0
OCD: 7 0
LCD: 7 0
Total Cells: 320451585 0
Data Cells: 11554537 0
Drop Cells: 0
Bit Errors: 0 0

ES: 6 0
SES: 0 0
UAS: 26 26
AS: 21192

Bearer 0
INP: 3.50 0.00
INPRein: 0.00 0.00
delay: 8 0
PER: 12.34 10.60
OR: 70.01 24.14
AgR: 7965.83 820.79

Bitswap: 16490/16493 0/0

Total time = 5 hours 53 min 38 sec
FEC: 21345 0
CRC: 8 0
ES: 6 0
SES: 0 0
UAS: 26 26
LOS: 0 0
LOF: 0 0
LOM: 0 0
Latest 15 minutes time = 8 min 38 sec
FEC: 396 0
CRC: 2 0
ES: 1 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: 723 0
CRC: 1 0
ES: 1 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Latest 1 day time = 5 hours 53 min 38 sec
FEC: 21345 0
CRC: 8 0
ES: 6 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 = 5 hours 53 min 11 sec
FEC: 21345 0
CRC: 8 0
ES: 6 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
#
ATP>

Edited by deleted (Thu 27-Nov-14 11:54:31)

In reply to a post by ron3003:

Max: Upstream rate = 1120 Kbps, Downstream rate = 13544 Kbps
Bearer: 0, Upstream rate = 797 Kbps, Downstream rate = 7896 Kbps


Discovery Phase (Initial) Band Plan
US: (7,32) (871,1205) (1972,2782)
DS: (33,859) (1216,1961) (2793,3959)
Medley Phase (Final) Band Plan
US: (7,32)
DS: (33,856)
VDSL Port Details Upstream Downst
ream
Attainable Net Data Rate: 1120 kbps 13592 kbps
Actual Aggregate Tx Power: 10.5 dBm 10.6 dBm
================================================================================
====
VDSL Band Status U0 U1 U2
U3 U4 D1 D2 D3
Line Attenuation(dB): 17.5 N/A N/A N/A N/A 32.5 N/A
N/A
Signal Attenuation(dB): 17.5 N/A N/A N/A N/A 54.3 N/A
N/A
SNR Margin(dB): 15.8 N/A N/A N/A N/A 11.3
N/A N/A
TX Power(dBm): 10.5 N/A N/A N/A N/A 10.6
N/A N/A

The problem is you only have one band upstream and one band downstream possibly due to attenuation by line length and maybe aluminium cable and line faults.

You should get the engineer to try additional pairs to find the best.

Is your phone line noisy?

Edited by deleted (Thu 27-Nov-14 12:05:48)

Just tried 17070, there's a bit of a hum and very faint crackle, never noticed it before.

Yeah, should be silent. You need a real engineer.

I'll caution this answer by stating that I haven't had the opportunity to study the statistics of a vectored line, so any artifact seen in the data could be caused by the trial going on.

First, as BatBoy mentions, you are limited in the frequencies you can use - which is indeed a sign of a long line and a high attenuation value. Your attenuation value suggests your sync speed is in the right ballpark - somewhere around 10Mbps would be kinda right (with a large margin plus or minus)

Second: That 500m from the DP is probably the main reason for a discrepancy from the estimates. Without knowledge of actual speeds, the estimator (I believe) assumes a more normal length of drop line (which would be 20m).

Third: Your current SNRM values are high, as a sync ought to target 6dB. The standard explanations would be that a noise source has disappeared since your last sync, or that you have been banded by DLM, with limited speeds. In the second case, though, I'd expect to see speeds a little closer to round whole numbers - and 7896 seems not such a number. But it could be something with vectoring.

Fourth: DLM has intervened with your line, as you have a non-zero "INP" value (set to 3.5) and a "delay" value greater than 1 (8ms). The "delay" value is standard for DLM, but the "INP" value of 3.50 is not - I don't think I've ever seen it set to a non-integer before ... suggesting that we are seeing something related to the vectoring trial.

The DLM intervention means that FEC and interleaving are turned on, and we can see some level of FEC corrections happening, and not much evidence of errors that FEC couldn't fix - you have an ES count of 6, and a CRC count of 8; if that continues, you would be well below the threshold to get DLM to reduce intervention - if BT manages to turn DLM back on again.

Fifth: The modem is using a quarter of your bandwidth to carry FEC overheads (10 bytes out of every 42). That is a fairly high amount, presumably caused by the "INP" value of 3.5

If you get rid of the crackle, then this overhead may well be unnecessary.

Sixth: Normally, once DLM has intervened, and the HG612 reports data, it tends to estimate a "max attainable speed" that is too high. Getting DLM to de-intervene would normally only restore speeds half way back to that "max attainable", which would then also lower to a realistic value.

However, when we see that, we also see the modem trying to synchronise at 6DB margin, while yours is higher.

In your case, it is hard to say whether removal of DLM would get your speed back to 11Mbps, or only back to 9Mbps. The impact of vectoring is an unknown here.

Is it really vectoring? I thought the trials were in Essex or Hertfordshire.

Second: That 500m from the DP is probably the main reason for a discrepancy from the estimates. Without knowledge of actual speeds, the estimator (I believe) assumes a more normal length of drop line (which would be 20m).

Spot on Wombat.

If DLM is actually currently removed would it do any harm to re-sync the modem now, I've always been wary in the past of upsetting the system?
Could the problem have been the ECI modem previously in use? As soon as I changed it to the Huawei (same as the cab) my max attainable on the Bt wholesale speedtest diagnostics increased from 6.4 to 7.46Mbps.
Engineer was very specific that there was vectoring on this cab and the only other one on the exchange that was also enabled for FTTC at the time. He also remarked that there was a trial going on in Boston Lincs too.

Edited by deleted (Thu 27-Nov-14 20:06:31)

Leave it a few days and let the magical dlm do its thing.

Normally, we don't have to be quite so timid with the modem as in ADSL days; this version of DLM seems to cope rather better in the face of "manual" disconnections. I don't think I've ever triggered DLM in this way.

However, with an abundance of caution, best practice would appear to be this:
1. From the router GUI, disconnect the PPPoE session to the ISP (optional)
2. Power down the modem by turning power off. Do not disconnect from phone line first - the modem should be able to give a "dying gasp" to the DSLAM, to let it know *you* caused the problem - though we have to assume that the DSLAM records this.
3. Leave power off for 30 minutes. This makes sure the DSLAM gets at least one 15 minute-long statistics period where no attempt to sync was made - which gives DLM another opportunity to notice.
4. Plug modem into line, if it was removed.
5. Turn on modem
6.Start PPPoE session in router, if it was stopped in step 1.

I'll leave it for now, Black Friday probably not the right day to cut off the family internet