Hey MrSaffron,
Thanks for your reply.
I understand what your saying, hoping up have both hg612 and Fritz!box 3390 stats as comparison.
The problem is that vdsl in the BTw implementation can't achieve the lengths that the standard spec would lead you to believe due to the frequency interference restrictions ofcom have imposed to protect adsl from the exchange.
Basically it's back to trial and error, order fttc if you can, if it doesn't work, just cancel and revert to adsl?
Surely the "system" can be more accurate than this?
Cheers,
flipdee

Short of carrying our RF sweeps to find out what sources of long wave and short wave radio are in an area as well as adjusting estimates over time as take-up increases you have a very moveable feast to manage.

The ANFP rules mean its not the same as the rest of the world, but how many real examples have you found of people with VDSL2 running on lines greater than 3km anywhere?

Alright!
So my friend's Sky Fibre Broadband was activated today, and much to my surprise, it's performing much better than expected.
Sadly my Fritz!box 3390 hasn't arrived yet but I checked out sync and speeds using the Sky Hub and my trusty Huawei HG612 for curiosity.

Sky Hub at master socket in house:
Modem Status Connected
Traffic Type:PTM
Line Rate - Upstream (Kbps):1316
Line Rate - Downstream (Kbps):9896

HG612 (last hacked hardware blob - not very latest) at Master socket also.
DSLAM/MSAN type: IFTN:0xb203 / v0xb203
DSL mode: VDSL2
Status: Showtime
Uptime: 57 sec

Downstream Upstream
Attenuation (dB):
Connection speed (kbps): 8077 1249
SNR margin (dB): 6.0 6.8
Power (dBm): 6.7 10.5
Interleave depth: 1 1
INP: 0 0

RSCorr/RS (%):
RSUnCorr/RS (%): 0 0.0000
ES/hour: 0.55 0

Then I tried the HG612 at the extreme of the site, as far as you can go in order to shorten the cable route.( by approximately 130m )

DSLAM/MSAN type: IFTN:0xb203 / v0xb203
DSL mode: VDSL2
Status: Showtime
Uptime: 0 sec

Downstream Upstream
Attenuation (dB):
Connection speed (kbps): 10712 1217
SNR margin (dB): 0.0 6.1
Power (dBm): 7.8 10.5
Interleave depth: 1 1
INP: 0 0

RSCorr/RS (%):
RSUnCorr/RS (%): 0 0
ES/hour: 4.45 0

Then in order to quickly get them back up and running again (was getting a bit late in the day). I extended the master socket via a somewhat unknown quantity of cable to a secondary socket.
This slowed things down to about 7.5 Mbps DS and 1.19 Mbps US.
Maxed out download didn't kill latency however maxed out upload would consistenly force pingtimes into 1000's and packet loss unti the throughput stops.
I suppose DLM will sort this one out.
These speeds would lead me to believe the cable routing isn't quite as I first thought, although it would be very interesting to see what the Fritz!box 3390 loop length estimate has to say.
I spent most of my morning fighting with the old DMT-UX on ubuntu 13.04 to no avail.
Can anyone recommend a distro/version combo that might actually allow DMT-UX to compile without standing on your head and touching your nose over those dammed dependancies?
Maybe the DMT-UX line length estimate isn't quite the holy grail so might not be worth the hassle!
cheers,
flipdee

It's quite possible with that amount of messing about on Day 1 that the DLM will band it at a lower speed tomorrow or even overnight. If he's lucky, it will just thump a fair degree of interleaving on.

DLM really is a nasty piece of work.
Lets hope it doesn't penalise them too much, really wanted to see what 130m less cable was going to do for the speed so had to bite the bullet on the messing about sadly.

At least I think i've convinced them to leave the router switched on 24/7 (some people are quite fond of the must switch everything off at plug approach!)

If it does do that, it won't be DLM's fault. It should have been left to its own devices for a couple of days to see what DLM made of it with no interruption.

I may be over-pessimistic, lets hope so .