Packet loss on Stadia on a VDSL2 line - Is there anything I can do about it?

[g67575]

I've been getting packet loss on my VDSL2 while streaming games and videos. Please screenshots below:

Spoiler: Stadia screenshot 1

Spoiler: Stadia screenshot 2

Packet loss occurs on Stadia and other game streaming platforms like Microsoft Game Streaming and Geforce Now (had to measure how much on these). But it's definitely enough to cause interruptions in the video stream, some input delay and audio cut outs. In general, the higher the bandwidth usage, the greater the amount of loss on this line.

Here's what I've done in an attempt to resolve it:
1. Wired up most my house with ethernet (partly to prepare for FTTP in the future).

2. Replaced router with an OpenWRT router (Raspberry Pi 4 with 4 core CPU).

3. Tried different modems (just used existing routers in bridge mode).

4. Contacted my ISP (Cuckoo Broadband). They logged a fault with Openreach and sent some Openreach engineers (on 2 separate occasions) who didn't seem to have been told specifically what the fault was, and I didn't even know the ISP had arranged for them to come around... Anyway, they checked the line with a device and said it was fine and within the range they would expect given the distance to my cabinet.

So, I'm at a loss - Maybe these faults can't be corrected on VDSL2 lines? When it comes to FTTC/VDSL2 The line quality and signal strength is mostly decided by the distance to the local FTTC cabinet, based on what I've read and been told.

Anyone else experienced a similar problem on a VDSL2 line?

 

[Turn]

Setup SmokePing, so you can view your latency, that'll give you a better idea to when it occurs, if there's any pattern to it, etc.
It'll also allow you to prove to your ISP that you're having issues with the latency aswell & you can add a range of IP's to see if it's only certain paths that have an issue.
I suggest adding some Anycast addresses such as 1.1.1.1, google.com, fastly.com.
https://hub.docker.com/r/linuxserver/smokeping

Once you have that setup, and you can actually monitor and see what's going on, and how bad the latency really is and at what times in particular you can move on from there.
I suggest changing the step size to 60 from the default of 300 in the Database file, so you can get more data.

 

[arknor]

if you have a phone plugged in try unplugging it

 

[g67575]

if you have a phone plugged in try unplugging it

There's a few connected, one at the master socket, 2 on extensions. Might be hard to disconnect one of them as the extension is behind a large desk. I think I might try connecting the modem directly to the test socket in the master socket instead.

 

[Turn]

Alright, keep on piling in the threads instead of listening to good advice

 

[VersionMonkey]

Smokeping is a good option, but as you are running OpenWRT, another option would be collectd-mod-ping. That would allow you to test just the latency on your VDSL line (by setting the other end of the PPP link as the target). That would help you understand if the problem is actually your VDSL line or something else (like your network/PC or your ISP's network).

What QoS have you enabled on OpenWRT?

 

[g67575]

@VersionMonkey - That's a good idea, thanks. Sorry, not sure what you mean by the other end of the PPP link. Do you mean my WAN IP address? Or, I could ping the 1st hop out to the Internet.

My connection is PPPOE btw.

Also, the results above are with SQM disabled. I can improve the packet loss to around 0.4-0.5% with FQ_Codel enabled (I've tried various settings for this).

 

[VersionMonkey]

@VersionMonkey - That's a good idea, thanks. Sorry, not sure what you mean by the other end of the PPP link. Do you mean my WAN IP address?

In a typical configuration, your WAN IP address would be (unless you are doing something funky with NAT) the address at your end of the point-to-point (PPP) link between your network and the ISP's network. Their end of that link will also have an IP address. You can see it in the LuCI summary, or from the command line on the router in the output of the ifconfig command - you should have an interface with Point-to-Point Protocol encapsulation which will show both your WAN IP and a P-t-P address.

Pinging the P-t-P address from your router eliminates a bunch of other possible causes for the problem you are having. It tests a bit more than just the VDSL link as it includes the wholesaler's network and it's dependent on the ISP's router not being overloaded (although that would tell you something in itself). But if you combine that information with things like the ThinkBroadband monitor, a smokeping to a bunch of other targets out on the wider internet and knowledge of what else might be happening on your network (e.g. somebody starting to watch Netflix) at the time you experience problems with Stadia you can start to systematically approach where the problem lies.

My connection is PPPOE btw.

That is normal, the PPP bit is the same whether it's running over dial-up, Ethernet or ATM. So long as you've got it set up so that your OpenWRT device is the thing that is doing the PPP and not the router-in-bridge-mode you are using as a modem.

 

[g67575]

Ok thanks. I've setup a ping to my gateway IP, which appears to be the same as the P-t-P address reported by ifconfig.

 

[g67575]

I seem to be getting some packet drops on the br-lan network interface (reported by ifconfig), which acts as the switch in my network. These drops happen all the time, regardless of whether or not I'm using Stadia. But it's only 352 packet drops after 6 minutes, so it's probably not causing the Stadia packet drops. The WAN interface isn't dropping packets or reporting errors.

 

[VersionMonkey]

I seem to be getting some packet drops on the br-lan network interface (reported by ifconfig), which acts as the switch in my network. These drops happen all the time, regardless of whether or not I'm using Stadia. But it's only 352 packet drops after 6 minutes, so it's probably not causing the Stadia packet drops. The WAN interface isn't dropping packets or reporting errors.

You mean you've got non-zero for "dropped:" in this bit of the output:

RX packets:126737640 errors:0 dropped:0 overruns:0 frame:0
TX packets:394224983 errors:0 dropped:0 overruns:0 carrier:0

Is this still on the RPi 4? What do you mean by "acts as the switch in my network" - what is it connected to? Are you also using the RPi as a WiFi access point?

 

[g67575]

Yes it's an interface on the RPi 4, it looks like this:

br-lan Link encap:Ethernet HWaddr [Removed]
inet addr:192.168.1.1 Bcast:192.168.1.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:31832 errors:0 dropped:550 overruns:0 frame:0
TX packets:54589 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:4231666 (4.0 MiB) TX bytes:61707806 (58.8 MiB)

This interface connects to a 4 port switch, which also has a Wifi access point (not using the RPi 4's WIFI).

The thing is though, I was still getting the packet loss in Stadia with a different router / network setup (just using my ISPs router as the modem and router).

 

[g67575]

Here are the ICMP graphs showing pings to my gateway after >1 hour:

Spoiler: ICMP graphs

There's a few instances of ICMP drops, I will keep an eye on it. I've set the ping interval to 0.1 seconds.

How should I interpret the results?

 

[Deleted User 298457]

Is this guy a troll?

I've never seen so many random threads about packet loss in my life.

Edit: and he is still running his gear off of a telephone extension, lol.

Alright, keep on piling in the threads instead of listening to good advice

Glad I'm not the only one paying attention

 

[g67575]

Is this guy a troll?

I've never seen so many random threads about packet loss in my life.

If you don't wanna help, you know where to go... My modem is connected to the master socket.

 

[Deleted User 298457]

If you don't wanna help, you know where to go... My modem is connected to the master socket.

Well subject to moving house you've tried everything else. There is only one other variable to change...

 

[VersionMonkey]

Yes it's an interface on the RPi 4, it looks like this:

br-lan Link encap:Ethernet HWaddr [Removed]
inet addr:192.168.1.1 Bcast:192.168.1.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:31832 errors:0 dropped:550 overruns:0 frame:0
TX packets:54589 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:4231666 (4.0 MiB) TX bytes:61707806 (58.8 MiB)

This interface connects to a 4 port switch, which also has a Wifi access point (not using the RPi 4's WIFI).

The thing is though, I was still getting the packet loss in Stadia with a different router / network setup (just using my ISPs router as the modem and router).

Ethernet interface to a switch should not be dropping that many packets - I wouldn't normally expect to see any at all, never mind hundreds in a few minutes. What make/model of switch is it and have you tried replacing the cable? Were you using that switch with the ISP router as well?

 

[g67575]

Were you using that switch with the ISP router as well?

Nope. I've tested the connection with 2 different modem/router combos that didn't use this switch (TP-LINK Archer VR200 in bridge mode).

 

[g67575]

I've tested the line just now directly connected to the test socket (to isolate telephone wiring). but still seeing the same problem, getting around 0.4-0.5% packet loss (SQM enabled) in Stadia.

 

[Armageus]

I've tested the line just now directly connected to the test socket (to isolate telephone wiring). but still seeing the same problem, getting around 0.4-0.5% packet loss (SQM enabled) in Stadia.

Try with a standard ISP provided router without messing about with SQM or anything else.

Not sure why you are making this as difficult as you are.

Strip everything back to absolute basics. Most basic router you can find plugged directly into the master test socket with nothing else connected. Connect a laptop or PC directly to the router with an ethernet cable, and then test.

If that works then add things back in one step at a time until the problem returns.
If it doesn't work then it's an ISP issue and having tested with their supplied kit and the most basic setup possible, you can go back to them for help.


And for the love of god, please don't create 57 more threads about your packet loss issue