In reply to a post by Chrysalis:

I asked for a quote to keep the dedicated dropwire but heard nothing back so gave up on it now. I was pretty shocked BT went to the expense of undoing their work just to enforce a policy.

If the drop wire only has 2 pairs, yours and your neighbours, then perhaps the answer is to order a second line, they will have to put in a new drop wire to supply it Once it's in cancel the other line..

In reply to a post by Chrysalis:

crosstalk isnt gradual, it seems most people think whenever a new FTTC line is enabled in the cabinet it adds a small affect of crosstalk to existing lines.

Whats nearer the reality is many lines may add no crosstalk at all (not close proximity) but then other lines may add a ton of crosstalk in one go as they close in the bundle.

Its complete luck what happens. Someone could order FTTC and have speeds way above estimates with no to little crosstalk all that time, or someone can be the first on a cab and have heavy crosstalk after a week.

This whole explanation is correct, but it totally invalidates your previous post (where you ask Openreach to perform random pairswaps or to test neighbouring lines to ensure that crosstalk isn't being added)

Unfortunately, when you add one FTTC line into a cable, you do cause crosstalk somewhere. Exactly where is indeed random, but it will be somewhere.

If an Openreach engineer had to check every pair combination at install time, it'd take forever. Remember that, on addition of a further line, it isn't enough to check just the remaining idle pairs. The whole set should be re-checked.

In essence you are asking an Openreach engineer to do statically what a Vectoring linecard has to do millions of times per second..

I agree.

What would be best is if the install engineer has a device that shows all current syncs and snrms on existing lines in the cabinet fed from a hub somewhere which itself gets data from the cabinet.

He puts in a line and activates it, the device sets of an alarm if one of the following happens.

another line drops and loses more than 10% sync speed in process.
another line drops and stays down.
another lines loses more than 2db margin and line was previously only on 6db (so no buffer to absorb crosstalk).

even if there is no pair swaping to fix the problem, these events can be logged as crosstalk so if affected users log a fault then openreach know right away the reason.

Edited by Chrysalis (Tue 18-Jun-13 00:35:14)

2 weeks later now 53mb down :/