Packet Loss when router is remotely busy

[#1]

Turned on the "Allow incoming ping requests" on the Hub Two Advanced Settings Firewall.
Graph is filling in OK now.
Thanks for your help.

[#2]

On more post and I'm off to bed.
See 

https://www.thinkbroadband.com/broadband/monitoring/quality/share/f848d870ffff649799bd9a9d2b5e414079031795

At 10:20 there is a little blip on the blue average latency and a tiny blip of red dropped packets.
This corresponded to me downloading a 512MB file.
Someone is watching HD TV at the same time so average download speed was very roughly 20Mbps and it took about 4 minutes.
As I understand it, losing a few ping packets when making the link busy is possibly to be expected (is that right..?)
The trouble is the packets that Overwatch loses under the same circumstances are not ping packets but crucial data.

[#3]

This should be a link to the trace for 4/4/2022:

https://www.thinkbroadband.com/broadband/monitoring/quality/share/13a5a63f6703b2e16a07f36b40c81cb958e66512-04-04-2022

At around 8pm we loaded up the internet with my PC downloading a large file while others were watching video and Jonathan played Overwatch, generally hammering the keyboard like mad as you do with these games. He saw what he characterised as "quite a lot" of packet loss, enough to spoil a game. From what I saw, the timing was random but the "packet loss" icons were flashing once every few seconds on average.  

On the thinkbroadband trace above, the blip in the blue average latency around 8pm, where it goes from around 20ms to around 35ms, corresponds to this busy period (The time on the axis is not very accurate, the blip appears at a different time each time I look at it!)

The small red blip at the top of the screen at the same time seems to show the problem. It must only be 1 or maybe 2% loss, but this seems to correspond with enough loss in Overwatch to spoil the game.

I hope this gives someone something to go on.

I note that the flooded BT man-hole just down the road still has water running UP OUT of it, so any connections down there are still getting a very hard time!

[#4]

Cheers for the updates and setting up the TBB graph!

In general the graphs look OK to my eye. The occasional lost packet is probably fine, but to see that happen when someone’s downloading is concerning, and I know how even a bit of packet loss can ruin a game. 

Tied in with that as your speeds are slower than expected, and the manhole is flooded, I’d say that there’s definitely a problem which needs another engineer looking into.

I was hoping the Hub Two would help, though I too wasn’t 100% confident it would solve the whole issue, but it’s opened up an avenue for these diagnostics.

Incidentally, Bob's post here > https://community.plus.net/t5/My-Router/Hub-2-speed-difference/m-p/1857798/highlight/true#M30960 may explain the difference in speed between a Hub One and Hub Two a little better than I could.

I’m out of the office now until Wednesday. I’m happy to take a closer look when I’m back, and we may end up needing to arrange that engineer. If so, I’ll escalate this to encourage a more thorough investigation it seems to try to get to the bottom of the problem.

In the meantime, try calling Openreach’s damage reporting number tomorrow > https://www.openreach.com/help-and-support/damage-health-and-safety to let them know about that flooded manhole and see if they can help as that doesn’t sound good at all.

Let me know how it goes

[#5]

Thanks for following this up Anoush.
I will try to report the damage tomorrow.
The Openreach engineer that came here the first time saw the flooded manhole. He opened it up and did some work in it and said that it had improved my connection. When I pointed out it was going to flood again he said he would report it and another team would deal with the flooding. It will do no harm to report it again though.

The Hub Two is sitting constantly at Downsync of 27.61Mbps, Upsync 5.266Mbps. These were the numbers I saw when it first connected and they have remained constant. It must be a couple of weeks now. So I think it has done its bedding in.

I'll look out for your follow-up after Wednesday.

It is a big deal for Jonathan to not be able to play Overwatch. I think that as far as he is concerned, that is pretty much the whole point of the internet! 🙂

[#6]

No problem and sounds like a plan. 

Haha yeah I don’t play Overwatch although I do want to start getting into it as a few of my friends play and say it is really good, so I can imagine Jonathan’s pain!

[#7]

I reported the flooding to Openreach:
The job reference number from our Openreach Damage Reporting Desk is SS1HFY33.

They wanted to know if the damage was dangerous.
I was tempted to tell them that it was an absolutely lethal threat, that my son had already died because of it... several times... while playing Overwatch.

They did seem to understand the problem but I got the impression that since it isn't dangerous it has been put in a queue that might be quite long.

[#8]

---

@Highside wrote:

I reported the flooding to Openreach:
The job reference number from our Openreach Damage Reporting Desk is SS1HFY33.

They wanted to know if the damage was dangerous.
I was tempted to tell them that it was an absolutely lethal threat, that my son had already died because of it... several times... while playing Overwatch.

---

Haha makes sense to me.  

---

@Highside wrote:

They did seem to understand the problem but I got the impression that since it isn't dangerous it has been put in a queue that might be quite long.

If you don’t get any luck over the next couple of days, I can raise a damage report our side with Openreach, which may possibly hold more weight.  

[#9]

Heya, really sorry for the delay. Somehow this slipped off my radar. How did the damage report go?

If you’re/Jonathan’s still having issues, we can raise what’s known as a “damage report underground” and/or arrange a broadband engineer from Openreach.

I’m out of the office now until Wednesday next week but my colleagues should be able to help while I’m away. 

Cheers,

Anoush

[#10]

Thanks for following up.

See yesterday at 8PM.

https://www.thinkbroadband.com/broadband/monitoring/quality/share/3780a2485cc1823da2144367f1bd3d63b514ada5-13-04-2022

Still losing lots of packets when internet is busy.

Nothing has happened in the road outside.
Nothing about our internet has changed. 

Downstream synch speed still 27.61 Mbps (slower than my guaranteed minimum speed).
Upstream sync speed still 5.266 Mbps

I would be grateful if you could progress this somehow.

[#11]

Thanks a lot for getting back to us @Highside and I'm really sorry to see that you're still having issues with your service. I've just p[assed this across to our suppliers for further investigation, though it's likely that they'll want to arrange an engineer visit. 

Please can you respond to the ticket stating your availability for an Openreach engineer appointment next week? 

[#12]

Thank you for keeping at this.
I've replied with times and dates.
I'll try to remember to update the forum with the outcome of the visit when it is scheduled.

[#13]

Thanks a lot for getting back to us, looks like our Technical Support Team have beaten me to it, and have arranged an engineer visit for tomorrow morning. Let us know how things go.  

[#14]

The engineer came.
He said that the line is fine.
He said his tests show no packet loss and that when he connects his equipment, the speed is fine too.
We insisted that there is definitely a problem and he said we need to talk to PlusNet about it, and left.

So that was disappointing!!!

Downstream sync is now 27.291 Mbps, Upstream 5.198 Mbps. No change.

This is the monitor graph for today when he came (just after 10am). No change to packet loss. For example around 5pm.

https://www.thinkbroadband.com/broadband/monitoring/quality/share/45898c729c5401632903a44456fce4e5270903c6-19-04-2022

What now?

[#15]

Hi there and I'm sorry to see that the engineer visit didn't really lead to much. What I would recommend as the next step is that we arrange another engineer visit when you can be available and we'll request a senior engineer to take a look at the issue as it sounds like it may be due to a faulty port at the exchange.