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

Status
Not open for further replies.
Perhaps. Generally, it's around 1% with SQM (FQ_Codel) disabled on my router.
I think you're making a mountain out of a mole hill, personally.

Go to https://packetlosstest.com/
Set the packet size set to max, for both tests to increase the bandwidth
See what loss you get

SQM hammers the CPU of a router, so if you're caining your connection you'll see some packet loss.

Remember, you're running over copper so unless it's causing you issues, leave it go :o
 
0.5% packet loss isn't something I'd ever consider a problem. Any packet loss should be handled by the application, it's possible that Stadia is just bad rather than this being an issue with your internet connection.

If you're bridging USB NICs together in a Raspberry Pi then I wouldn't be surprised if the performance isn't great.
 
Last edited:
Got a reply back from my ISP (Cuckoo Broadband), they say some loss is to be expected and consider 5-10% to be a high amount of packet loss (I assume they mean for FTTC).

Thing is, the impression I get from the Stadia subreddit is that even 1% is going to cause problems (many seem to have much better FTTC or FTTP lines). It's something I've had issues with on other game streaming platforms too.

Maybe it's only something that will affect game streaming? Would 1-2% loss have much impact on video calling software?

The interesting thing is, I (sort of) corrected the packet loss issue when I was using the Asus DSL-N16 router/modem, but only by limiting the upstream sync speed to 1mbps, which causes other performance issues...
 
Last edited:
Throttling the speed probably causes Stadia to send data at a lower rate which never outpaces your connection, therefore nothing has to get dropped. If cloud game streaming can't function with bursts of 1% packet loss then it can never work properly over the Internet.

You're also witnessing first hand the reason why dedicated services with packet loss guarantees cost so much more than broadband connections.
 
So, I did a bit more investigating, this time with Microsoft Game Streaming (who have servers in London) via the browser version. I found out the IP to scan using Netlimiter 4 while running the service, then put the IP into WinMTR. Here are the results:

WUWpzSA.jpg


So, the most striking part of these results is that there's over 55% loss on one of Talktalk's hops after leaving it to run for a couple of minutes.

EDIT - I just repeated this test and got 57% loss, without the Game streaming service running in the background. For some reason, I don't seem to be able to reach every single hop.

My ISP uses Talktalk business for their backhaul, apparently.
 
Last edited:
It's not unusual for intermediate routers to drop pings directed to them.

I'd guess from the FQDN that the "talktalk" host is actually the peering point in the Microsoft network for talktalk traffic. If so, it'll be a busy box which will be prioritising actual traffic.
 
I'm fairly sure people have told you this before, but if you were actually getting 55% packet loss at a hop then everything else after it would also be showing that level of packet loss. You cannot compare ICMP traffic being dropped with UDP packet loss. The Stadia service itself shows the packet loss at between 0.5% and 1% - this is completely acceptable for a broadband service.

Please listen to what people are saying here rather than just going off and doing your own thing, misinterpreting the results and then posting again. Have you set up that smokeping instance yet like you've been requested to every time you've made a thread about packet loss?
 
I installed it, but think I'll leave it. Got no idea how to set it up, it looks like it would take some time and expertise to get it working. It said something about needing to install some Linux files too.
 
Last edited:
Thankyou, perhaps I'll come back to this in a (long) while, or just upgrade to FTTP, potentially at some point in 2023 if all goes well.
 
Status
Not open for further replies.
Back
Top Bottom