Most engineers ever involved? DSL speed issues progressed to line disconnection - Still not solved!

[#1]

This tale of woe starts as most do - occasional drops in speed, followed by a disconnection, followed by complete lack of service.

We do have a long-line here, but most of it is uncontended - so there is very little crosstalk. Prior to the issues, we were getting reliable service at around 2.2Mbits/s.

On calling Plusnet, the tired but helpful person on the end of the line suggested that we should move the SNRM up to 9. I agreed, at which point the line dropped and did not recover. So an Engineer Visit was arranged. Followed by an innumerable succession of engineer visits.

So far, I believe we have had:

A new master socket - one of the shiny NTE 5C with the integrated VDSL faceplate! Made no positive difference.

Someone resetting the stats on the DSL linecard (which, predictably, resulted in almost constant line-drops)

Increase of SNRM to 9

500m of line replaced (on our property - some visible tree damage, which was cut back as we were notified). Engineer while doing this stated that the line was "acceptable quality" until they plugged into the house test socket at which point it was not. Well... Thanks?

Someone switching pairs between the linecard and CAB

Another 20m of line replaced. No difference.

Someone fiddling round at the exchange cabling

Escalation to the "multiple problem team (?)" in Openreach - which meant a day of them doing nothing before sending the call back to plusnet to book an engineer.

We now have an engineer booked for Friday (morning, apparently, although this doesn't seem to guide when or if they will arrive)

When I don't call Plusnet - *nothing* is ever progressed. Despite having two open tickets (one for BB, one for voice) which are allegedly being "worked on". We get *no* communication in terms of updates on BT, no calls from BT, unless it's a physical visit. There isn't ever an attempt to do an end to end test.

The last one was classy - We had a "Diagnosis code: T080 Description: Fault - Unbalanced Cable". Which was "fixed" by: "Clear Code: 81.7 Clear Message: Pair Changed from MDF-PCP". Yay - no unbalanced line, no reported fault in the faultfinder, job done. Apart from... The pair appears to not actually be connected to our line. .... ....

We are both getting sick of spending £20 / month on mobile broadband - which provides BETTER service than Plusnet IN ADDITION to both line rental and Plusnet charges.

Please can someone help escalate this? We would like to remain with Plusnet, but this level of support is not acceptable.

[#2]

Hi @Dibblah,

Thank you for getting in touch. I'm very sorry to hear of the poor experience that you've had in regards to this fault and the number of engineer visits that you've had.

I'm just looking into this for you now and will provide an update via the open fault ticket on your account.

[#3]

So, again BT does "something". Engineer visits house because they've actually managed to mislay our pair on the last engineer call (surprise!).

They then apparently re-pulled the multi-pair connection from the Exchange to the underground junction box near the exchange.

Engineer calls to say "right, you have a dial tone, job done, I'm away". I ask him to revisit the property to see if the actual original issue that's been hanging around for *months* has been fixed. He then went off to 'talk to his boss' to see if that's possible.

So, in the background the CM has synched. At 288kbits/second.... With a negotiated SNRM of 6.

I dearly hope that this is because the linecard needs stats resetting. I absolutely do not want another engineer involved.

In addition, Openreach is apparently transitioning our area between service centres. Which means (contrary to the statement:

"our supplier's multiple repeats case management team which should ensure that the engineer is given the full history of the fault and the actions of the previous engineers before they arrive at your property."

... that they have NO access to the prior fault tickets or information on work carried out.

Please. Can we have "broadband"? This line was delivering 2.2Mbits/s CONSISTENTLY for around 2 weeks before these issues started. Now we're at 1/10th of that.

It would be great to feel that we are being listened to and things are changing so this doesn't happen to another customer. I know, it's unlikely, but... Please. Help.

 Note that below is directly after a DSL modem reset - and after 2 hours to allow the line to "stabilise".

Uptime:	0 days, 0:00:56
DSL Type:	ITU-T G.992.5
Bandwidth (Up/Down) [kbps/kbps]:	446 / 283
Data Transferred (Sent/Received) [kB/kB]:	178.00 / 143.88
Output Power (Up/Down) [dBm]:	12.4 / 16.4
Line Attenuation (Up/Down) [dB]:	40.9 / 68.0
SN Margin (Up/Down) [dB]:	8.5 / 8.0

[#4]

So, after calling the "very busy" (30 minute wait) callcentre at Plusnet, I was told that "due to the work on the line, it needed reset". Fine. I was expecting that the DSLAM had negotiated down. I was told to reset the DSL modem after AT LEAST (and very definitely not less than) 4 hours, which brought it just after the Plusnet callcentre closes. Odd coincidence there.

So, the DSL connection has now synched at.... 283kbits/s. Exactly the same as before the reboot, the call to plusnet, etc.

The engineer did *not* come back to the house to check his work, they did *not* have any information on the history of this fault. Very tired of the runaround. Very tired of chasing Every. Single. Time. Can someone please help - take this and just get the bloody thing (which we're paying for!) fixed.

Cheers,

Allan.

[#5]

Hi,

A warm welcome to the forum.  In answer to your question, I once had 18 engineer visits over a period of 6 months before BT Openreach finally sorted out their shoddy infrastructure.  What takes the time is the poor quality of information returned to ISPs and the time it takes for BTOR to respond to "fix rejected" reports.

68dB attenuation (4.9km from the exchange) puts you at the very extreme of ADSL viability.  Speed checkers would suggest that a synch speed of 1.6mbps would be optimistic ASSUMING that the wires are copper ... and not aluminium.  If they are aluminium (or a mixture) expect less!

Poor line balance is going to be very unhelpful.  Elevating the SNRM will make the line slower ... and at this length there is not much room for flexibility.

It is uncommon to have both voice and broadband issues open on a line at the same time, because whilst there is a voice issue on a line, there is zero merit chasing broadband issues!

Broadband is not going to work well if the "phone" line is not working properly.

Please perform a quiet line test - dial 17070 select option 2 using a corded phone plugged into the test socket behind the face plate of the master socket. It should be silent. A noisy phone line (or no dial tone) will have a marked adverse impact on the performance of broadband.

If the line is noisy or there is no dial tone, then a PHONE LINE fault needs to be raised with your phone provider. If this is PlusNet, you can report a fault on line using the button below.  From the Q&A list, choose the one which matches the problem, 'open' the 'section' and click the trouble-shooter link.  NB: If you receive a failure message (rather than a log-in prompt) then log-in to the user portal in a different browser tab and attempt to use the trouble-shooter again.

• Phone Faults

@Gandalf - what does the line balance now look like please?  What is leading on this issue at the moment - voice or broadband?  Do tests, engineer reports or infrastructure information indicate if aluminium is involved here?  Is this service running ADLS or ADSL2?  If the latter is there merit in trying ADSL1 over 21CN?

[#6]

Hi Allan.

I'm sorry to read about your experience.

Our tests are showing a potential fault still present on the phone line, what's called an Earth Contact.

This would likely be causing your very slow speeds...

xDSL Status Test Summary
Sync Status:		Circuit In Sync
General Information
NTE Status:		NTE Power Status:	PowerOn	Bypass Status:

	Upstream DSL Link Information	Downstream DSL Link Information
Loop Loss:	40.7	67.5
SNR Margin:	7.1	7.1
Errored Seconds:	0	8
HEC Errors:	0
Cell Count:	0	0
Speed:	446	284

Maximum Stable Rate (KBPS):	864	Fault Threshold Rate (KBPS):	691
Mean Time Between Retrains (Seconds):	550	Mean Time Between Errors Upstream (Seconds):	3187
Indicative Line Quality:	R	Mean Time Between Errors Downstream (Seconds):	86400

And intermittent connection we're seeing...

I've moved ticket 169866124 (Closing the newer ticket) into my own workflow so I can take ownership of this for you.

I'll update you when we have more info.

Cheers.

Anoush

[#7]

Thanks, Townman! I believe we are on copper for the majority of the line. The frustrating bit here is - before the line down and "fix" we were for two weeks or so consistently getting 2.2mbits/s connection.

I don't think it was a line balance issue, one of the pair was completely disconnected - no phone service, no ring voltage.

And now, after reasonable voice yesterday, the line is audibly crackly. How do we get this fix rejected quickly?

Since we already have 3 calls "open" on this - the last one I've just checked the log for and the engineer optimistically REDUCED our SNR from 12 (which is a bit over the top probably) to 6 (which... Well. Wouldn't have been my first action) - is there any point in me calling the call centre?

The CM negotiates ADSL2+, stats at the end. I have OpenWRT, so I can set it to negotiate ADSL, but I doubt that will make much different with an audible fault.

Really, really tired of this. I *know* we are a long way from the exchange and had my expectations at around 1.2Mbits/s. But .288 is... Not useful. Better off with 4G.

Thanks for your help!

Status: UP
Line State: showtime_tc_sync [0x801]
Line Mode: G.992.5 (ADSL2+)
Annex: A
Profile:
Data Rate: 284 Kb/s / 446 Kb/s
Max. Attainable Data Rate (ATTNDR): 624 Kb/s / 578 Kb/s
Latency: 7.50 ms / 6.75 ms
Line Attenuation (LATN): 67.5 dB / 40.7 dB
Signal Attenuation (SATN): 60.6 dB / 40.3 dB
Noise Margin (SNR): 7.6 dB / 7.4 dB
Aggregate Transmit Power(ACTATP): 15.4 dB / 12.3 dB
Forward Error Correction Seconds (FECS): 5093049 / 125890
Errored seconds (ES): 5683 / 10295
Severely Errored Seconds (SES): 3 / 20
Loss of Signal Seconds (LOSS): 0 / 6
Unavailable Seconds (UAS): 349 / 349
Header Error Code Errors (HEC): 236 / 14540
Non Pre-emtive CRC errors (CRC_P): 0 / 0
Pre-emtive CRC errors (CRCP_P): 0 / 0
Line Uptime: 1h 22m 1s
ATU-C System Vendor ID: Broadcom 163.167
Power Management Mode: L0 - Synchronized

[#8]

Thank you, Gandalf.

In unrelated weather news, it rained this morning and the work yesterday was down a manhole cover.

Hope this can get looked at tomorrow, since I am at home then. Would be really great if OR could take responsibility for end-to-end tests, but I'm guessing that's cloud cuckoo land.

Thanks again!

[#9]

No problems. Unfortunately we can't ask an engineer to take ownership of a job, but I'll be happy to own this from our side providing you with more timely proactive updates and chase where needed.

[#10]

Okay, so the engineer arrived today (a day early!) and appears to have "fixed" the voice issue - the line is now not audibly crackling. However, it is still only negotiating at 288kbits/s. The "max attainable" is fluctuating wildly - I've seen up to 1.3, down to 200kbits/s.

He is apparently asking his supervisor for permission to replace the 50 pair line near the exchange. Apparently we are not the only people locally affected. No idea how long this is going to take to resolve.

Thanks for your help so far!

Status: UP
Line State: showtime_tc_sync [0x801]
Line Mode: G.992.5 (ADSL2+)
Annex: A
Profile:
Data Rate: 287 Kb/s / 446 Kb/s
Max. Attainable Data Rate (ATTNDR): 952 Kb/s / 573 Kb/s
Latency: 7.50 ms / 6.75 ms
Line Attenuation (LATN): 67.7 dB / 40.8 dB
Signal Attenuation (SATN): 60.7 dB / 40.3 dB
Noise Margin (SNR): 11 dB / 10 dB
Aggregate Transmit Power(ACTATP): 13.7 dB / 12.3 dB
Forward Error Correction Seconds (FECS): 6757131 / 3547
Errored seconds (ES): 1341 / 14460
Severely Errored Seconds (SES): 0 / 360
Loss of Signal Seconds (LOSS): 0 / 6
Unavailable Seconds (UAS): 216 / 216
Header Error Code Errors (HEC): 291 / 54069
Non Pre-emtive CRC errors (CRC_P): 0 / 0
Pre-emtive CRC errors (CRCP_P): 0 / 0
Line Uptime: 2h 7m 13s
ATU-C System Vendor ID: Broadcom 163.167
Power Management Mode: L0 - Synchronized

[#11]

Thanks for the update.

I'm glad to hear the engineer fixed the problem with your phone line and is looking into renewing the line. They've sent the fault report back to us advising the fault was cleared so it sounds like they'll be doing the extra work in the background.

I've reset the broadband settings on your line now so you should see faster speeds now, around 1450kbps.

Let me know if you have any further issues.

[#12]

Still repetitive disconnections.

Is it possible to enable interleaving at a reasonably high level to see if we can at least get a connection before Openreach fixes the underlying issue?

Cheers,

Allan.

[#13]

Setting the SNRM up to about 10 seems to get the line to stabilise a little, but not to staying up for more than 20 minutes.

Status: UP
Line State: showtime_tc_sync [0x801]
Line Mode: G.992.5 (ADSL2+)
Annex: A
Profile:
Data Rate: 928 Kb/s / 446 Kb/s
Max. Attainable Data Rate (ATTNDR): 876 Kb/s / 566 Kb/s
Latency: 8.0 ms / 6.75 ms
Line Attenuation (LATN): 66.5 dB / 40.5 dB
Signal Attenuation (SATN): 58.4 dB / 40.2 dB
Noise Margin (SNR): 10.4 dB / 9.8 dB
Aggregate Transmit Power(ACTATP): 15.1 dB / 12.3 dB
Forward Error Correction Seconds (FECS): 75187 / 181
Errored seconds (ES): 562 / 14476
Severely Errored Seconds (SES): 484 / 373
Loss of Signal Seconds (LOSS): 51 / 19
Unavailable Seconds (UAS): 1819 / 1819
Header Error Code Errors (HEC): 23101 / 54270
Non Pre-emtive CRC errors (CRC_P): 0 / 0
Pre-emtive CRC errors (CRCP_P): 0 / 0
Line Uptime: 6m 23s
ATU-C System Vendor ID: Broadcom 163.167
Power Management Mode: L0 - Synchronized

[#14]

Hi Allan.

I'm sorry to hear the connection drops/speed problems have returned.

Line tests are coming back clear now and as we don't know when or if your line will be replaced, I think the next step is raising another broadband fault and getting another engineer out there to investigate further.

I've also raised an escalation to our suppliers due to the length of time this is ongoing for.

Whilst it's unlikely to change the next course of action, they'll be able to escalate this with the local Openreach operations manager to make sure an experienced engineer is assigned to the job and investigates this thoroughly.

We should hear back within 24 hours. I'll update your ticket shortly too.

EDIT: Interleaving is already enabled and switched on I'm afraid.

[#15]

"Unfortunately our suppliers have rejected the escalation, so I've re-raised the escalation." - how in a sane and sensible world can this happen?

It's not being escalated for fun, there's still an issue!

Thanks again for your persistence!