Packet loss has persisted for years and from VDSL to FTTP

I've suffered from packet loss for years. I've been on VDSL BT, Plusnet and TalkTalk over these years and the packet loss has persisted between ISPs, back hauls and routers.

It occurs on all devices on my network both Linux and Windows, wired and wireless, multiple NICs, all cables have been replaced multiple times and currently running cat 6e high quality ethernet cables.

A few months ago I had Giganet FTTP installed under Openreach and the packet loss has remained. I'm currently on 500/70mbs test result here

I'm currently using the Technicolor DGA4134 provided by Giganet.

On VDSL with BT I used the Home Hub 3 and Home Hub 5. On Plusnet I used a TPLink TD-W9980 with both stock firmware and OpenWRT. On TalkTalk I used both the provided TalkTalk Hub and the TD-W9980 with OpenWRT.

Of all the different combinations TalkTalk and their provided hub seemed to have the least occurrences of packet loss but still quite often and at seemingly random times. All other setups is pretty much consistent packet loss all day every day including on FTTP.

The packet loss is always around 3%. When gaming I see around 3-4% packet loss consistently in all games on all servers in all locations.

The symptoms are just generally bad hit reg, stutters/small freezes, glitchy inconsistent game mechanics like enemies moving way too fast, stuttering abnormal animations, having impossible reaction times, being killed before I can see people, enemies being perfectly accurate while somehow running faster than full speed whilst transitioning into a crouch state which is supposed to slow you down instantly(CS:GO), and just generally feeling way behind in the game state.

How can this packet loss carry over to so many different setups and services?

The green cabinet I have always been connected is an ECI cab that appears to have never changed. To this day it is still the old cabinet it has been since at least 2009 (same cabinet in google streets with images taken in 20009) so I'm assuming for FTTP I must be connected to another cabinet........or would they have just connected me to the same ECI cabinet for FTTP and could that be the source of the packet loss? I'ts the only common variable I can think of!

Gaming Net Graphs

BF4 UK Server
BF4 NL Server
BF4 DE Server
Valorant MM server (Stockholm)
Star Trinity Speed Test

MTR - Im not sure what to make of these results, I know they might not be accepting pings but I have never seen results like this from so many hops across so many destinations.

CS:GO Community Server, DE
CS:GO Community Server, NL
CS:GO Community Server, UK

Google UK

It's been 7 years and it's driving me nuts.......any theories?

My theory is that , since everything external, ISP, network, service type, has changed, then the issue is internal to you network/equipment.

So what do you get when you test using this site (select United Kingdom server from dropdown at bottom of screen)

https://packetlosstest.com/

Both the DE+UK CS:GO community servers show packet loss between your computer and your router dsldevice.lan. (UK=~35% / DE=~92%!)

This might not matter if the DGA4134 doesn't prioritise responding to pings.

Are you able to set up a ThinkBroadband Broadband Quality Monitor? Even if you have a dynamic IP, it would still be useful to test the connection from the WAN side of your router to the Internet.

Another interesting test might be to dig up the TD-W9980 again, remove the antennas, and the WAN cable, etc. Just have one Ethernet cable between your PC and the 9980, and run the packet loss test command with the 9980's IP as the destination. This could eliminate the Internet connection entirely from the equation. (Loss=PC/router/"internal" issue. No Loss=Internet issue.) Make sure to test for a good 5+ minutes.

Edited by AndrewNi (Sat 12-Nov-22 10:36:07)

In reply to a post by Zarjaz:

My theory is that , since everything external, ISP, network, service type, has changed, then the issue is internal to you network/equipment.

Well, I would agree but my own hardware has changed many many times. Ive had 3 completely different pc builds along with upgrades swapping out components over the years, multiple routers and multiple operating systems. I have essentially 3 pcs right here....I say essentially because one is a steam deck which some might not see as a pc even though it is. I've live booted Linux lite and ran mtr and star trinity on it (can't game on it) and those results match both my other pcs. Both of the other pcs are intel, one is ivy bridge 3570k the other is rocket lake 11700kf (my gaming pc). The 3570k machine has a realtek nic and the 11700kf machine has an intel nic. I have a dock I bought for the steam deck with GB Ethernet, this shows the same packet loss on all machines alongside their own built in nics. There really is no hardware variable that hasn't been changed multiple times over the years so if it does turn out to be a local hardware problem then I must have VERY bad luck.

In reply to a post by dect:

So what do you get when you test using this site (select United Kingdom server from dropdown at bottom of screen)

https://packetlosstest.com/

On there I get packet loss too. It's usually around 1% vs the common 3%+ when actually gaming. But does this test use UDP or TCP protocol. I have a feeling the loss is on the UDP protocol since it really only seems to show in games.

In reply to a post by AndrewNi:

Both the DE+UK CS:GO community servers show packet loss between your computer and your router dsldevice.lan. (UK=~35% / DE=~92%!)

This might not matter if the DGA4134 doesn't prioritise responding to pings.

Are you able to set up a ThinkBroadband Broadband Quality Monitor? Even if you have a dynamic IP, it would still be useful to test the connection from the WAN side of your router to the Internet.

Another interesting test might be to dig up the TD-W9980 again, remove the antennas, and the WAN cable, etc. Just have one Ethernet cable between your PC and the 9980, and run the packet loss test command with the 9980's IP as the destination. This could eliminate the Internet connection entirely from the equation. (Loss=PC/router/"internal" issue. No Loss=Internet issue.) Make sure to test for a good 5+ minutes.

I do have the DGA4134 set to respond to pings. I have ran just local tests to all of the routers with no packet loss over the years but I will do some more tests tomorrow. One thing I did notice across the board, enough for it to pop out as possibly not just a coincidence was disabling WiFi on whatever router I was using (I had already tested with all of my wireless devices switched off/checked there was no wireless connections on the router itself to make sure some rogue device wasn't eating bandwidth and causing buffer bloat) would bring the packet loss down or even to 0%......but it would return after a while of testing/throughput. Another thing to note is the packet loss sometimes seems to appear after a short while (from a few seconds to minutes) after joining a game server or a short while after running a test. For example, mtr tests will show 0% at first and then hops will start to saturate with packet loss. With some destinations it's after a couple of seconds, other destinations its a little bit longer, but once one hop starts showing loss they all quickly start to follow suit.

I haven't set up a BBQM on this connection yet but I have ran them in the past on VDSL which IIRC didn't show any problems, at least nothing that correlated with what I was getting from the usual tests on my side. I will set this up on my current connection tomorrow. I do have a static IP with Giganet BTW.

I am on the side of this being something on my end..........I just cannot fathom what it could be as every variable has been changed many many times. I've even considered it maybe being somehow malware that has managed to persist somehow over many builds, eating away at my connection but I can dismiss that just looking at my network usage on the router itself.......which shows if i'm not using the connection the usage is a flat graph and usage correlates to what i'm doing otherwise.