cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

High Jitter and Packet Loss on EE Backhaul Nodes (Hop 4 & 10) - Impacting Real-T

sagaodyssey7928
Explorer

Hi everyone,

I am looking for some technical assistance or an escalation to a network engineer regarding persistent packet loss and severe jitter on my connection.

I’ve done extensive local troubleshooting to rule out my own equipment, but the issue clearly originates within the EE/BT network nodes.

The Problem: I am experiencing "yellow spikes" (stuttering) in real-time UDP applications (gaming). This happens even under no-load conditions with all other devices disconnected. I have tested multiple LAN adapters and cables, and even used a VPN, but the spikes persist because the loss occurs before reaching the VPN gateway.

Technical Evidence (WinMTR Analysis): I have attached my WinMTR logs below. Please note the following:

  • Hop 1 (192.168.1.254): 0% Loss and <1ms latency. My local hardware (PC/Router) is perfect.

  • Hop 4 (62.172.102.224): This is where the issues begin. I am seeing ~5% packet loss at this EE node.

  • Hop 10 (be101.lon1-eri1-g2-nc5.uk.eu): The loss increases to 10%, with latency spiking from an average of 11ms up to 128ms (Worst).

This 117ms jitter spike is what's breaking the sync in real-time applications. Since it's occurring on the EE backhaul, there is nothing I can do on my end to fix this.

My Setup:

  • Router: Smart Hub (SH31B)

  • Connection: Wired Ethernet (Cat6)

  • Troubleshooting done: Factory reset router, swapped LAN adapters (Realtek/ASIX), tested with NordVPN (no improvement).

Could a moderator or engineer please look into the stability of these specific routing nodes (62.172.102.224 and the lon1-eri1 exchange)? It appears to be a congestion or hardware fault on the backhaul.

-----------------------------------------------------------------------------------------|
| WinMTR statistics |
| Host - % | Sent | Recv | Best | Avrg | Wrst | Last |
|------------------------------------------------|------|------|------|------|------|------|
| hub.home.arpa - 0 | 1780 | 1780 | 0 | 1 | 4 | 4 |
| 172.xx.xx.xx - 0 | 1780 | 1780 | 3 | 3 | 28 | 4 |
| No response from host - 100 | 358 | 0 | 0 | 0 | 0 | 0 |
| 62.172.102.224 - 5 | 1541 | 1478 | 5 | 6 | 34 | 6 |
| 194.74.16.145 - 0 | 1779 | 1779 | 6 | 9 | 77 | 7 |
| be107.lon-thw-pb1-nc5.uk.eu - 0 | 1779 | 1779 | 5 | 7 | 53 | 7 |
| No response from host - 100 | 358 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 358 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 358 | 0 | 0 | 0 | 0 | 0 |
| be101.lon1-eri1-g2-nc5.uk.eu - 11 | 1248 | 1112 | 6 | 11 | 128 | 7 |
| No response from host - 100 | 358 | 0 | 0 | 0 | 0 | 0 |

5 REPLIES 5
JimM11
Community Hero
Community Hero

@sagaodyssey7928 You will need to call EE CS by yourself.

bobpullen
Star Contributor
Star Contributor

Are you sure you're interpreting things correctly? Not all routers will prioritise ICMP/ping responses and some will drop traffic if they've 'better things to be doing'.

e.g. you state that there is 5% packet loss at 62.172.102.224 however, this can't be the case because (pretty much) all of your packets are making it to the subsequent hop. If the traffic was being dropped then this wouldn't be the case 🤔: -

| 62.172.102.224 - 5 | 1541 | 1478 | 5 | 6 | 34 | 6 |
| 194.74.16.145 - 0 | 1779 | 1779 | 6 | 9 | 77 | 7 |

sagaodyssey7928
Explorer

Thank you for response. I'm not sure as I 'm not an expert that is why I am asking expert support like you here to identify the cause/solution of spikes and stutters during gaming.

What about max pings? There are 100+ms spikes although I'm connected to a UK server under unloaded conditions. I've tested today and similar results are shown (in my beginner opinion) for your reference:

|------------------------------------------------------------------------------------------|
| WinMTR statistics |
| Host - % | Sent | Recv | Best | Avrg | Wrst | Last |
|------------------------------------------------|------|------|------|------|------|------|
| hub.home.arpa - 0 | 2519 | 2519 | 0 | 0 | 3 | 1 |
| 172.xx.xx.xxx - 0 | 2519 | 2519 | 3 | 3 | 17 | 4 |
| No response from host - 100 | 508 | 0 | 0 | 0 | 0 | 0 |
| 62.172.102.232 - 14 | 1634 | 1408 | 5 | 6 | 50 | 6 |
| 194.74.16.231 - 0 | 2519 | 2519 | 6 | 8 | 88 | 25 |
| be107.lon-thw-pb1-nc5.uk.eu - 1 | 2515 | 2514 | 5 | 9 | 124 | 7 |
| No response from host - 100 | 508 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 508 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 508 | 0 | 0 | 0 | 0 | 0 |
| be102.lil1-rbx1-sbb1-nc5.fr.eu - 0 | 2518 | 2518 | 11 | 12 | 39 | 12 |
| fra-fr5-sbb1-nc5.de.eu - 0 | 2518 | 2518 | 18 | 19 | 43 | 19 |
| 37.59.16.56 - 0 | 2519 | 2519 | 19 | 21 | 35 | 20 |
| No response from host - 100 | 508 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 508 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 508 | 0 | 0 | 0 | 0 | 0 |
| ovh-d-03-183.thebouncer.email - 0 | 2519 | 2519 | 19 | 20 | 43 | 21 |
|________________________________________________|______|______|______|______|______|______|
WinMTR v0.92 GPL V2 by Appnor MSP - Fully Managed Hosting & Cloud Provider

It helps to think of the MTR trace a little like this: -

  • From your machine to hop 1 and back
  • From your machine to hop 2 and back
  • From your machine to hop 3 and back
  • From your machine to hop 4 and back
  • ...etc

So - to a degree - it doesn't really matter what you see between the first and final hops; as long as the destination response times are reasonable.

e.g. in this latest example, the final hop shows: -

| ovh-d-03-183.thebouncer.email - 0 | 2519 | 2519 | 19 | 20 | 43 | 21 |

Which translates to 19ms best, 20ms average, 43ms worst, 21ms last i.e. not particularly indicative of a problem.

@sagaodyssey7928 Earlier in the post you were saying that the PC was doing gaming as the UDP protocol is that true or not still, packet loss does not matter as the get dropped for ever anyway, You may just have to consider using another Hub to replace the 6 Plus version that you have and see if there is any improvement.