Soldato
- Joined
- 24 Sep 2015
- Posts
- 3,976
Oof, I missed that. Yeah, 0.1s is obnoxious.
Setting reasonable expectations would be a good move too.
BT Infinity & FTTx Discussion
- Thread starter michellez
- Start date
Oof, I missed that. Yeah, 0.1s is obnoxious.
Setting reasonable expectations would be a good move too.
I checked hops 2-4, they are Talktalk (Opal Telecom hops). The 9th hop is the last hop, which appears to have the same amount of packet loss as the 3rd hop.
Is this worth looking at, or am I wasting my time
It's pointless, my first hop to Vodafone shows packet loss for me.
But I don't actually get any packet loss to stuff past it, it's just that device that has some sort of firewall or something that causes drops.
I'd be happy to help you w/ setting up Smokeping, if you had questions I'd be happy to answer.
No one can help you with setting it up if you're unwilling to try a little harder than you have already.
Last edited:
Ok thanks for the help and patience guys. The packet loss I see on Stadia happens all the time, in almost exactly the same way, whenever I start a session and continues throughout. Generally, thousands of lost packets after a few minutes of streaming, which increases depending on the amount of bandwidth used. I don't think the issue occurs much / at all at 720p resolution. Might be interesting to test at 4K resolution.
My interpretation of this is that the copper cable/ infrastructure is probably the reason for the loss. Some have suggested that the main limitation on ADSL/VDSl lines is the copper part of the line, which seems reasonable to me. What other possibilities exist, in your experience?
I will certainly run some more captures, with less intensive ICMP intervals.
My interpretation of this is that the copper cable/ infrastructure is probably the reason for the loss. Some have suggested that the main limitation on ADSL/VDSl lines is the copper part of the line, which seems reasonable to me. What other possibilities exist, in your experience?
I will certainly run some more captures, with less intensive ICMP intervals.
Last edited:
So, I tried a session set to 4K resolution after creating a new account, but it scaled it down after a minute or so to 1440p, then 1080p. Packet loss is between 1000-2000 per minute.
EDIT - Tried setting the resolution to 720p (mobile data setting limits traffic to around 7mbps), didn't get any packet loss at all in 20 minutes, gameplay felt very smooth.
EDIT - Tried setting the resolution to 720p (mobile data setting limits traffic to around 7mbps), didn't get any packet loss at all in 20 minutes, gameplay felt very smooth.
Last edited:
You need to stop rabbit holing into wild theories and tests, and do the basics.
- Use TBB, carry on posting the graphs
- Use a wired connection if you haven't already
- Use a decent UDP based Wireguard VPN over the wired connection and see how it is
- Change cables, between gaming device and router, also between router/modem and faceplate
- Eliminate voice interference by doing the BT noise test from a phone
- Try a different router if possible
- Stop using ICMP/traceroute!
I think it's very likely that the lack of G.INP (also known as ReTX) on my line is the reason there's packet loss on this connection. This is a technology that allows data packets to be retransmitted before they reach the customer's address, rather than simply being dropped.
The majority of FTTC lines have had this for years, but unfortunately, Openreach never managed to get it working on some FTTC cabinets (manufactured by ECI). They tested G.INP on ECI cabinets multiple times, but it was never rolled out (probably won't ever be now).
I've no way of knowing if this is the reason, so I'd need someone with a FTTC connection connected to an ECI cabinet to run Stadia to know if this is true or not.
The majority of FTTC lines have had this for years, but unfortunately, Openreach never managed to get it working on some FTTC cabinets (manufactured by ECI). They tested G.INP on ECI cabinets multiple times, but it was never rolled out (probably won't ever be now).
I've no way of knowing if this is the reason, so I'd need someone with a FTTC connection connected to an ECI cabinet to run Stadia to know if this is true or not.
Last edited:
Occam's Razor - e.g. the simplest explanation is most likely the right one. Copper lines aren't suited to carrying data, and quite frequently data packets have errors caused by noise or attenuation and are lost. I can't comment myself on the effectiveness of G.INP itself though at avoiding / mitigating packet loss, but it seems to have been well received where it was rolled out.
So, I played a bit more in Stadia, managed to reduce packet loss to ~0.2% when playing at 1080p (down from approx. 1% with SQM disabled). To do this, I had to change these SQM settings on my router:
1. Reduce upload bandwidth to 4000kbps
2. Set the Per Packet Overhead to 256 (an unusually high amount)
Other settings that helped a lot - Basically everything off on my PC's network adapter.
The fact that this works this indicates to me that there is a line problem (rather than an ISP related issue).
It occurs to me that applying interleaving (already enabled for the downstream) on the upstream might be a better solution to doing the above, in terms of correcting packet loss. Are there any VDSL modems that allow the user to enable interleaving manually?
EDIT - Here's the results from a 11 minute session:
https://i.imgur.com/C7B2JNI.jpg
1. Reduce upload bandwidth to 4000kbps
2. Set the Per Packet Overhead to 256 (an unusually high amount)
Other settings that helped a lot - Basically everything off on my PC's network adapter.
The fact that this works this indicates to me that there is a line problem (rather than an ISP related issue).
It occurs to me that applying interleaving (already enabled for the downstream) on the upstream might be a better solution to doing the above, in terms of correcting packet loss. Are there any VDSL modems that allow the user to enable interleaving manually?
EDIT - Here's the results from a 11 minute session:
https://i.imgur.com/C7B2JNI.jpg
Last edited:
No, that's the exchange side.
Openreach flipped our area to "fibre coming soon" in June 2021, added it to the Fibre First map and rollout documents around October last year, and are currently building on the other side of town. That's all scheduled to finish mid-April according to the roadworks they've booked in, my hope is they get over to us shortly after that and we might be looking at a go-live around June/July. I'll see how long the service takes to become available to order after the work completes in the current areas.
Probably going to go with 500/75 for cost reasons initially, the only use for 1Gb would be the upload and going from 75Mbps to 115Mbps isn't a game-changing number for the usage it's likely to get. The increase from ~17Mbps will be welcome enough.
Probably going to go with 500/75 for cost reasons initially, the only use for 1Gb would be the upload and going from 75Mbps to 115Mbps isn't a game-changing number for the usage it's likely to get. The increase from ~17Mbps will be welcome enough.
Soldato
- Joined
- 14 Apr 2014
- Posts
- 7,425
- Location
- Hampshire
Because it’s a completely different technology, you’ll find the change from FTTC to FTTP transformational.
Everything will feel snappier and quicker in general. The increased bandwidth is a bonus if anything
I'm reasonably lucky at the moment as I get 60Mbps and a fairly consistent 8ms ping to most places, but it's been this speed since FTTC was installed in 2012 which is about the same amount of time it took to go through all the ADSL, ADSLmax, ADSL2+ phases in the previous decade. It's sort of amazing when you stop to think how little progress there's been up until now.
Associate
- Joined
- 4 Jun 2021
- Posts
- 475
- Location
- Yorkshire
No that's jumping to an unsupported conclusion.
Applying SQM affects the IP layer between your router and the ISP's LNS and has no direct impact on the DSL link. I guess you might alleviate a problem with the DSL line through applying QoS higher in the stack; but to jump straight to the conclusion that applying QoS to the IP layer making things better means there's a problem with the DSL link would be wrong.
First of all, understand that the OpenWRT SQM scripts aim to solve problems with bufferbloat. That's when your router (or your ISP's router(s) for that matter) buffers too much data such that latency is affected.
There are several tools which can help you understand if you have a problem with bufferbloat (links from bufferbloat.net would be a good place to start) and the other things we've suggested (graphs from your router, the ThinkBroadband BQM, smokeping and so on) while not specifically about bufferbloat can also help - but you need to use them consistently and correlate each tools results together.
There was also a discussion about it over in the Virgin Media thread here which is worth going through. I'm not sure exactly where it starts (this post https://forums.overclockers.co.uk/posts/35234668 is somewhere in the middle I think). @Rainmaker can you suggest a point to jump in to that thread - I believe you are also using OpenWRT and reached a good SQM configuration?
Here's a real sting. Imagine where this country could have been by the year 2000.
"At that time, the UK, Japan and the United States were leading the way in fibre optic technology and roll-out. Indeed, the first wide area fibre optic network was set up in Hastings, UK. But, in 1990, then Prime Minister, Margaret Thatcher, decided that BT's rapid and extensive rollout of fibre optic broadband was anti-competitive and held a monopoly on a technology and service that no other telecom company could do."
https://www.techradar.com/uk/news/world-of-tech/how-the-uk-lost-the-broadband-race-in-1990-1224784