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

Re: Poor FTTC - Stats included please look

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.

Re: Poor FTTC - Stats included please look

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).

Re: Poor FTTC - Stats included please look

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.

Re: Poor FTTC - Stats included please look

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.