Maximum acceptable sync loss

Hello dudes,

So the installation of my second line seems to have played hell with the primary. From initially having a max attainable back in 2013 of over 98Mb it settled at 64-67Mb up until this week when the second line into the property was brought back into service.

It's now banded at 55Mb, and errors continue to merrily increment even at that level, stats below.

So it's lost over 18% of sync and had at least 3 DLM interventions, the last of which was banding. I don't know the exact details of that as I don't monitor obsessively.

It's not yet outside the 'clean' estimate range, which goes down to 54.3Mb. Would my provider be able to raise a case with Openreach?

Max: Upstream rate = 20132 Kbps, Downstream rate = 64916 Kbps
Bearer: 0, Upstream rate = 20000 Kbps, Downstream rate = 54999 Kbps
Bearer: 1, Upstream rate = 0 Kbps, Downstream rate = 0 Kbps

Down Up
SNR (dB): 9.3 6.0
Attn(dB): 17.0 0.0
Pwr(dBm): 14.0 7.2

Total time = 1 days 7 hours 38 min 10 sec
FEC: 84634064 1078
CRC: 51294 171
ES: 12841 163
SES: 157 0
UAS: 138 107
LOS: 3 0
LOF: 27 0
LOM: 0 0

Since Link time = 13 hours 45 min 23 sec
FEC: 5619929 122
CRC: 419 20
ES: 351 20
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0

Do you a landline phone? Dial 17070 and select option 2, the line should be quiet.

In reply to a post by WilliamGrimsley:

Do you a landline phone? Dial 17070 and select option 2, the line should be quiet.

It's not a WLR line.

what's the upper end of your clean range estimate? 80mbps?

I assume if you disconnect the new line the error's plummet on the first line?

I got no idea what openreach would do, they now have added a new figure on the BT wholesale checker which is below the 20 percentile used for the clean low range, and kitz's isp are using that to stop her fault been escalated. If your isp (or openreach) does the same then you may hit the same brick wall. It seems in return for openreach and CPs offering to refund people for low performance the goal posts for determining if a line is under performing have been moved.

I would probably raise a fault and see what happens. There is ways to alleviate the threat of fee's.

In reply to a post by fishpan:

what's the upper end of your clean range estimate? 80mbps?

73.4. The range is 54.3-73.4.

Between distance from cabinet and worst case scenario crosstalk 80Mb is impossible without vectoring

Scary what crosstalk can do.

From: http://www.speedtest.net/result/6203225557.png
To: http://www.speedtest.net/result/6203225557.png

what dioes 2nd line sync at?

Both the same link for me?

All i see is a 102mb Down and 24mb up Talktalk speedtest for the 9/4/2017 on both

In reply to a post by Ignitionnet:

Scary what crosstalk can do.

From: http://www.speedtest.net/result/6203225557.png
To: http://www.speedtest.net/result/6203225557.png

Doh.

http://www.speedtest.net/result/3219692669.png should be the first one.

It seems you have had a change of ISP, so how do you know the difference is just down to Crosstalk?

In reply to a post by jaydub:

It seems you have had a change of ISP, so how do you know the difference is just down to Crosstalk?

Changing ISP doesn't change sync speeds. I'm on the same DSLAM as before via the same cabling.

Post deleted by RobertoS

Hang on! What products are you on? You have two speed tests there at well over 100Mbps down and over 20Mbps up. So where do cross-talk and sync speeds come into it?

Edited by RobertoS (Mon 10-Apr-17 15:47:26)

In reply to a post by RobertoS:

Hang on! What products are you on? You have two speed tests there at well over 100Mbps down and over 20Mbps up. So where do cross-talk and sync speeds come into it?

2 x FTTC lines, Bob.

Load-balancing or bonding then.

In your OP you said the problem arose "when the second line into the property was brought back into service". Were things fine the first time? Were the two lines independent at that stage, or set up as now?

What stats does the second line have, and are both with TT?

Typically when we talk about crosstalk it is just a case of your line running close to another for a while, but in this case they could be close together all the way from the cabinet, and certainly from the DP to you. Also normally cross-talk doesn't seem to cause banding, just reduced sync.

I'd be thinking more in terms of the reconnected line being incorrectly connected somewhere/somehow and is causing high error rates on the first one. Something daft perhaps like a dodgy connector or deteriorated insulation.

It could even be the reason for your considerable deterioration since 2013, made much worse now by actually carrying a service. What happens to error rates if you shut it down?

So prior to the issue causing the banding the primary line had dropped from an attainable of over 98Mb to 64Mb. It had been running smoothly at 67Mb, however.

I don't blame standard crosstalk for the banding.

The second line went into play and the banding happened after that, so it seems reasonable to put two and two together. I can see DLM interventions between 6am and 8am Wednesday, Thursday, Friday and Saturday.

They both run on the same 2 pair cable into the property. I would presume that the pairs are separated at the DP.

The second line is BT not TT, however I will repeat my earlier response that the ISP is irrelevant as the issues are on the xDSL side.

The primary has had FTTC non-stop since 2013. The secondary was ceased, and I do not know for sure what was done with it.

I suspect when the second pair was brought back into service something was done that impacted the first pair.

I shouldn't really have mentioned crosstalk, it's clouded the issue. The banding is almost certainly not caused by crosstalk.

Either way nothing is going to be done with this unless the primary drops further. I could indeed have an SFI visit, but risk no fault being found and a charge. I don't really feel the need to waste the cash.

It's running within estimate. I must admit I'm confused that DLM went straight to banding rather than trying to use interleave to control errors, but it is what it is and I guess the configurations can prefer using G.inp and banding.

EDIT: Just FYI the second line is a bit longer than the first, and it shows, however it shows fewer errors despite having a lower SNR margin.

# xdslcmd info --show
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 0
Last initialization procedure status: 0
Max: Upstream rate = 20090 Kbps, Downstream rate = 64204 Kbps
Bearer: 0, Upstream rate = 20000 Kbps, Downstream rate = 54999 Kbps

# xdslcmd info --show
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 0
Last initialization procedure status: 0
Max: Upstream rate = 19692 Kbps, Downstream rate = 57084 Kbps

It is what it is, and I am stuck unless it degrades further.

Edited by deleted (Mon 10-Apr-17 18:12:17)

I think I would be asking BT what their "supplier/installer" has done to wreck your existing line. I agree TalkTalk aren't likely to play particularly willingly.

Before line 2 was ceased however, was all well on both lines?

How old is the final cable run to the premises? That's the area I was pointing to in my previous post. The same sort of effect as a tree rubbing causing your drop over the years, and now the other line is active - bang!

What are the stats like on the BT line? (The stats weren't there when I started )

Edited by RobertoS (Mon 10-Apr-17 18:20:58)

In reply to a post by RobertoS:

I think I would be asking BT what their "supplier/installer" has done to wreck your existing line. I agree TalkTalk aren't likely to play particularly willingly.

Before line 2 was ceased however, was all well on both lines?

How old is the final cable run to the premises? That's the area I was pointing to in my previous post. The same sort of effect as a tree rubbing causing your drop over the years, and now the other line is active - bang!

What are the stats like on the BT line? (The stats weren't there when I started )

Before line 2 was ceased both were fine.

The cable run is less than 7 years old and all underground, via a fully ducted network,

I rebooted the modem. I think the FEC stats are spurious and can't recall what is considered an acceptable error rate by DLM.

Since Link time = 28 min 37 sec
FEC: 594639 11
CRC: 32 3
ES: 21 3
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0

Edited by deleted (Mon 10-Apr-17 19:25:51)

The joys of xDSL.

xdslcmd info --stats
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 1
Last initialization procedure status: 0
Max: Upstream rate = 22378 Kbps, Downstream rate = 65508 Kbps
Bearer: 0, Upstream rate = 20000 Kbps, Downstream rate = 48997 Kbps
Bearer: 1, Upstream rate = 0 Kbps, Downstream rate = 0 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.1 7.0
Attn(dB): 17.0 0.0
Pwr(dBm): 14.3 7.2

For the curious I found the source of the interference. I have no idea why the second line being brought back to life caused it to be picked up when it was previously fine but it is what it is.

http://forum.kitz.co.uk/index.php/topic,19667.0.html