|
|
This is actually caused by the opposite of buffer bloat, under buffering. In essence the buffer on the provider side is too small to absorb the bursts of packets the CDNs are sending. This causes every round of packets they send to over flow the buffer. The LNS server on the ISP side cant enter and exit the dropping state quickly enough to pass the full line rate. The 'fix' on the ISP side is to increase the size of the buffer however the problem with this is that it increases hardware requirements on their side.
This behiaviour is usually accompanied by lower than expected throughput on the line while flows from a bad source are happening. I've worked in depth with BT Business on this and I believe that buffers on at least certain BT Business products have been adjusted which has helped in my cases. I encourage you to reach out to your provider to discuss this as you are the first person I've ran into 'in the wild' and 'outside of my customer base' that is impacted.
The buffer bloat sounds possible after googling it.
Its like anything above a certain latency gets dropped. The cap seems to be very low.
https://www.thinkbroadband.com/broadband/monitoring/...
My usual router is a belkin RT1800 running openwrt, i've also tried a decent gaming pc as a dial up PPPOE connection with the same result. I'm currently on the plusnet router again, they want to send one of their engineers to check it out (not openreach)
It would be great if someone could test epic or battle.net downloading at full speed to see if they have similar results.
Edited by agoodm (Wed 23-Oct-24 15:41:10)
|
|
|
Presume BT still heavily using Cisco gear like I know they were years ago?
Only asking as I had to spend a day or two recently tweaking the buffer settings on a spanking C9300X which altough has hardware specs that make you blush, out of the box is like a blank canvas and the default buffer sizes are terribly undersized. Performance was woeful at full tilt until I upped the port buffer limits. A well known Cisco issue.
Possibly of tangental help to the OP.
Edited by Pheasant (Wed 23-Oct-24 15:45:06)
|
|
|
|
Post deleted by agoodm
|
|
Register (or login) on our website and you will not see this ad.
|
|
|
Accidentally deleted my other reply but in essence I dont think its a exactly a secret that BT use Nokia SRS devices heavily throughout their network including routers and LNS roles. By default the queue length on the LNS is/was 1000 packets which on the gig service = 5MS. Sadly common software applications create 10-15 flows from 10-15 distinct CDN nodes which all appear to dump 64KB onto the network at likely 100Gbps per round. When this arrives at the LNS the buffer overflows and the queue enters the dropping state. Crucially with the buffer being so small the LNS simply cant enter and exit the dropping state quickly enough which results in lower than expected throughput. The 'fix' is for the provider to increase the size of the buffer and indeed this is/was being trialled at least for BT Business customers. Unfortunately its a million dollar question re how large the buffer should be. Too large hurts performance under load, too small risks under buffering. The size of the buffer also dictates hardware sizing on the LNS side which is a big deal in the race to the bottom market they operate in... Ultimately in my opinion pressure should be applied to the CDNs to stop activing like a DoS attack. I'm running into situations where one user hitting one of their services can be impossible to QoS because even dropping 10+Mbps does not cause them to back off...
Presume BT still heavily using Cisco gear like I know they were years ago?
Only asking as I had to spend a day or two recently tweaking the buffer settings on a spanking C9300X which altough has hardware specs that make you blush, out of the box is like a blank canvas and the default buffer sizes are terribly undersized. Performance was woeful at full tilt until I upped the port buffer limits. A well known Cisco issue.
Possibly of tangental help to the OP.
|
|
|
the old alt net was brsk (wan was dhcp) and was very good.
At idle I get no packet loss. I would expect latency not packet loss though on the connection when downloading?
If anyone else can try start an update on battlenet or epic games then ping 8.8.8.8 and see if get issues. I had a temp 30mb Sogea line for a while and even that managed better without packet loss just latency.
Thanks for confirming, PPPoE is a more demanding protocol than IPoE, so you have two possible causes now, either BTw anti buffer bloat causing it, or the router not been able to handle PPPoE at those sort of speeds.
|
|
|
Accidentally deleted my other reply but in essence I dont think its a exactly a secret that BT use Nokia SRS devices heavily throughout their network including routers and LNS roles. By default the queue length on the LNS is/was 1000 packets which on the gig service = 5MS. Sadly common software applications create 10-15 flows from 10-15 distinct CDN nodes which all appear to dump 64KB onto the network at likely 100Gbps per round. When this arrives at the LNS the buffer overflows and the queue enters the dropping state. Crucially with the buffer being so small the LNS simply cant enter and exit the dropping state quickly enough which results in lower than expected throughput. The 'fix' is for the provider to increase the size of the buffer and indeed this is/was being trialled at least for BT Business customers. Unfortunately its a million dollar question re how large the buffer should be. Too large hurts performance under load, too small risks under buffering. The size of the buffer also dictates hardware sizing on the LNS side which is a big deal in the race to the bottom market they operate in... Ultimately in my opinion pressure should be applied to the CDNs to stop activing like a DoS attack. I'm running into situations where one user hitting one of their services can be impossible to QoS because even dropping 10+Mbps does not cause them to back off...
Presume BT still heavily using Cisco gear like I know they were years ago?
Only asking as I had to spend a day or two recently tweaking the buffer settings on a spanking C9300X which altough has hardware specs that make you blush, out of the box is like a blank canvas and the default buffer sizes are terribly undersized. Performance was woeful at full tilt until I upped the port buffer limits. A well known Cisco issue.
Possibly of tangental help to the OP.
Did you / do you see clients with packet loss issues using Openreach-based FTTP networks though?
I've been on again off again using an Openreach FTTP service at my place in Suffolk. I've variously used Cerberus, TalkTalk Biz and the since the middle of this year I'm back using it again, but this time with EE as the ISP on the 1.6Gbps tier.
I've not really seen any packet loss. I'm back there tomorrow and could probably run some deeper tests, but it's not something I've ever noticed, even running at full tilt using a PPPoE connection.
I'm inclined to think the issue is not so much with the provider, but potentially with the OP's router.
|
|
|
Thanks for confirming, PPPoE is a more demanding protocol than IPoE, so you have two possible causes now, either BTw anti buffer bloat causing it, or the router not been able to handle PPPoE at those sort of speeds.
I'm also inlined to think its the latter.
Even Windows-based laptops I've found can struggle running a PPPoE client, especially if they are a few years old, hence aren't necessarily an indicator of rude network heath.
The OP is better off testing using either a Mac or Linux machine direct into the ONT.
|
|
|
Did you / do you see clients with packet loss issues using Openreach-based FTTP networks though?
I've been on again off again using an Openreach FTTP service at my place in Suffolk. I've variously used Cerberus, TalkTalk Biz and the since the middle of this year I'm back using it again, but this time with EE as the ISP on the 1.6Gbps tier.
I've not really seen any packet loss. I'm back there tomorrow and could probably run some deeper tests, but it's not something I've ever noticed, even running at full tilt using a PPPoE connection.
I'm inclined to think the issue is not so much with the provider, but potentially with the OP's router.
I've got personal experience in BT Business FTTP. I've also tested ICUK G.Fast with similar results. They use the same or similar buffer sizes on FTTC however with the lower speeds on FTTC the buffer sizing is adequate. I have still ran into difficulties providing QoS though as they are so aggressive and not necesarily respond to packet loss.
The acid test I've been using is installing Fortnite in the Epic Games Launcher. I would see below line rate in the download but would not be able to use the remainder of the connection. EG the Fortnite download might run at 650Mbps but starting another download along side it would not result in throughput increasing to the line rate. BQM would show like OPs with base latency going up 5MS and significant packet loss, upwards of 10%. In order to get the problem to go away I would need to QoS this download to around 450Mbps. I was trialling a longer buffer size at one point, I dont know if this has been rolled out across BT Business.
In my case the 'router' in question is an HP Proliant server which is comfortably capable of 10Gbps of PPPoE without breaking a sweat. Indeed even a BT Business Hub 5 can do 1Gbps of PPPoE assuming its otherwise fairly idle.
|
|
|
|
Thanks for the info very interesting to hear. I do work for a business telecom provider and connected lots of gamma and zen connections but I haven't come across this issue on fttp. I've just swapped the router out for a draytek 2766. Had the same result with packet loss. If I bandwidth limit the connection to 440mb the packet loss stops. I do see the occasional 1x 1000ms+ response in the mix which is odd but no packet loss.
Can't imagine the Plusnet guy coming will have any idea on this one. Unless they can escalate it.
|
|
|
Can't imagine the Plusnet guy coming will have any idea on this one. Unless they can escalate
Can’t imagine that the guy will work for Plusnet.
54-46 was my number
|
Pages in this thread: 
Print Thread
