Openreach engineer finds no fault. PN want to send another.

[#1]

Good morning @LaurenB @TheMightyAJ @jab1 @Anonymous and @198kHz 

Well, the mystery is solved - although not yet resolved.

An Openreach engineer called this morning to say that there is "a throughput issue at the [our town] header", which is affecting many (but not all) fibre customers of various service providers. They confirmed it started when our issue became apparent, last Wednesday.

So, we have had more than a week of difficulties using the internet and extra expense buying unlimited data plans for our mobiles to use as hotspots and a wifi dongle to use with a PC. But, almost as significant has been the hours and hours of time and stress over this period trying to get to the bottom of the problem. I have had many, many calls with PN support staff, and posted many times in this thread. I have documented the situation with dozens of screenshots, and created a table recording how speeds and packet loss have varied.

I am very grateful to everyone who has tried to help zero in on the cause of my problem. But I am frustrated that my initial theory, that this was all being caused by a lack of capacity somewhere, and nothing to do with anything in my house, or by a fault on our line, has been borne out, despite scepticism from almost everyone. 😓

I cannot emphasise strongly enough how frustrating and stressful it is to have to jump through so many hoops in order to try and get to a solution/explanation. I was absolutely certain that a 2nd engineer visit today would be a waste of time (and threat to my health), but I was told that it had to happen before the issue could be escalated. I understand that this process may sometimes discover something a 1st visit didn't, but in my case simple deduction should have proved to any reasonable person that it would not be relevant.

So I urge you all here, and will also emphasise to the PN telephone support team - PLEASE remember, next time someone reports the same situation as mine (ie very fast speeds before about 8am, dropping to VERY slow ones in the evenings), to acknowledge that there may be a local throughput (ie capacity) issue which doesn't show up in line tests.

[#2]

Hi @MVH_Somerset thanks for getting back to us.

I'm really sorry to see the problems you've had. 

I'm glad to see the engineer's identified the issue, though not only are our tests not showing a capacity issue, I've checked our suppliers capacity report for the equipment (also known as S-VLAN) at the exchange and there's no reported issues. 

Appreciate the frustration but I can't see how we can acknowledge a capacity issue when our tests and supplier reports don't show this. Realistically all we can do if tests pass but there is an issue, is progress through an engineer investigation.

Unfortunately the engineer's report from today doesn't give much away as they've just suggested in their notes to us that they couldn't find an issue, but based on what you've said the engineer's told you, I've got in touch with our suppliers complex faults and quality assurance team and they've confirmed the exchange equipment isn't at capacity. 

It's very possible the engineer may have been referring to the cabinet rather than the exchange though this "a throughput issue at the [our town] header" seems to suggest an issue at the headend exchange which our suppliers aren't aware of. 

Also, looking at the last 30 days of your connection, the drops below don't suggest a capacity issue at all  Over-utilised exchange equipment causes slow speeds at peak times which I know you're experiencing, but not line drops. 

As the engineer's closed the job based on the ongoing issues they believe to be present and worked on in the background, we won't receive any further updates or information from the engineers to be able to relay onto you.

I think given the engineer's findings and your vulnerability, let's see how it goes and if your service improves in due course, though potentially if you're still having issues, we may have to arrange another engineer.

[#3]

Hi @MVH_Somerset

I've just come off a call with a couple of managers from our suppliers complex faults & quality assurance team and they've done some digging into this and they can indeed see there is a capacity issue on the S-VLAN at the exchange. 

They're arranging to move you across to less utilised kit, but it can take a couple of days. 

Fingers crossed by next week your speed will be steady. Could you let me know how it goes?

[#4]

Thank you for pursuing this Anoush, and for your last post. I must admit that the previous one was not what I wanted to hear!

I will indeed post again once our connection is finally back to normal. 😊

[#5]

No problem, I admit when I was typing up my first post it absolutely wasn’t what I wanted to say either, but credit where credit is due, our suppliers complex faults guys continued to scratch their heads at the issue after my initial conversation and then followed up with me. 

I’m still a little puzzled by the drops in your connection but once the congestion issue is hopefully fixed, we should have a clearer picture and we’ll see if the drops are still happening and take things from there.

[#6]

though not only are our tests not showing a capacity issue, I've checked our suppliers capacity report for the equipment (also known as S-VLAN) at the exchange and there's no reported issues. 

Doesn't say a lot for ORs first line diagnostic systems if they don't report when there really is a capacity problem.

. I’m still a little puzzled by the drops in your connection but once the congestion issue is hopefully fixed, we should have a clearer picture and we’ll see if the drops are still happening and take things from there. 

Are the drops due to DSL losing sync or just PPPoE drops ? AFAIK the radius doesn't know the difference

Is suppose its just possible that a period of packet loss could result in a loss of LCP echo packets sufficient to timeout the PPPoE

[#7]

@MisterW wrote:

though not only are our tests not showing a capacity issue, I've checked our suppliers capacity report for the equipment (also known as S-VLAN) at the exchange and there's no reported issues. 

Doesn't say a lot for ORs first line diagnostic systems if they don't report when there really is a capacity problem.

It's more Wholesale and upon further investigation the capacity report we've checked was from 21st December which as far as I'm aware predated the issues as @MVH_Somerset said the problems started on the 22nd.

We normally receive an updated capacity report every week though we haven't yet as there seems to be a delay due to the festive season. It's very possible that the issue would've flagged on this week's report if we received it.

When contacting the complex faults team while an adviser couldn't see an issue at first, they did only 2 hours later after doing a lot of analysing and talking amongst themselves. 

Appreciate that overall this hasn't made for a good experience, and we could've got in touch with the complex faults folk a little sooner, though I think the drops may have been clouding the issue for us. 

@MisterW wrote:

. I’m still a little puzzled by the drops in your connection but once the congestion issue is hopefully fixed, we should have a clearer picture and we’ll see if the drops are still happening and take things from there. 

Are the drops due to DSL losing sync or just PPPoE drops ? AFAIK the radius doesn't know the difference

Is suppose its just possible that a period of packet loss could result in a loss of LCP echo packets sufficient to timeout the PPPoE

Ah good shout. Hard to tell. Our tests aren't showing any retrains or errors, so they could very well be PPP drops. 

@MVH_Somerset I've just received a message from the manager of our suppliers complex faults team to confirm that the problem should now be resolved. Could you let us know how things go tonight and over the weekend?

[#8]

Hi @Gandalf , @Anoush  and @MisterW

Thank you for your continued input.

I've just run a test (screenshot attached) which shows a d/l speed of 68Mbps, so it appears that BT have indeed fixed my issue, which is great. 😊

I do however have a serious concern. Bearing in mind that I had what appears to be an identical issue 18 months ago which lasted a fortnight, and then disappeared, I assume there is a possibility that this will happen again at some point. (At that time there was no acknowledgment that a cause had been identified from anyone - apart from an informal phone call from an Openreach engineer.)

My question to you is, if this should happen again, how do I avoid the stress, massive waste of time, and significant expense which I have endured for the last nine days? Would there be any way to convince PN to talk to the complex faults team a lot sooner (if, of course, the symptoms of the problem were identical to the ones I have had twice now)?

As I said before, everyone here and on the phone has been friendly and tried to be helpful, for which I'm grateful. 😎  But it has been such a struggle to reach a satisfactory conclusion; and I really hope that lessons can be learnt which will prevent me, or anyone else, having to go through such a painfully slow process in the future. I hope you can appreciate how dispiriting it is to have almost every suggestion you make discounted as being irrelevant or repeatedly being told that "we can't do anything without another engineer visit". In particular, the Tech Support Team on the phone seem to have very limited authority/autonomy, and if the remote tests they run don't find a fault then requesting up to three OR engineer visits seems to be the only option they can offer. 😞

[#9]

Hi @MVH_Somerset

Excellent, I'm glad to see your speeds are back to normal now. ‌‌If you experience a problem again and the symptoms are identical, feel free to create a new topic here on our forums and reference this one and we'll be happy to have a chat with the complex faults team. 

I'm really sorry again for the stress and pain you've gone through.

I'm keen to use the experience you've had to try to make our handling of this type of issue better, so I've emailed a colleague within our Business Improvements team in an effort to understand if this is a one-off instance we should feedback on or if we'd need to look at the process that agents follow.

If there's ever anything else you'd need help with, feel free to post back to let us know.

[#10]

Thank you very much @Anoush, I really appreciate your positive response.

Before I retired I did have experience and training in Continuous Improvement (as we called it in my organisation), and I'm pleased to hear you recognise that there is the potential for re-examining the procedures/processes which your colleagues follow. 😊

[#11]

No problem @MVH_Somerset 

Yup, they're often called Continuous Improvements over here too.

[#12]

Hi @MVH_Somerset 

Just to follow up. How has your speed been over the weekend? 

[#13]

Thanks again for your continuing interest in our case 😊

It's been perfect. Just did BT Wholesale test and got 68 d/l and 21 u/p 😎

BTW, "my" Openreach engineer has also been incredibly good at giving me updates. During the last call we had, after the fault was resolved, he confirmed that "a line card needed swapping out".

[#14]

Thanks for getting back to me @MVH_Somerset 

Ah awesome, that's really good to see! 

If you'd like to pass on your thanks to the engineer, I'd recommend filling out the form Here to let Openreach know.